Sehmi-Conscious Thoughts

In my previous post I examined the business transaction pattern is some detail and made the case for using the pattern to much better implement a capability as a service (capsule). In this post I will develop the connection between the three part model introduced in [SS06] and propose how it can be extended to support the modeling of communication patterns. This requires a richer expression of a "service contract" to include the interaction sequence required to communicate with the service in addition to the conventional WSDL contract. The recent emergence of new technologies such as Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) present some interesting options for automating the generation of the conversation controllers necessary to support the service interaction.

Extending the Three Part Model

Traditional approaches to developing IT solutions frequently focus on two well-understood models—the business model which describes what the business does, and the technology model which describes one way of implementing the various business functions, as shown in Figure 4. However, this strategy frequently leads to close-coupling between the two models, resulting in dependencies between the technology model and the business model. This can cause brittleness if the business model changes, and can ultimately require that the technology model (and the implementation of the solution) be completely redeveloped as business circumstances change.

The prime reason for this is that Business and IT maintain their separate models within their respective domains. Business needs are conveyed largely by "tossing documents over the wall" – all too often confusing requirements with solutions. This has made IT adopt a very introverted view of itself, focusing on improving things that IT knows best, like availability, security and productivity, and not spending too much time contemplating how it can drive radical business change and add business value. IT solutions and platforms create technology silos that impose awkward constraints on the business model and as a result, business silos become reinforced by technology silos, and the whole system of Business plus IT becomes inflexible and arthritic - i.e. close-coupling. Thus Business and IT must work together to achieve common aims, but this is just not happening smoothly enough.

Figure 4. Traditional approach to modeling solutions

The Three Part Model attempts to eliminate as many of these dependencies as possible, enabling you to build solutions that can easily adapt as the business evolves and grows. It achieves this by introducing the Service Model. The service model enables you to abstract the business capabilities into one or more services, and then map these services to the technology model, as shown in Figure 5.

This simple idea lends a lot of value to the SOA vision which seeks not just to remove the gap between Business and IT but to blur the boundary between business processes and technology services. Essentially, SOA benefits by introducing the third service model element lying between the existing business model and the technology model. You might think that adding an intervening layer moves these models further apart, but actually the service model (and by implication, SOA) acts as a lubrication layer that allows the two models to flex and work together in greater harmony.

By imposing an intervening service layer, the business can focus strongly on defining levels of service rather than how those services are delivered. IT can in turn focus strongly on meeting contract obligations, choosing the best technologies and solutions for the circumstances, without unduly constraining the business process model. SOA naturally breaks down monolithic applications into finer-grained services which are more easily flexed and which can eliminate duplication. They are more easily aligned to business processes and help eradicate silo-based thinking. As a result, IT has to develop a much more outward-looking view. Instead of being led by the business IT strategy is driven by business needs. The promise of SOA is that it will lubricate brittle and static relationships and allow revitalized and agile businesses to gain a strong competitive edge.

Figure 5. Using the Service Model to remove dependencies between the Business and Technology Models

Using a service model facilitates discovery of services—the pieces of functionality implemented by the business—independently of any particular technology.

In Service Oriented Architecture terminology, the business capabilities identified by the business model have a very close correspondence to service contracts defined by the service model. Similarly, the business expectations (expressed as SLEs) translate to SLAs when the services are ultimately built and deployed, and so influences the choice of technology used to implement the services. For more information on the Three Part Model, refer to [SS06].

Describing Business Processes in the Service Model

However, breaking the business model down into a series of services only captures the business capabilities (what the business does), but does not provide information on the business processes that use these capabilities (how the business operates). To capture process information, the service model also needs to encapsulate how information and data flows between the various services. This requires extending the service model to include an orchestration mechanism that concisely and completely describes the way in which services interact, how they perform transactions, and how control passes between them. This in turn demands a mechanism to more richly express the definition of a service contract to include the message exchange patterns and the protocols that define the sequence of messages sent to and from the service.

While the structure and schemas of messages sent to and from the service can be adequately expressed by using WSDL, flow control is outside the scope of WSDL. Modeling this aspect requires either extending WSDL to include these semantics, or developing an additional WSDL-like grammar that can describe this information. This is the purpose of the SOAP Service Description Language—SSDL [SP01].

Like a WSDL contract, an SSDL contract defines schemas for describing data structures, messages, and endpoints. However, SSDL provides the basis for a range of protocol description frameworks extending those available in WSDL, including:

• The Message Exchange Patterns (MEP) framework representing the common, simple message exchange patterns available in WSDL (one-way, request with single response, request with multiple responses, and so forth).
• The Communicating Sequential Processes (CSP) framework, which enables a service contract to define multi-message interactions as a sequential process. CSP can describe systems in terms of processes that operate independently, and interact by passing messages to each other. CSP allows services to be defined both as sequential processes, and as the parallel composition of more primitive processes.
• The Rules-based SSDL Protocol framework, which uses Boolean expressions to specify the messages that a service can send and receive in response to other messages, according to the current state of the service. For example, a merchant service should only expect to receive a payment message after it has sent an invoice message, and not before.
• The Sequencing Constraints Protocol (SC) framework, which can describe complex, multi-party, multi-exchange sequences of messages with flow control, using a notation based on pi-calculus.

SSDL is currently a work-in-progress. The intention is to promote the development of tools such as model checkers that can verify the correctness of protocols defined in an SSDL contract and assess the compatibility of services, and also to enable hosting environments to validate the messages exchanged by services.

The Role of the Conversation Controller

A service host provides an environment for receiving messages and forwarding them to service instances, and for transmitting responses from service instances. The technology used to create the service host depends on the SLA requirements, the underlying network protocols, and a raft of other technological considerations. In addition, conversational services require hosts that can implement and enforce the rules governing the message exchanges defined by the SSDL contracts specified for those services. This leads to the requirement for the service host to incorporate a conversation controller component.

The conversation controller is essentially a state machine that drives the interactions with the services. Current SOA technology, such as ASP.Net and WCF, provide tools that can analyse a WSDL description of a service and automate the generation of code that can send and receive messages to and from a service. The next goal is to extend this notion and add a capability to generate code that automatically controls the flow of messages, according to the semantics defined by an SSDL description.

Automating the Conversation Controller

To briefly recap, to automate the generation of a conversation controller that can automatically handle the desired message exchange pattern required to communicate successfully with a service you need to know two things:

• The schema of the messages sent to and received from the service. This is generally available as WSDL metadata.
• The required conversation protocol. This defines the set and sequence of messages required to communicate with the service. WSDL does not convey this information and a different set of metadata such as that prescribed by SSDL is required.

The availability of tools for generating code from an SSDL description is currently very limited. However, Microsoft Windows Workflow Foundation (WF) and Microsoft Windows Communication Foundation (WCF) provide technologies that we can use to implement an alternative approach to define the conversation protocol. This approach uses a workflow to model the service message interaction rather than an SSDL description. It is possible to introspect the workflow metadata to derive behaviour metadata (also in the form of a workflow) that a client can use to control its conversation with the service.

The high level architecture of a prototype solution based on WF and WCF is shown in Figure 6.

Figure 6. High Level Architecture

The main components of the prototype solution are:

1. A state machine WF workflow exposed as a WCF service. The workflow implements the business logic for the solution. The workflow contains custom receive and send message activities in addition to regular activities used to coordinate the service's internal implementation logic. This workflow acts as a substitute for the SSDL description of the service.
2. A custom WCF service host called WorkflowServiceHost. The state machine workflow is hosted by a custom WCF service host. This is used to dynamically generate the service implementation based on introspection of the hosted workflow.
3. Custom workflow activities to send messages and to receive messages. These activities (SendMessage and ReceiveMessage) are part of the WorkflowServiceHost implementation.
4. Auto-generated behaviour metadata that models the required message interaction. The prototype implementation outputs a XOML-based sequential workflow. It consists of the activities, ReceiveMessage and SendMessage, contained in the state machine workflow but does not include any other activity that might be used as part of the service's internal implementation. In this way, the XOML generated workflow is used to model the message interaction behaviour required to successfully communicate with the service.
5. A client consumer of the WCF service. The client can use the behaviour metadata (the XOML workflow) emitted by the service to direct the desired sequence of messages that must be sent to and received from the service.

[ Note: I know that the above prototype solution probably ought to be re-implemented in .NET 3.5 using the new Workflow Services. No time on my hands unfortunately. Volunteers always welcomed! ]