Summary
The value of CDL is that it takes us from art to engineering by ensuring good governance that is supported by tools throughout. It gets you to a solution much faster and more accurately with higher quality. It does this through formal validation of CDL descriptions against requirements, through monitoring of services against CDL descriptions and directed guidance of services construction through generation based on a CDL description. The formal tie in of a description to requirements and the linkage directly to monitoring and generation is what provides quality and time to market coupled with the level at which CDL as a description languages operates. WS-CDL (CDL) has been around now for some time. The Pi4SOA tool suite has found great favour among vertical standards (ISDA, ISO, TWIST, HL7 and many others). Researchers continue to plough a furrow towards ever more interesting analysis of CDL as well as looking towards son-of-CDL. With Redhat's announcement of their SOA governance project (Overlord) and the central role played by CDL and the Pi4SOA tool suite one could be forgiven for assuming that SOA platforms vendors and tool vendors show interest in CDL and are actively looking at working on it and providing it to their communities.
So why is this not the case?
Some of it is still rooted in the adverse and misleading publicity that CDL received at the hands of some analysts and many large vendors. The deliberate confusion created in the minds of the population at large through the BPEL vs CDL debate caused much damage and was founded on many many fallacies and misunderstandings. But perhaps the fundamental reason for the lack of tools from vendors is rooted in the classic question "show me the money".
Despite some large corporates asking for CDL tooling, vendors have not really provided anything at all. And so we are left with a few tools largely open source from smaller players.
The SOA platform vendors make their money on run times not on design so they are focussed on execution and not description. This is why VC's often say you cannot make money from tools. It is why Eclipse is open source. So Java, BPEL J2EE Application Servers, ESB's and all of that stuff is all about execution and the scale that run time brings to revenue for vendors.
CDL is a description language not an executable language. At first glance it is not clear where there is any revenue. It has no runtime component. It's value at first glance is in clean concise accurate descriptions of System Architectures in terms of their observable behavior and message exchanges. So it is all about design and not execution.
One might argue that WSDL is also a description and yet has value. But that value is entirely driven by its use in execution. To have Web Services a WSDL description is needed. The attendant software to type check, marshal and un-marshall operations and data and to ensure correct message exchange patterns are adhered to is all part of the run time machinery needed to use WSDL.
WSDL has another value in that it is a language to describe the technical contract of a single service. It might not capture behaviour but it does capture the functional footprint and data types that a service needs to be useful at all. But this value, as a contract, is not why SOA Platform vendors invest in WSDL. The reason they invest is because they can clearly see the value in their run time environments and so the revenue that accrues.
So what of CDL? As with WSDL, CDL is a very good language for describing all of the contracts needed for a set of services. It describes the collaborative contract that is, in effect, a System Architecture description. But that, as far as SOA Platform vendors would be concerned, does not generate sufficient revenue to justify investment.
On the other hand there are many UML vendors who provide design time tools that users do buy. So there is a value. IBM have Rational, Magic have Magic Draw and so on. But it is not a big revenue ticket business. It is niche.
CDL can play a role in the execution phase and this is where the key revenue value can be clearly seen. If we have a System Architecture description that described the externally observable behavior of services then we can monitor the run time services against that description. This technique is like BAM but is really BAM with teeth as we can measure what we observe against what we expect. The result is monitoring, or governing, services such that we can determine where problems exist based on an artefact that also governs the change of the system as whole and may be used to drive evolution. This is why CDL is a key part of Redhat's SOA Governance project called Overlord.
From a user perspective, that is some entity wishing to deliver a solution, the value is more profound. On one side CDL provides possibly the very first formalised way of delivering an artefact, the System Architecture description, that can be validated against requirements and so yields testable architecture. This artefact represents to TO-BE state of a system. On the other side a CDL description can be used to describe, in much the same way, the AS-IS state of the system. In this case the artefact can be validated by automated observation (monitoring) to ensure that it truly represent the AS-IS state. When there is no variance in the monitoring we have a stable AS-IS description.
So CDL provides a means of having testable System Architectures for a TO-BE description and provides a means of defining an AS-IS description and means of validating that description against an existing IT real estate.
Clearly the difference between the AS-IS and TO-BE state represents the scope of work to be carried out. Because CDL is a formal description, analysis to identify the gap, between AS-IS and TO-BE, is much easier, faster and can be supported by tools to ensure that the gap is correctly identified. Furthermore the changes to the AS-IS state can be managed over the lifetime of a programme of work with continuous real time governance, through monitoring, to ensure that the solution delivered is correct at all times.
The value of CDL, in a nutshell, as has been blogged before, is that it takes us from art to engineering by ensuring good governance, that is supported by tools throughout. It gets you to a solution much faster and more accurately with higher quality.
As Redhat start to use the monitoring aspects of CDL SOA vendors will inevitably move towards it and I would anticipate SOA Governance and BAM to settle on CDL.
