Right. Of course, some ESBs may be able to do well in this area, possibly tying this with governance.

Just like there is no single distributed programming model/protocol, I would argue that there won’t/can’t be a single formal description language to describe interactions between systems. WS-CDL can only do so much. Just like UML did not fix all the modeling problems!

“So, it seems a RESTful CDL would
- describe the ordering constraints of a particular media type’s anchors
- provide a language to help a user agent track long-lived client-side variables as it crawls across representations.
- handle more than XML-based interaction”

Possibly. If someone claims to have a universal description/orchestration language, they better include resource-oriented systems, or whatever we come up with in future as well. IMO, that is going to be a limitation with most service composition-level specifications. They can only formalize certain aspects of certain distributed systems, but unfortunately claims don’t stop there. Instead of saying that “okay, we understand what you are doing with REST, but sorry our technology does not deal with your systems”, they say “your approach is incomplete, and so use our approach for everything” (quotes mine).

Thanks for your thoughtful comments.

Subbu

A number of ways for monitor and/or enforce
- An application-layer network intermediary , particularly for CDL-enabling legacy services, like an ESB.
- A framework that augments intercepts calls at the framework level (i.e. inside Axis)
- Some code generation, taking it a bit further than WSDL already does
- A framework that will help pick “next possible steps” in the choreography, track variables, channels, etc. for you
- A framework that hooks into your WS stack to watch what you’re doing, perform correlation, etc.
- One also needs to ensure the services are “CDL-aware”, in that they need to pass channel references around, as a URI, or WS-Addressing, EPR, etc., and if they’re not already doing so with some kind of unique Message ID, this could be automated by a CDL framework.

I think most of the toolkits opt for the “Framework-level” proxy instead of the “network-level” proxy to insert CDL policy. Or, in other words, they’re not building an ESB, they’re building an Axis-wrapper.

During the standards process, I recall there was contention about the necessity of BPEL vs. CDL because it is hard to see the difference at a high level when “enforcing” a CDL: they’re both supported by implementation-level frameworks, and they’re both talking about describing business processes. People didn’t really get CDL’s nuance, hence why BPEL has taken off.

The difference, as I see it, is subtle:

- BPEL is really an *execution language* on a single node. The endpoints that BPEL talks to don’t need to know that the parent was implemented in Java, .NET, Ruby, or BPEL.

- Whereas CDL is not something executed, it’s more of a spec of control flow that is shared across all of the systems that interact with one another; while it can also indicate what “next steps” are required, like BPEL, it also has a declarative way to specify the detection of errors & throwing of exceptions to who isn’t playing by the rules *without* requiring a centralized orchestrator.

So you could think of CDL as being *both* an “interaction variance checker” and a “distributed process execution language”. The latter part is somewhat more controversial, obviously.

The Pi4Tech stuff, by the way, was started by Steve Ross-Talbot, who was probably the #1 public champion for WS-CDL (that I’ve seen), and was the chair of the W3C working group. I recall he has some very good reasons for popularizing this technology.

Anyway, Pi4SOA isn’t documented (at all), so you’d have to browse CVS to figure it out, along with the Sourceforge discussions.

Some discussions I found a bit enlightening:
http://sourceforge.net/forum/forum.php?thread_id=1515687&forum_id=419139

One area that interests me in CDL vs. REST: “Hypermedia as the engine of application state”, in the RESTful web, is how we construct interaction machines. To me, hypermedia already exhibits much of what we want in a choreography-driven SOA, in that it specifies the possible interactions at runtime, with ordering constraints and whether they’ll have side-effects or not (GET, PUT or POST) defined by the media type. The problem is that these are usually defined in a human-readable RFC or specification.

So, it seems a RESTful CDL would
- describe the ordering constraints of a particular media type’s anchors
- provide a language to help a user agent track long-lived client-side variables as it crawls across representations.
- handle more than XML-based interaction