WS-Choreography Definition Language (WS-CDL)
This working group is hosted by the
The current draft can be found
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
gave at the first face to face meeting of the WS-Choreography group
as an invited expert. Here is a paper
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.
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
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
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.
(This figure was generated from the current WS-CDL.xsd
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
- token: this is basically a variable of the
choreography bound to a document content
- tokenLocator: this is a condition expression,
expressed in XPath
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 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.
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
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
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.
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
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
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.
examples and schema