CTO view

• A View from the CTO
• Behavioural Modelling and WS-CDL

'A' in SOA

To put the "A" in SOA what is needed is:
• a formal description of a system
• the structure of components and their inter-relationships

A choreography package may be viewed as an architectural blue-print for a system. This is possible as a complete choreography package precisely describes all the observable interactions of the system, and the state the system should exhibit should an observer wish to look down into the system and inspect the message exchanges and the observable state.

Hattrick Software A View from the CTO

CDL meets JBoss

9 January 2008

For several months Hattrick Software (and the Pi4 Technologies Foundation) have been engaged with Redhat. The aim is to provide an 'out of the box' easy to understand methodology supported by our CDL toolsuit working with the JBoss ESB to enable the creation of large scale SOA solutions that may incorporate existing services as well as enabling new services to be constructed. (http://jbossesb.blogspot.com/)

This combination of technologies (CDL and JBossESB) will reduce the time it takes to construct large-scale SOA solutions and ensure there is a formal the link between the SOA system requirements and the SOA system design, supported by a methodology that validates the design against the requirements before a line of code is written.

The objective is to enable an 'SOA Blueprint' to be generated with traceability from the design requirements all the way through to system construction and operation thus ensuring that system operation can be governed against the requirements.

Once this is achieved "Open Processes" become possible, whereby the code may be freed from the plumbing thus enabling code migration to and from differing platforms. We have already achieved this as we successfully moved an existing system from Axis to JBoss. This took less than an hour with the SOA blueprint taking less than a week to construct.

We look forward to making this available via Redhat later this quarter with the intention to firstly provide an open source version followed by the enterprise edition early in 2009.

A View from the CTO

25 October 2006

Overview

I have always found the term SOA (Service Oriented Architecture) to be somewhat of a misnomer. There is little about Architecture (the A) in SOA. The ‘A’ in SOA is really redundant. It is more a case of ‘SOD’ (Service Oriented Design) because there is nothing in SOA that provides anything with respect to architecture. There is no ‘A’ in SOA.

In practice SOA is a way of loosely coupling a collection of services that are implemented as Web Service or as Message(Event)-based services over some communications substrate (SOAP over HTTP or some form of JMS) that are expected to collaborate in order to achieve some goal.

Architecture

Why should this lack of Architecture be of any concern? To understand this we need to get to the bottom of what we mean by Architecture and how it may be applied to the notion of service and services. I would conjecture that it is very important because it fundamentally describes how services are to collaborate to achieve some goal. Without an Architecture we are simply piling bricks upon bricks with no overall picture of the space that they create and the dimensions that it occupies.

There are many definitions of what constitutes IT Architecture. The one I like most is from TOGAF, which in summary can be thought of as follows:

• A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
• The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.

WS-CDL as an Architectural Description

WS-CDL provides a grounded formal model of a system that enables it to be described at a suitable (externally observable behavior) architectural level in an unambiguous manner. Such a description needs to be capable of describing the boundaries between services and the way in which they need to interact but without describing in detail how they might work internally.  To paraphrase the previous section we need something that describes the dimensions of the system and the space it created that needs to be filled. This is exactly what WS-CDL provides. It enables systems of services to be described in terms of their externally observable interactions and how these interactions should be ordered and this in turn enables the boundaries of the services to be determined precisely. The boundaries of a service are described in terms of the messages that they can send and receive and the operations that result in messages being exchanged and the order in which these can occur.

The system description (the global view) needs to be a set of ordered interactions in which the order captures sequence, parallelism, choice, loops, conditionality and dependency. Because the description is at a system level (again the global view) conditions and choices need to be situated. That is the conditions need to be told where to happen (i.e. which service is master of the condition and which are subservient to its outcome). All of these features are present in WS-CDL.

WS-CDL provides a global description of a system that comprises set of services. Thus global behavior can be described. The formal grounding of WS-CDL enables the service contracts to be projected out of the global model to give local structure and so deliver the local external behavior of services that is guaranteed to meet the global model requirements exactly.

WS-CDL tools can then simulate, using use cases of sends and receives, against the description to ensure that it works correctly and just as importantly fails when messages are received out of order.

WS-CDL tools can also be used to generate the state machines for one or more of the services where the state machines define the ordering of sends and receives at a service level. Business logic (the bit that fills in the space in an Architecture) can then be added to the state machines to implement the non-observable behavior.

The ability to simulate a choreography as a giant state machine or indeed generate and deploy state machines representing a system provides a unique ability to exercise a description of a system as well as providing a means of building one (through service state machine generation). In this way WS-CDL provides, for the first time, a means of describing the Architecture of a system in which that system does not have any embodiment (there are no services) or indeed if it is partially or fully manifested (one or more or all services have been implemented). In any of these cases the description can be used to monitor what the system actually does and compare against the WS-CDL description. This latter point provides a means of continual real time governance of the system against it’s Architectural description.

In summary WS-CDL delivers the capability to put the “A” back into SOA by offering simulation, continual monitoring and generation against a standards based formally grounded specification language.