CDL meets JBoss ....

Every one that knows me knows that I am a keen and avid supporter of WS-CDL in all of its guises. So I will not be blogging about its virtues today. Rather the more interesting topic is that of Redhat and JBoss and their use of WS-CDL to promote what might be called "open processes". I shall deal with what's going on first and talk about what "open processes" might mean second.

For several months Hattrick Software (and the Pi4 Technologies Foundation) have been engaged with Redhat's JBoss team through Mark Little to build the necessary integration between the current open source pi4soa project and JBossESB. The aim is to provide an out of the box easy to use and easy to understand way of creating large scale SOA solutions that may incorporate existing services as well as requiring new services to be constructed. The WS-CDL part of this, through the Pi4 Technologies SOA tool suite, supports a methodology - the one I have started blogging about and no doubt will continue to do so. What this combination of technologies will do is reduce the time it takes to construct large scale SOA solutions and ensure that they are correct with respect to the requirements that are used as input to design and build them.

I have been working with Mark Little on this project and we are all very excited because, possibly for the first time, we can see a road to delivering such systems that links requirements formally to design and so validates design against requirements before a line of code is written. It extends this traceability from requirements all the way through to construction and operation of such SOA systems ensuring that we can govern them against the requirements be they functional or non-functional. To our knowledge this has never been done before. Our collective aim is to move SOA solution building away from being an art and towards being an engineering discipline.

"Open Processes" takes advantage of this discipline and ensures that the SOA blueprint that is the design model of a system becomes a key artefact in construction and operation of systems. By so doing we free the code from the plumbing and enable migration from and to differing platforms. It would make it easy to take an existing system and then port it to a new platform simply through a few button presses and clicks.

Imagine you have an existing SOA system based on the International Big Mega company. If you could retro-fit the SOA blueprint to the existing system you bring it under control of this key artefact. You can do this by constructing the SOA blueprint and monitoring the existing system against that blueprint. When you are happy that it has captured everything you can switch generation and deployment to a new platform and so gain the freedom of process from any vendor lock-in. Equally you can do it based on new requirements and apply the same technique to existing services in your current platform thus ensuring that the new requirements are met and that the existing system continues to function even if you reuse some of the existing services. It brings service re-use to a new level and ensures processes (or systems) are really open.

We have had some success already moving an existing system from Axis to JBoss. It all took less than an hour to do but then again we did already have a SOA blueprint - which in and of itself took less than a week to construct.

We look forward to making this available. Not all of these features will be present first time around but many will. We intend to provide an open source version and a licensable enterprise version so that you folks out there can try before you commit. When it is made available later this quarter we look forward to you feedback.