Putting the 'A' back into SOA with WS-CDL

Putting the ‘A’ back into SOA with WS-CDL

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.

In this blog I shall examine what is meant by Architecture and offer a means of retro-fitting Architecture to a system of services using WS-CDL as the description language as well as using such a description as a continual form of governance.

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.

Last year I attended an Architecture Summit in London. The great and the good turned up from Rod Johnston, to John Davies to Matthew Rawlings to Floyd Marinescu to Alexis Richardson and many more. We talked for two days about architecture what it means and what it’s purpose is with respect to software system.

I went into that summit with a view on Architecture and came out with a different view, one that is more refined and one that is suggestive of tools and technologies that can be employed to help define an Architecture.

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.

During the Architecture Summit I penned the following 9 principles of software architecture, the aim is that if you follow them you significantly reduce the risk of project failure:

1. Plan and organize – with no plan and no organization you will fail.
2. You have the right to say NO – don’t blindly say yes to all requirements because some may be impossible to meet so say NO when it cannot be done.
3. Simulate or be damned – if you cannot simulate the system you need to build you clearly do not understand enough about what is should do.
4. Global externally observable behavior describes the contract for a system – if you have an overall description of a system in terms of its externally observable behavior then you have a description of the dimensions and space defined by the description. This is the Architecture for the system.
5. Local externally observable behavior describes the contract for a component – the local externally observable behavior describes the public functional interface and the order in which those functions may be called. This forms the basis for any service contract.
6. Local externally observable behavior must be completely derivable from global behavior – if you have a global description then the local externally observable behavior should be completely derivable from it.
7. Establish the design principles – without design principles you will end up having a patchwork quilt to maintain at the start so get them established up front and make sure that they are in line with the overall performance requirements.
8. Establish the design constraints – systems always have constraints. They may vary but often cost and available components are amongst them.
9. Architecting is a continuous process – never stop Architecting. Requirements are continually added and there is a constant need to understand what the impact of new requirements are on an existing system. With a global description it should be possible to examine the effect of change.

WS-CDL as an Architectural description
Of the 9 principles 3 to 6 are supported directly by WS-CDL. 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 enables tools vendors (of which the Pi4 Technologies Foundation is one and Hattrick Software another) to deliver the capability to put the “A” back into SOA by offering simulation, continual monitoring and generation against a standards based formally grounded specification language.