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.
|