Concept: Service Composition and Choreography
This concept describes the ways services can be combined to yield composite and collaborative structures which provide new higher-level, business-oriented services.
Relationships
Main Description

Introduction

One key aspect of Service-Oriented Architecture (SOA) is that services be composable, which means that a new service is often composed as a collaboration between a set of existing services. In many respects this is true of existing component-based and object-oriented techniques, except that certain capabilities in the middleware being used to develop service-oriented solutions allows the direct execution of these collaborations through standards such as Business Process Execution Language for Web Services (BPEL4WS, WS-BPEL or just BPEL). It is this ability to compose services structurally, that is to define the usage dependencies between services, and also to compose services behaviorally that makes a services-based architecture and IT strategy attractive to so many organizations.

More and more organizations are realizing the need for increased agility in their ability to respond to changing business environments, whether it's the pressure of globalization, new markets and channels, or simply new competitors using technology more efficiently. These organizations are looking towards service-oriented development and service-oriented solutions as a way to organize their IT assets to address current requirements and provide an infrastructure of business-aligned functions that can be reused, reconfigured, and recombined efficiently and effectively to address future requirements.

Another aspect of the ability to compose services in this manner is that it provides a flexible way to incorporate existing IT assets into new solutions in the same manner as newer assets. For example, existing assets, even those developed for mainframe platforms and similar, can be exposed as services with some middleware products and integrated in the same way as new services developed using JEE, IBM WebSphere or Microsoft .NET. Unfortunately, most existing assets tend not to be developed with interfaces that adhere to much of the guidance we would use for new services. As such, it is useful to create composite services that do not just wrap these existing services, but rather provide different, more business-aligned interfaces that leverage the existing functions by aggregating and choreographing them to provide the higher-level capability.

Service Choreography

The term, Choreography, is used in many middleware products to denote the managed execution of some script denoting a process flow, where the participants are services and the tasks are message exchanges. In some products, the term Orchestration is used. While some industry analysts and technologists describe differences in the meaning of the words and how these terms are used in standards, for most users the differences are much less interesting than the similarities.

In terms of standards, a common way to represent the choreography of Web Services was late in coming, after most of the leading middleware vendors introduced proprietary solutions. The current industry standard is the Business Process Execution Language for Web Services (WS-BPEL, BPEL4WS, or simply BPEL). For more information on WS-BPEL, see the Wikipedia article on Business Process Execution Language or the IBM BPEL site.

Services as Composite Structures

Services can easily be developed upon the functions provided by other services in a recursive manner, as shown in the diagram below, where services can identify those services they rely upon. In this case, an instance of the OrderProcessor Participant is using services provided by instances of the Invoicer, Productions, and Shipper Participants to implement the operations provided by its Purchasing service.  These four instances are assembled by the Manufacturer Participant, which delegates its implementation of Purchasing to the OrderProcessor instance.   As an unshown detail, the processPurchaseOrder operation of the Purchasing service provides entry to the realization of a Purchase Order processing business process.

Composite services often are used where the usual factoring of service capabilities identifies common functions that can be provided in more than one circumstance. For some services, where the role is more to provide infrastructure capabilities, this is relatively easy to identify. In other cases, detailed service collaborations will identify the need to split a candidate service into more than one actual service.

Figure 1.  Example of a composite service

 

One important use of composite services is to provision functions realized by existing (legacy) assets. In many cases, such functions are accessed using connectors or APIs provided by the asset itself, and a new service is developed which relies on these assets for some logic. In some cases, an alternative strategy can be used to enable the aggregate component to evolve more flexibly and to permit the existing asset to be swapped out in the future for a different implementation.  In this alternative approach, each existing function is exposed as an independent service.  These services are then used by the composite service.  This strategy enables both the existing assets and the composite services to evolve independently.

This latter approach can have some drawbacks. If the low-level services that realize the composite can be exposed only by using Internet protocols such as SOAP/HTTP, they are likely to be less reliable and have poorer performance than if they are accessed using a native API or connector. These tradeoffs have to be a part of the general set of architectural decisions made and documented as part of any service design.

A composite service also can be used when the set of services to be leveraged by the composite is not known completely. For example, consider an order management service.  We might identify the need to separate out order validation as a separate set of independent business rule services, such that new rules can be added later. This is related to the topic of service mediation (see Concept: Service Mediation).

Service Collaborations

We use the notions of service collaborations, ServiceContracts, and ServicesArchitectures to support modeling the behavior of composite services.

  • During Service Identification and early in Service Specification, we use collaboration between Interfaces, ServiceInterfaces, and/or Capabilities as an analysis-level tool to describe the roles, high-level responsibilities, and communication patterns of services.  
  • We continue using collaborations during Service Specification to help derive the detailed specifications of ServiceInterfaces, including the operation signatures and the messaging protocols that providing and consuming Participants must follow during their interactions.  If the collaboration involves a single provider and a single consumer, it is straightforward to have it be an owned behavior of the ServiceInterface, itself.   If the collaboration involves a provider and multiple consumers, it is best to represent this as a formal ServiceContract.
  • The collaboration of the community of Participants that is involved in realizing the composite's service operations can be described using a ServicesArchitecture. 

The ServicesArchitecture includes a composite structure, as well as a behavior denoting the messages exchanged and their sequencing.

The composite structure can be used to show the following types of information:

  • The instances of the Participants that are involved in the collaboration;
  • The run-time connections between the instances, described using ServiceChannels; and
  • The ServiceContracts between each sub-community of interacting instances.

The earlier composite structure diagram for the Manufacturer Participant provided a view of the collaborating instances and their run-time connections, 

The following composite structure diagram, Figure 2, shows an alternative rendering for Manufacturer.  This is a structure diagram for the ServicesArchitecture for Purchase Order Process, which the constituent parts of Manufacturer collectively realize.  Here, we see the Participant instances involved in the process and the ServiceContracts that they must abide by.  The larger rectangular parts within the ServicesArchitecture represent the instances of the Participants that collaborate to realize the business process.  The dashed ovals represent the ServiceContracts that govern the interactions between Participants.  The dashed lines between the ovals and the ServicePoints/RequestPoints that are on each Participant define the roles that each Participant plays in a ServiceContract.

Figure 2.  Composite structure for Manufacturer ServicesArchitecture

  

In the context of service solution design, the notion of Service Collaboration is analogous to the notion of choreography in web services terms. It represents a configurable, externalized flow description sequencing a set of message exchanges between services. In most middleware implementing choreography, the flow is described in an XML language such as BPEL. Such a language could be generated from the service collaboration described in the Artifact: Service Model when the flow itself is described with UML 2 Activities or Interactions.

Specifying Service Behavior

As was stated above, a Collaboration -- be it a UML Collaboration, a ServiceContract, or a ServicesArchitecture -- shows both the structure and the behavior of the interacting instances.  It is most common to use either UML 2 Activities or Interactions, specifically Sequence Diagrams, to describe the flow of messages between instances in a collaboration. The diagram below is a UML 2 Activity Diagram demonstrating the behaviors of the four Participant instances that are involved in realizing the Purchase Order Process.  This specific diagram is owned by the Purchase Order Process ServicesArchitecture.  It is usual to build a similar behavioral diagram for each service operation that is realized. These behaviors are owned by the Participant that realizes the pertinent service operation.

Figure 3.  Activity diagram for Purchase Order Process

 

Specifying Service Bindings

The bindings (actual physical protocols and message encodings) used to communicate between services are properties of the service channel itself.  The bindings used between services have significant impact on non-functional requirements such as performance, reliability, and security. So, the available choices need to be documented with the consequences of each identified within the overall system architecture. For example, it might be that one use of service partitions (described using Participant notation) is to represent allowable or required binding between services within the partition.  A common requirement is that services within some logical zone communicate using a high-performance, proprietary binding, whereas communication with services outside of the zone uses lower-performing, but standardized, bindings.

Kind in mind that, even though Web services present a simple model and a set of simple, flexible protocols, you are not restricted to these choices. Just as WSDL already has bindings for both SOAP and HTTP GET/PUT, it is important to provide requesters with additional choices. For example, a single service can expose a message using a message-queue binding and a SOAP binding, so the requester can choose the more appropriate binding to use. In this case, the provider might also provide incentives, such as a guaranteed service level if the message queue is used, but no service guarantees for an HTTP conversation. 

More Information