Web Services Choreography Description Language (WS-CDL)

WS-CDL is in my opinion an example of premature standardization. WS-CDL provides multiple layers of abstraction, an enormous set of features and a simulation based design. Personally I think a purely declarative approach with little or no abstraction that focuses on making it easy to describe basic stuff would have been better. I don't know which position, mine or WS-CDL's, or which mid-point between the positions is right but I'm pretty sure that no one else does either. We just don't have enough industry experience to standardize choreography descriptions. Unfortunately the potential standardization of WS-CDL can do real harm as it will likely freeze the experimentation and learning that the industry so badly needs.

I believe that choreography is one of the critical missing pieces in SOA. Trying to design a composite application made up of 10 or 20 services using a few diagrams and text is at best a futile act. What's needed is a choreography description language (CDL), a declarative syntax that can capture in a standardized form who the services are, what messages they will exchange and in what order. The point of a CDL is to augment a spec, not replace it.1

Unfortunately WS-CDL is not a CDL, it is more accurately described as a Web Services Simulation Language. In essence WS-CDL is a full fledged programming language with variables (four flavors in fact), exceptions, expressions, final blocks, composition, inheritance, looping, state synchronization, etc. Near as I can tell it's actually Turing complete. However a simulation language is exactly what isn't needed, in my opinion, by the vast majority of people trying to create composite applications. In fact, I'd argue that a simulation language like WS-CDL can cause real harm to good SOA design. It will cause people to write their requirements in code instead of words. Unfortunately code doesn't carry the depth of meaning that text does which means that there won't be a real understanding of what drove the requirements the code is attempt to represent. The end result will be brittle composite applications that will implode as soon as any changes are made to the component services because those changes will more than likely violate the code in the simulator (although not the underlying requirements). In other words, I believe WS-CDL encourages tight coupling.

Of course one can always write 'abstract' WS-CDL documents which leave out bits and pieces of the code but this is a poor substitute for a real CDL. First, WS-CDL really wants you to provide the details. Second, even basic choreographies are painful to describe in WS-CDL. For example, because WS-CDL wants to be able to handle every conceivable contingency it has decided that it won't actually bind itself to WSDL directly. Instead it introduces its own abstraction layer where you have to repeat the WSDL information or at least give new names to existing WSDL constructs in order to use them in WS-CDL. For example, you can't use just refer to a WSDL 2.0 interface in a WS-CDL definition, instead you create a behavior with a new name that itself can point to the interface. The upside is that you can use things other than WSDL with WS-CDL. The downside is that if you just wanted to use WSDL you have to pay for the abstraction layer that you neither wanted nor needed. The bottom line is that even if one does create a profile of WS-CDL and removes the more dangerous parts one is still left with many layers of frequently unnecessary abstraction that interferes with design.

It's really unfortunate that WS-CDL happened in a standards committee. In a better world WS-CDL would be the product of some private consortium of companies or perhaps an open source effort who would put it out as a concept piece to be examined, experimented with and eventually either accepted, rejected or recycled into new proposals. As an experiment in defining a standard language for simulating choreographies I think WS-CDL has much to recommend it. As a choreography language, I think it went down the wrong track.

I believe that the standardization of WS-CDL by the W3C (if it happens) may cause real harm to the industry. Much as with XML Schema or WSDL 1.12, the appearance of a premature standard will drive customer demand for that standard and therefore kill off mainstream efforts to gain the industry experience needed to meet the criteria for a good standard.

1I actually wrote a white paper that I submitted to the Web Service Choreography Working Group when it was formed that explains in detail, with examples, background, etc. what I think a CDL is.

2I know, I know, WSDL 1.1 is not a W3C standard. It is actually W3C note with no real standards status. But I can count on the fingers of one hand the number of customers I've met who understood and/or cared about the difference.

4 thoughts on “Web Services Choreography Description Language (WS-CDL)”

  1. I totally agree, we need a muh more declarative solution. BPSS is unfortunatelly too heavy on the message site and enforces a very strict state model, but it comes much closer at defining boundaries, timeouts and shared state.

    Actually thats the important thing, to analyse a business protocol or a composed serice behaviour, you want to find the critical points where multiple services in the choreograhy may disagree about their state and intended outcome. Exactly those conditions are easier described if you dont have programming model which is nearly impossible to be analysed. Especially with all those side effects introduced by variables.

    This is BTW the exact same reason why I dont think Abstract BPEL is a good thing for defining protocols.

    Gruss
    Bernd

  2. I agree completely with the abstract BPEL comment. In my mind the only use for an abstract BPEL is as a code skeleton to create a non-abstract BPEL.

    What I’m worried about is that people might try to use WS-CDL for protocol design rather than just for simulation. That would lead people to do dangerous things like rely on WS-CDL’s state alignment features. By externalizing state alignment from the protocol messages you signifigantly increase the chance that the protocol designer will toast their performance by introducing extra round trips. You also guaranteed a badly designed protocol because a well design protocol should provide state alignment as a direct consequence of the messages themselves, not as separate meta-data.

    Sigh, I’m not looking forward to the mess WS-CDL is bequeathing us.

  3. I guess it comes as no shock that I disagree. And I guess it comes as no surprise that I suggest such comments be made to the WG of which you were an active member. There was a review period of which you (both) were informed. But my records suggest we had no comments at all from either of you at that point.

    You may or may not have a valid point but I don’t see the same point being made about BPEL which could also be said to be jumping the gun given it has been very much vendor and not user led.

    We can, in the Choreography WG, at least cite user communities who we have actively enaged with to ensure that the work is directed at solving their problems.

    I hope that both of you actually try to build stuff using WS-CDL. It really isn’t that hard to do when you have tools to help – and they are available. I don’t think anyone has ever suggested coding directly in WS-CDL’s XML representation. You might even be pleasantly surprised.

    As to all of the other criticisms I’d like them to be put to the WG rather than aired here first. At least that way, if we failed to address them, you would have the moral high ground. Alas at this point you have little to stand on.

    Shame given the active contributions of the past.

  4. To be fair I did present these comments to the working group and even spent the time to fully explain them in the white paper I linked to in the article above. In fact, as I understand it, the term WS-CDL was taken from my white paper. In addition I attended both the Oracle & AttachMate F2F meetings of the group and argued strongly in favor of the position I lay out in both the white paper and this article.

    To understand why I subsequently withdrew from the group one has to understand the dynamics of a standards group, especially one that is doing fundamental design (always, I suspect, a bad idea) rather than just standardizing existing practice.

    In a group doing fundamental design there tend to be two sources of power – Companies you have to keep happy because they are so ridiculously powerful (e.g. IBM and MS in BPEL) and people willing to put in sweat equity.

    Nick, from Oracle, fell into the later camp. He and I talked and he has a very different vision of what WS-CDL should be then I do. We were unable to come to any kind of consensus on the right approach. Once I realized that Oracle was going to fund Nick to the point where he could work on WS-CDL full time I approached my management and gave them a choice.

    We could either have me working more or less full time on BPEL and use my sweat equity there to make sure the group went in the direction we wanted or we could do the same for WS-CDL. What we couldn’t do is both (alas, cloning doesn’t work yet). From a business perspective the decision was trivial – BPEL won and I dropped off WS-CDL.

    To be clear, Nick was very willing to listening to my concerns. He just disagreed and frankly I can understand why he disagreed. We approach the problem from very different view points. But in the end he was willing to spend as much time as it took to get his points accepted and from a business perspective I couldn’t justify matching his time investment.

    Later on, btw, when the spec was getting ready for final review Steve Ross-Talbot directly contacted me to get a review. I didn’t see much point in doing a review since the spec had diverged so widely from the direction I thought it should take and sending in a long list of comments repeating points I’d already made to the group in the past didn’t seem very productive. But in the end it didn’t matter, at the time of the review I was completely snowed under in work and there was simply no time available to do a review.

    In regards to BPEL, I have said many times that I feel BPEL is outrageously premature. In an ideal world BPEL wouldn’t have happened for at least another five or maybe ten years. But unfortunately politics doesn’t always work in the best interests of the industry. Given who was behind BPEL and their power over customers we were left with no option but to at least make sure BPEL was designed in a manner that favored our interests.

    As for your comment that WS-CDL’s format isn’t too hard to use if you have tools to help I would recall the following post I sent to the BPEL list on the same subject :

    I remember in the late 1980s when everyone argued that source code was dead and all programs would be written using UIs.

    I remember the early 1990s when everyone argued that no one would ever directly author HTML.

    I also remember the late 1990s when everyone (myself included =( ) argued that it didn’t matter if XML was human editable since everyone would use tools.

    It’s funny how often everyone is wrong.

    Just a thought,
    Yaron

Leave a Reply

Your email address will not be published.