Over the years we've seen a few discussions around WS-CDL. For instance Gregor Hohpe mentioned it in the context of coversations, and there are at least two implementations of it in the wild. But unlike it's distant cousin WS-BPEL, WS-CDL has not been able to catch the imagination (and hype curve). Which is a shame because as we commented earlier:
As Jeff Schneider said:
As Jeff Schneider said:
The original WS-CDL specification was less than impressive, however, the concepts were right on. I haven't gone back to revisit the specs but I will. It will take people some time to understand the fundamental 'centralization' problem associated with BPEL. Until then, alternatives will largely be ignored.Or as Charlton Barretto commented:
CDL enables the business stake holder, the business analyst, the enterprise architect and the application engineer to share their views of the same system in a synchronised fashion, by providing the means for each level of detail for each stake holder to be captured without that detail being necessarily exposed to the others. Also CDL provides the necessary provenance to enforce requirements at each level. In this fashion, CDL also enables the A in SOA, since it provides the manner in which architecture can be modelled, described and implemented.Well Steve Ross-Talbot has come up with an interesting analogy to try to help things. As he says:
Possible the most important invention that gave rise to the industrial revolution and which Stevenson failed to patent was the micrometer. Stevenson was notorious for inventing things and not patenting them. So the inventor of the micrometer was William Gascoigne in the 17th century. It was directly responsible for the engineering discipline in constructing the steam engine and in constructing the Enfield rifle that was used during the civil war in the United States.As Steve points out, the micrometer removed ambiguity in the engineering process and hence enabled precise engineering techniques that ultimately lead to industrialisation and allowed components to be manufactured separately "... with bullets being made in one place and gun barrels in another." Steve goes on to suggest that WS-CDL is the IT equivalent of the micrometer for the same reasons, in that it defines a way of precisely talking and reasoning about services.
... before a line of code is cut the CDL description is shown to be valid against the requirements and to be correct in computational terms (i.e. free from live locks, dead locks and race conditions).CDL removes the ambiguity between implementation and requirements, allowing services to be designed and developed separately with the assurance that they can work together "as designed". What Steve is saying is that CDL is a necessary condition for service re-use. But will this help to persuade the sceptics, or are we in for a few more years in the Dark Ages?
Community comments
Perhaps the reason
by Jim Leonardo,
Re: Perhaps the reason
by Gary Brown,
top-down
by Gerald Loeffler,
Re: top-down
by Steve Ross-Talbot,
Perhaps the reason
by Jim Leonardo,
Your message is awaiting moderation. Thank you for participating in the discussion.
Is IT not industrializing because we have yet to see the Henry Ford or William Levitt of IT show up and tell us how to mass produce software.
One thing people seem to forget is that we don't build software anymore. We DESIGN software. We've had these things called compilers running around for a few years that do the actual mass production of instructions for us, we have to provide the blueprint in the form of code is all (go decompile a modern app if you don't believe me). Even though Ford came up with assembly line techniques, there's still a need for engineers to design the cars. Until every new application truly is a mash up of existing chunks of funcitonality and requires nothing new, we're not "Industrializing" IT.
All I'm saying is this isn't silver bullet territory, we get better and better at it, however there's a great big "BUT"... Society's tendancy to specialize means that despite all the marketing fluff we get from time to time, easier to use tools just means developers will do more. It doesn't mean that developers go away. It just means that the level of development they do is progressively higher level. How often do you write in assembly when you're in Enterprise Software development, hmmm?
top-down
by Gerald Loeffler,
Your message is awaiting moderation. Thank you for participating in the discussion.
we should acknowledge that choreography in general and WS-CDL in particular impose a decidedly top-down approach to service design. this is not a value statement, just an observation. (my personal value statement is that the rigor that WS-CDL introduces is an important ingredient to rational service design.) however, this top-down approach is in contrast to agile approaches to software development, which eschew up-front design and thus are inherently bottom-up.
many would say that the the services that WS-CDL deals with are a layer above what could be "grown" in an agile way. and there is a lot of truth in that: enterprise architecture is rarely agile. but my real argument is that WS-CDL's top-down approach is culturally alien in a world that has (rightly) learned to value agile approaches to software development.
cheers,
gerald
www.gerald-loeffler.net
Re: Perhaps the reason
by Gary Brown,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't think the article is saying that engineers are not required, whether to design the cars or the individual components. The point is that the removal of ambiguity made the assembly line possibly - as many engineers working in different locations could design and build their individual components, with the knowledge that once they went on to the assembly line they would all fit together perfectly.
If this was true, then we would all be driving around in Ford Model T ;-). Industrializing does not imply reusing existing components - it just enforces controls on the manufacturing process.
WS-CDL is not about enabling mass production, and therefore reusing existing chunks of functionality. It is about defining a high level multiparty contract that ensures that each part will integrate into the overall process correctly. This does not imply that each individual component is legacy - it simply defines the responsibilities required of that component. Whether the component is reused or designed/built from scratch is not relevant.
Re: top-down
by Steve Ross-Talbot,
Your message is awaiting moderation. Thank you for participating in the discussion.
On the issue of top-down duly acknowledged. It is top down. Anyone in the Enterprise Architecture domain will understand immediately that most of what we do at this level is top down. It incorporated bottom up too as we do not have the luxury of having green-field sites and have to deal with legacy - perhaps this middle out.
The world has learned to deal with uncertainly and agile is certainly one way of doing it - there are many others. But equally one would not want to do enterprise architecture in a completely agile manner. It would miss the point which is to impose some structure over what is to be done.
I would content strongly that top-down using CDL provides structural integrity and imposed necessary constraints. But it does so without preventing agile being used for implementation - which is where it belongs.
Having no top-down is as simply absurd. Equally having no agile is absurd too. Both top-down and bottom-up and middle out have validity through out the delivery of a solution (from business goals to delivery). The strength of CDL as Gary Brown points out is to define a multi-party contract. This provides the needed structural clarity of what is to be delivered without getting in the way of implementation. It does not tell you all you need to know but provides the interfaces and behavior of what is to be delivered and ensure all services will work by design. Surly no bad thing.
Through out the ages agile has been with us. A more top down structural approach is often imposed when evolution based on agile starts to drift away from high level business goals. For example city planning. Maintaining structural integrity over the long term is what ensures a business remains flexible. Bottom up agile methods ensure we can deliver point solutions without having a full specification.
Oddly enough most of the Enterprise Architecture find both agile and top-down (in some cases using CDL) familiar and supportive and not alien at all. Maybe it depends on your perspective. A Technical Architect or a developer may well find top-down (and so CDL) alien. But then it was never meant for them it just empowers them through the Enterprise Architect.