Behavioural Modelling and WS-CDL
14 December 2006
We model business processes in order to enable our businesses to scale, to exert automated control over the business process, to manage risk in the event of a process failure, to efficiently manage change to the business process, and to ensure that the executing processes reflect what was anticipated to occur.
Since the early 1990’s there have been many attempts at encoding business processes to achieve these goals. The first attempts back in the early 1990’s ensured we could automate and exert control but suffered from vendor lock-in as the available solutions were vendor specific and not standards driven. These solutions also suffered from high integration costs due to the absence of standardised practices to wrap existing system and present these in a unified manner. Equally these solutions exhibited a centralisation of control due to the need to run in a centralised server. This increased operational risk when distribution was needed to ensure that some of the activities could operate without the need to report back to a centralised orchestrator.
In the latter part of the 1990’s the Work Flow Management Coalition (WFMC) standards group was formed. The remit of WFMC was to standardise on the description of workflows (business processes) to enable interoperability of the description of the workflows. This removed part of the vendor lock-in as regards description but did nothing to remove the problems of integration. Users were still bound to specific vendors as their legacy applications were still bound to the workflow using proprietary solutions. It also failed to tackle the problems of failure applied to a single point of control because the solutions were all based around an orchestration process and failed to tackle the problem of change management for business processes that were long lived.
In 2002 IBM came up with the Web Service Flow Language (WSFL) and Microsoft came up with Xlang for Biztalk. These two proprietary offerings were joined in the development of Business Process Execution Language (BPEL) in 2003. BPEL solved the problem of integration by utilising Web Service standards (WSDL and SOAP) to make legacy integration part of the standards solution. The problems of centralisation of control through orchestration and the problems of change management of long lived business processes remained unsolved. The effect of these unsolved problems was to force solutions down a specific architectural corridor which increased operational risk through a single point of failure and made change management of the underlying processes and the business process description unwieldy.
Until the advent of WS-CDL in 2003 no-one had tackled the issue of scale and no-one had tackled the issue of change. BPEL (WS-BPEL as it is now called) still provided a server centric orchestration mechanism and so carried with it high costs of failure should the orchestrator be unavailable and provided little to manage change of the underlying processes or the description of the business process.
The centralisation of control ran counter to most notions of distribution which seek to reduce this risk by distributing control. During the latter part of the 1990’s most large institutions had already invested heavily in distribution. Only WS-CDL provided the necessary standard for description of a business process, utilised the prevailing standards (Web Services) for integration of legacy application and did so in an architectural neutral manner so that distribution could be preserved (and in WS-CDL’s case positively encouraged).
WS-CDL helps manage change by utilising a formal technique called bi-simulation. This technique enables a WS-CDL description to be statically analysed against the behaviour of the processes to determine what changes have been made that would render the system of processes un-interoperable. The same technique can be applied to legacy processes through monitoring and variances from the description can then be readily identified and reported. This ability to bi-simulate ensures that changes to processes can be better managed and reduce the risk of failure in the system of processes when changes need to be made.
Furthermore up until the advent of WS-CDL no standard had effectively addressed the fundamental issues of describing business processes in a manner that enabled the description to be formally reasoned over - which resulted in business processes, so described, being prove-ably free from deadlocks, livelocks and race conditions – all of which are common in distributed systems.
The technique that is used to describe business processes using WS-CDL is called “Behavioural Modelling”. It is a technique that concentrates on describing the collaborative behaviour of a set of services or application in terms of the messages that these pass to each other to enact specific activities or computation. It is akin to the same process of organisational delegation in which a manager delegates a task by passing a message with enough information to subordinates to enact the activities required to achieve a business goal. The way in which this may be achieved by people is neither hierarchical nor static in dynamic organisations.
