BPEL from CDL

WS-CDL and WS-BPEL both provide a way to describe how web services should collaborate. But the difference is that WS-CDL gives a global perspective the message exchange whilst the WS-BPEL provides a single participant's perspective.
As some are arguing I do not see a competition between these two specifications. Rather they must co-exist to describe services interactions properly.
Though, WS_CDL is designed to be used in conjunction with the WS-BPEL, one limitation of the WS-CDL specification is that a clear mapping with BPEL is missing. I agree that the intention of WS-CDL is not to be depend on WS=BPEL but there are advantages of having such a clear mapping.

1. Choreographies can be defined in WS-CDL first by business partners and then generate BPEL process stubs for each party
   
2. A party who’s having an internal business processes may need to publish the interface to its processes to attract business partners by generating the choreography. This could be done using a BPEL to CDL mapping.
   

From the engineering perspective such a mapping could be automated. Also such a defined approach would minimize the inconsistent mappings by different parties coming in to collaboration.
This paper presents how BPEL process definitions are derived from the global WS-CDL model. Authors have done this by defining a set of transformation rules.
For example

1. Each party participated in CDL choreography a separate BPEL stub is generated
   
2. One cdl:relationshipType maps to one bpel:partnerLinkType and the bpel:role with its bpel:portType is generated from the referenced cdl:roleType declaration
   
3. Generate separate property files for each cdl:roleType including only those bpel:properties that are relevant for a party.
   
4. BPEL basic activities are directly mapped to CDL basic activities
   
5. Work units in CDL are related to scopes in BPEL
   

The complete mapping is available in the section 5.
The paper addresses a much required issue by not altering the existing standards or without introducing new standard, which is a plus point. The approach seems straightforward and not requiring intermediated mapping like in the approach here[4] where the mapping is into Communicating Sequential Processes. Also authors have implemented a prototype of the mapping as a proof of concepts.
Saying that, one limitation of the paper is that there is no reference on how to verify the generated BPEL stubs over the original CDL. Generated stubs may be correct for the given example or could be verified manually for simple scenarios. But it is required to have a formal mechanism to verify more complex scenarios. That is not in future work section too. And the verification need to be integrated to the BPEL stub generation or it should be done after generating BPEL stubs but before the populating them with application logic.
Also it is not clear how the mapping from BPEL processes to CDL is done. Which also an interesting issue (as far as ROAD is concerned ). May be we might be able to complete that part. We can map several processes to a common choreography by projecting them over a ROAD Self Managed Composite. In other words by overlapping several processes we might be able to define the choreography. Syntactical transformations might use the same discussed in the paper. Sure need to think and discuss more about that.