WS-Choreography Definition Language (WS-CDL)
This working group is hosted by the W3C.
The current draft can be found here. The working group is scheduled to complete its work in Q1 2005.
Here is a complete and clear presentation directly from the author of WS-CDL.
Here is the presentation I gave at the first face to face meeting of the WS-Choreography group as an invited expert. Here is a paper I wrote about "choreography" and its relationship to BPM in July 2002. I have created a more sophisticated example relating choreography, BPEL and BPM in this presentation or my commentary on BPEL-J.
Commentary
The working group has defined a very precise articulation between orchestration (BPEL) and choreography. While "BPEL is a programming language to specify the behavior of a participant in a choreography [...] choreography is concerned with describing the message interchanges between participants. Participants of a choreography are peers, there is no center of control". A choreography definition can be used at design time by a participant to verify that its internal processes will enable it to participate appropriately in the choreography. It can also be used to generate a public interface (e.g. abstract BPEL) that can be used to tie in internal activities to support the choreography. At run-time, the choreography definition can be used to verify that everything is proceeding according to plan. It can also be used unilaterally to detect exceptions (a message was expected but not received, or help a participant in preventing it sending messages in the wrong order or at the wrong time).
I have been very happy to see the group going in this direction because this was my recommendation -as an invited expert- to the working group during the first face to face meeting in march 2003.
Please, take a look as this article [BPEL-J] if you need more details on the topic. After working for four years on the ebXML BPSS specification this does not appear like rocket science to me, but I guess that it is great that more people understand the distinction between the two concepts. It is also rather incredible that the WS-CHOR working group is adopting the same language (e.g. talks about "collaboration"), I hope this signals a possible alignment between the two groups.
The group is working with the pi-calculus research community to model the concept choreography (Solos Calculus). Lots of progress seem to be underway. Some pi "gurus" pretended that the concept of choreography was already included in the pi-calculus, and therefore was irrelevant.
WS-CDL vs BEPL
Frankly, the examples that have been used by the BPEL community have been so basic that it is easy to discard the concept of choreography: if all you have is 3 services talking to each other: an orchestration, a composition or a choreography look exactly the same (and you probably don't need a spec to deal with these use cases). The day I'll see the BPEL definition of a business process for build-to-order cars, I will believe that BPEL is a business process related language, until then I think the BPEL tenors ought to show some contrition (BTW, I don't think I'll ever see either). So what's so different between BPEL and CDL?
- CDL provides a definition of the information formats being exchanged by ALL participants, BPEL provides the information formats exchanged by one participant.
- CDL provides the global message exchange between participants without a specific point of view, BPEL provides the message exchange from the point of view of one participant
- CDL provides "reactive" rules that are used by each participant to compute the state of the choreography and infer which message exchange will/can happen next. BPEL specifies "active" rules that are executed to infer what to do next, once the rule is computed, the orchestration run-time executes the corresponding activity(ies).
In addition, CDL offers a model for specifying a common understanding of a message exchange (it this message exchange happens, we agree that we will both be in the state of "OrderSent" for instance). BPEL has no such concept, just as if "State" was not an integral part of business process modeling and execution. I'll come back on state later.
Incidentally, I disagree with Nick when he says you can generate logic from a CDL and not from a BPEL. Nothing prevents me to take a BPEL and create a Java class that will perform like a BPEL engine executing the BPEL definition.
At the end of the day, yes, it is true, BPEL can describe two types of choreographies: master/slave and unilateral. Master/Slave is the case where the orchestrator controls everything and all other participants interact only with him and not between themselves (true peer-to-peer fashion). The unilateral case, is when every participant decides to describe its own view of the choreography. If they are designed in complete isolation what is the likelihood they would match? zero.
Now if the interfaces are designed to work together, you still have to create the sum of all the participant interface definition in order to define the the global view and understand the behavior of the choreography . This is what WSCI suggested in its time and thank god, WS-CHOR quickly buried it.
In the real world, these two types of choreographies are rare. In addition, if you are a "master" you may not want to publicly disclose all your internal behavior just because you need a choreography definition. Bottom line, using BPEL to express choreographies is a very bad idea, it does not work often and when it works it is awkward. I feel sorry that the BPEL group has defended this position for so long because it is untenable.
WS-CDL specifies protocols
Business (Order Management) and Technical protocols (Transaction) alike can be modeled with WS-CDL. I believe that this is an answer to one of the requirement I had expressed in the working group, i.e. the possibility to clearly define a "protocol" like the ebXML BPSS Business Transaction Protocol that is used underlying the collaboration to ensure things like state alignment and non repudiation. Via composition, I believe that ebXML BPSS can be modeled by WS-CDL. Note that this is a desirable thing (at least from my perspective) and it does not weaken BPSS in any way. WS-CDL alone cannot guaranty interoperability between participants since it does provide a "choreography" protocol that can insure guaranteed state alignment between choreography participant. Note that this is not the role of WS-CDL to specify all possible technical protocols: there will be multiple specifications like BPSS that can leverage WS-CDL. WS-CDL demonstrates the layering that exist between the concepts of orchestration, choreography and collaboration.
WS-CDL Concepts
(This figure was generated from the current WS-CDL.xsd specification)
Information
WS-CDL is not only specifying the choreography of messages, but also, if necessary the type of messages being exchanged. A choreography is aware of some of the content of message exchanges via tokens and tokenLocators.
- informationType: aliases to WSDL types, XSD or other typing mechanism
- token: this is basically a variable of the choreography bound to a document content
- tokenLocator: this is a condition expression, expressed in XPath
Participants
This is the key of the WS-CDL specification.
- role: specifies the operations implemented by a given participant that will perform this role in the choreography. What is interesting is that a WSDL specification is not mandatory here. So WS-CDL is not a choreography of WSDLs but merely a choreography of operations that can be specified in some WSDL once the choreography is implemented.
- relationship: ultimately every choreography can be divided into a series of binaries relationships. A relationship expresses just that, the commitments of each participant to another.
- participant: a participant implements one or more role in the choreography (e.g. a distributor can be both a buyer and a seller in a choreography, using the same relationship definition with respect to its manufacturer or customers).
It is interesting that the choreography substrate is "outside WSDL". IMHO, it was not possible to "choreograph WSDL", only WSCI did it, but the result was that the choreography was hardly visible and understandable. Here, the group chose to define "operations" that are choreographed and later bound to a concrete WSDL. An operation is specified for each "interaction" (the object of choreography). From what I have see, it looks like the only operation that you can define in a role are request / response (inbound) to that role (I have asked the working group to confirm this conclusion but they did not feel appropriate to answer my question). Ultimately, I don't view it as a major problem because the request/response operations of someone are typically the solicit response operations for someone else and vice versa. However, it make it difficult to take an arbitrary WSDL and choreograph it but as I said earlier, I don't think this case is that common, the most common usage pattern is start with a choreography and create WSDLs for it.
For the record, ebXML BPSS does not force you to think at these two levels: operation and interaction. BPSS only defines interaction types -Business Transaction- (which can be used by any role), a type is then used as an Interaction Activity -Business Transaction Activity- that specifies the direction of message flow, and when you bind it to a physical participant, there is no ambiguity to who sends what. Note that in BPSS, a participant does not support an interface, it merely specifies that it supports a choreography (collaboration). This would be the equivalent of deprecating WSDL for WS-CDL. I have always argued that in a true peer-to-peer scenario, the concept of interface does not have much reality and is advantageously replaced by the concept of choreography.
Channels
What is important to realize, is that WSDL does not have an official correlation mechanism. As a matter of fact, WSDL does not even acknowledge the notion of instances of a service invocation. So even though WSDL lets you define groups of operations, it does not give you the tools to express how these operations are related. The goal of channel is to alleviate this severe limitation of WSDL.
I must admit, I still have trouble to grasp the intent of the author here. I guess I am a bit confused by the meaning of channel at run-time and design-time. What is clear, is that, by providing a channel passing mechanism, WS-CDL allows the possibility of participants of a choreography that may not all be known at the start of a choreography. BPSS does not supports that, and if I understand the necessity, I am not sure the authors of the specification measure all the implications of this capability on the architecture necessary to support this feature (how does the new participant gets notified of the current state of the choreography? how does this participant gain context?). From a pi-calculus perspective, a channel specifies where and how a message is to be communicated.
It looks like the correlation mechanism is specified as part of the channel via the identity element of the channel type.
ebXML BPSS does not have an explicit correlation mechanism. The correlation is done at the message service layer and is implicit (we never look at the content of a message for correlation) the ebXML infrastructure keeps track of that. If this is not as general as the WS community may like it, it is nevertheless the most efficient way of dealing with the problem. I cannot imagine the number of cross-references that will result in via explicit correlation where all participants ask all the other participants to carry their primary keys.
I believe that channels are an important mechanism to model something like BPSS because any two role communicate through two channels: a business channel where the business documents are exchanged and a technical channel to implement the business transaction protocol. In BPSS this technical channel is implicit and signals never appear in the collaboration definition.
Choreography
As I said earlier the substrate of the choreography are abstract request/response operations that are referenced by "interactions". An interaction must specify what relationship it is bound too.
In addition, WS-CDL has introduced the notion of "State" and make extravagant claims about "State Alignment". States are specified (as I understand it -though I cannot confirm it) via the record element:
where Source and Target represent the states of each party associated to the interaction. I repeat for the n-th time that state alignment cannot be achieved without a protocol (See this post). The other thing is that, WS-CDL notion of state is fragmented: say for a PO / AckPO interaction, there are two states, one for each role, POSent and POReceived. Asside from the fact that these two state can easily get out of synch (I sent a PO so I am in POSent state, while the supplier never received it and is still in PONotReceived state), it would be more appropriate to define a unique state associated to the interaction that is reached when the interaction is successful (for whatever it means).
The choreography definition is relatively classic:
It has the good old sequence / parallel / choice construct, along with assign. Recursive composition is achieved with the perform element. I really like the concept of a work unit that groups interactions in meaningful ways (e.g. for error handling).
So we are we?
Orchestration vs Choreography, I think the debate is closed. I am a bit puzzled at how companies like IBM and Microsoft can continue ignoring this specification much longer, they run the risk of making their SOA and BPM strategy falling behind. I do hope they don't come with a competing spec and decide to join the working group before it ends.
The spec is decent though quite naive about the notion of State. It is remarkable enough that finally this notion has been introduced and that someone talks about state alignment in the web service community. But again, IBM and Microsoft seem to completely ignore the problem. As I said earlier, the problem is interoperability, of course you can always make it work through ad hoc conventions and policies -creating an extremely tight coupling between your services.
With respect to WSDL and WS-CDL, it will probably be difficult to explain to the users why they cannot start with a WSDL and "choreograph it". There is nothing wrong with the approach of the working group, it is merely the fact that in a multi-party peer-to-peer interaction scenario, an arbitrary set of interfaces does not necessarily lead to a possible collaboration.
If progress is made on the formalism of choreography with respect to pi-calculus that will give it tremendous weight for simulation.
We are still far from done. The spec remains fairly theoretical and does not even hint an architecture to implement it. For the record ebXML BPSS was published with a collaboration definition, a state alignment and non repudiation business transaction protocol and an architecture (BSI) in 2001. I am wondering if the working group is considering at pointing at BPSS for these minor details.
Overall, the BPM space is making huge progress this spring. The release of BPMN and WS-CDL signals a profound inflection in our ability to move in the right direction for both modeling and execution. The second half of 2004 should be fascinating when we put all the pieces together: BPMN, WS-CDL, BPEL, WS-CAF and BPSS.
References
http://developer.net.au/news/business+news/w3c+targets+web+services.asp
