Wednesday 6 February 2008

Orchestration and Choreography, WS-BPEL and WS-CDL

I am somewhat compelled to write on the topic of WS-BPEL and WS-CDL. This is a topic that has surrounded the development of WS-CDL since it's inception and alas there has been a great deal of myth making in the telling of the story by large vendors and analysts alike. For those that are interested and of open mind I hope this helps position the two.

Rather than trawl back through history I shall focus forward and look at problems and solutions instead as I think these are much more important than the politics of standardisation and the great debate of orchestration vs choreography.

Fundamentally it is all about abstraction and expression. Since the days of Alan Turing and Alonso Church computer science has looked at higher and higher levels of abstraction in which all that went before can be incorporated in some way with what is on offer. We see the demise of assembler and the rise of structured programming languages. We see the demise of structured programming languages and the rise of object-oriented languages - now of course I egg it up and many of the older languages are still used and are very useful but I play to the main gallery in this particular blog.

Abstraction that is well founded (and so has some formal underpinnings) is a very useful concept in academia and one might be forgiven in thinking what benefit does this bring to business. Generally it boils down to two things. Firstly as the level of abstraction increases (and yet the expression remains the same) so the speed of delivery of an executable increases

This was the true with the move from C to C++ and then to Java and C#. As the level of abstraction rises so the gap between the requirements and the solution becomes smaller and in this way the alignment of solution to requirements or as is often said IT to business becomes cleaner and crisper. The message is that abstraction really does matter and really does impact business and is not just an academic nicety,

So where does this fit with WS-BPEL and WS-CDL. After all you probably think that they are the same. If you look at what they do and how they do it and how they describe things you will very quickly understand that the levels of abstraction they deal in are different. If you imagine wanting to build a car and you go out and select all of the tools and technology to do so it might at the high end look a little similar in abstraction to WS-BPEL. A bunch of parts that are delivered as units that are orchestrated into ever higher units which are orchestrated and delivered as a service. If you wanted to build a motorway (interstate highway) system you would not use the same tools and technologies that you use to build cars. Road systems are not orchestrated, rather they have some rules that govern them but they essentially acts as channels between peers (roads between cities or towns or villages). WS-CDL describes interactions between peers without describing how those peers do their business internally. It described a blueprint of communication. WS-BPEL simply does not describe what WS-CDL does and WS-CDL does n ot describe what WS-BPEL does. They are tools for different purposes. Just like cars and roads they are complimentary. Obviously you can drive a car off road. You can use WS-BPEL without WS-CDL. Obviously you can use a road without a car and so WS-CDL can be used without WS-BPEL. But magic stuff happens when roads and cars come together just like WS-CDL and WS-BPEL.

Now the tools we actually use for building cars can be used to build roads. We could use a spanner and hammer and a screw driver to help dig. But it makes more sense to use a spade or digger. And this is the point. We can all use assembler still but for the most part we choose not to because the level of abstraction does not match the problem we try to solve.

At this point I want to look to others to support the differences and the complementary nature of the WS-BPEL and WS-CDL. Here are two interesting takes on it.

A recent report from Burton group stated:

"Right now developers working on complex service-oriented architecture implementations face a Hobson's choice between an existing standard that doesn't meet their needs and an emerging standard that they can't use yet, according to a Burton Group report released this week."

and went on to say,...

"Despite its limitations, Howard sees BPEL with its vendor tools support continuing to play a role in SOA development. Eventually, however, BPEL sub-processes will play a subordinate role in the larger choreography and WS-CDL with vendor support will be the big picture standard."

Others, in response to the above said

"I think it is out of confusion that people get hung up on the equality of BPEL and WS-CDL. They address very different perspectives in a service-oriented approach (i.e. orchestration and choreography). Therefore to say BPEL is limited, is true if you are considering choreography but not so if you take what it aims to fulfil - orchestration, the executable process. Let us move on, and stick with the fact that they complement each other..."

So I am not alone in thinking that WS-CDL is important and I am not alone in thinking that WS-CDL worked or could work rather well with WS-BPEL and that they are in fact different beasts doing different jobs which themselves are complementary.

If you are still not convinced then let me point you to an example in WS-CDL and see if you can encode the same example in WS-BPEL as efficiently. You can certainly create systems using just WS-BPEL but the problem is that as soon as you need to deliver more than one service collaboration is needed and this is where WS-CDL works well. If you try to solve collaborative service problems using WS-BPEL you will find that the complexity and subsequent management starts to impinge on success. You will end up with many moving parts (one WS-BPEL per service and one set of partner links to each service that talks to another and so on) and many files. With WS-CDL you will end up with one file for the collaboration and can use this to generate the necessary WS-BPEL files ensuring that they all match up. Doing it without WS-CDL you will be forced to match all of the WS-BPEL files by hand - time consuming and error prone.

As one well known computational scientist once said (Jon Bentley's Programming Pearls) "I'd rather write programs to write programs", the very essence of abstraction.

And as John Koisch (HL7) told me today WS-BPEL is a very good white box service language and WS-CDL is a very good black box system language.

It really is akin to the difference between assembler and say Java. You can do it, but should you do it that way when better ways exist that will help you deliver faster and with a greater quality of result.

I would welcome further comments.

1 comment:

Unknown said...

One of the practical benefits of using WS-CDL and WS-BPEL together is that WS-CDL does not have a standard endpoint language.

Therefore WS-BPEL abstract processes can be used as an endpoint representation for the WS-CDL projected endpoints, and then conformance checking of services can be handled by WS-BPEL abstract process to executable process conformance.

So WS-CDL can ensure conformance between a set of peer to peer services, and WS-CDL projected abstract BPEL processes can be used to ensure that executable BPEL processes comply with their expected local behaviour.