Simple CDL

[objectiser]

Currently Savara is caught between two stages in its evolution - the first being the introduction of the "testable architecture" concept based on the only choreography description language available (i.e. WS-CDL), and the second being the application of "testable architecture" to a more widely adopted standard that now incorporates choreography (i.e. BPMN2).

The problem is that the BPMN2 standard is not yet finalized - this should happen within the next couple of weeks. However that still leaves the time delay before suitable BPMN2 modelling tools become available - and possibly even longer before open source tools are available.

Therefore its possible that WS-CDL may play a role in Savara for some time. On that basis, I think we need to consider two options:

1) Continue to use the existing WS-CDL tools as they are now, and focus efforts on either building, collaborating or waiting on an open source BPMN2 modeller. The problem with this approach is that WS-CDL is not so widely adopted, or understood, and therefore there is a learning curve in terms of understanding the concepts.

2) The other approach is to see whether WS-CDL can be simplified in such a way that makes it suitable for its role in "testable architecture", but at the same time minimises the learning curve for new users.

In terms of option (2), its possible that unnecessary constructs such as Channel and Relationship Types could be removed. Maybe we don't even need to have Participant Types explicitly defined - just have a Participant Type automatically generated per Role Type.

Other constructs that could be removed are finalizers - the semantics of the finalization mechanism are not found in any endpoint execution language (e.g. BPEL or BPMN2), and unlikely to be implemented by services implemented in general programming languages (e.g. Java).

So just wanted to explore the potential for presenting a simplified CDL editor to uses - based on filtering out unnecessary constructs - as a means of reducing the learning curve.

It will be a separate issue to determine what constructs should be hidden in this simplified view, how much work would be involved in making the changes, and whether this is a worthwhile effort compared to option (1).

Comments welcome.

[jeffdelong]

I think 2 is a good approach. Simplification can be gained have the tooling generate defaults for most of the "unnecessary constructs". This is already done with the Role Types / Participant Types as well as with Channel Types. Also the URIToken and URITokenType are now automatically created, which is a simplification. It would be nice to be able to "hide" the channelTypes, except that the Identity Tokens must be associated with each Channel, and I don't see a way around that.

Filtering of the UI capabilities could be handled through a setting under Preferences - Choreography - Designer that controlled what was visible in the Designer (this could be similar to how Drools Flow can excludes certain node types from being displayed). So there could be a 'Basic" setting and an "Advanced Setting" where the basic setting only showed certain Activities in the Choreography Flows editor. For example, Assign, Finalize, No Action, Perform, and SIlent Action might not be under Basic. Not would Bind Participant, Bind Variable, Copy, Participant, or Record. Also under State there are a listing of Channel Variable that don't appear to provide useful information (User created Variables could be interesting though). This might not be displayed under the basic setting.

You might be able to do these things and not change the underlying model (i.e. it would still conform to WS-CDL), and still make it simpler to learn and use.

[objectiser]

Hi Jeff

Like your suggestion. I think we now have to understand what is the subset of CDL that should be supported in terms of representing protocols that can be checked for conformance against other artifacts (such as BPMN, BPEL, etc), and then within that scope, look at what levels make sense.

We can then provide warnings when other constructs, that can't be easily mapped onto other notations, have been used. But as you say, still support full CDL.

I'll have a think about the proposed levels, and make a suggestion on this thread later.

Regards

Gary