Correlation

One of the fundamental requirements for exchanging information via Web services is the ability to persist context and state across the delivery of multiple messages. Because a service-oriented communications framework is inherently loosely coupled, there is no intrinsic mechanism for associating messages exchanged under a common context or as part of a common activity. Even the execution of a simple request-response message exchange pattern provides no built-in means of automatically associating the response message with the original request.

Correlation addresses this issue by requiring that related messages contain some common value that services can identify to establish their relationship with each other or with the overall task they are participating in (Figure 7.18). The specifications that realize this simple concept provide different manners of implementation. We therefore dedicate the following section to explaining what correlation is and comparing how it is implemented by some of the WS-* extensions we've covered so far.

Figure 7.18. Correlation places the association of message exchanges into the hands of the message itself.

Note

For a look at how correlation typically is implemented as part of SOAP headers, see the examples provided in the WS-Addressing language basics section in Chapter 17.

In Plain English

To encourage repeat business, we introduce a promotion where, after ten visits to our car wash, your eleventh visit is free. We implement this promotion through the use of a punch card. Every time a customer drives in, we punch the driver's card. This card associates the current visit with all of the previous visits. Essentially, the punch card provides us with a form of correlation. Without it we would have a very hard time remembering which customers had visited us before.

 

7.3.1. Correlation in abstract

To establish a neutral point of reference, let's start with a very basic description of correlation without any reference to its implementation. In tightly bound communication frameworks the issue of correlated units of communication (individual transmissions) rarely arose. The technology that enabled tightly bound communication between components, databases, and legacy applications typically established an active connection that persisted for the duration of a given business activity (or longer). Because the connection remained active, context was inherently present, and correlation between individual transmissions of data was intrinsically managed by the technology protocol itself.

Things change dramatically when you fiddle with the coupling, however. When one stateless service sends a message to another, it loses control of the message and preserves no context of the activity in which the message is participating. It is up to the message to introduce the concept of correlation to provide services with the ability to associate a message with others.

This is achieved by embedding a value in the message that is propagated to all related messages. When a service processes a message and locates this value, it can establish a form of context, in that it can be used to associate this message with others. The nature of the context can vary. For example, a message could be part of a simple exchange activity, an atomic transaction, or a long running orchestration.

Let's now take a look at how correlation is achieved within some of the composition environments we covered in Chapter 6 and the messaging extensions discussed so far in this chapter.

7.3.2. Correlation in MEPs and activities

Because they are generic and non-business-specific in nature, MEPs and activities have no predefined notion of correlation. They are simple, conceptual building blocks incorporated and assembled by either custom-developed solutions that employ custom correlation identifiers and related processing logic or by specifications that impose proprietary forms of correlation (as described next).

7.3.3. Correlation in coordination

The context management framework provided by WS-Coordination establishes a sophisticated mechanism for propagating identifiers and context information between services. A separate activation service is responsible for creating new activities and subsequently generating and distributing corresponding context data. Services can forward this information to others that can use it to register for participation in the activity.

While context management uses a correlation-type identifier to uniquely represent a specific activity context, it goes well beyond correlation features to provide a comprehensive context management framework that can be leveraged through activity protocols, such as those supplied by the WS-AtomicTransaction and WS-BusinessActivity extensions.

7.3.4. Correlation in orchestration

WS-BPEL orchestrations need to concern themselves with the correlation of messages between process and partner services. This involves the added complexity of representing specific process instances within the correlation data. Further complicating this scenario is the fact that a single message may participate in multiple contexts, each identified by a separate correlation value.

To facilitate these requirements, the WS-BPEL specification defines specific syntax that allows for the creation of extensible correlation sets. These message properties can be dynamically added, deleted, and altered to reflect a wide variety of message exchange scenarios and environments.

7.3.5. Correlation in addressing

WS-Addressing's message id and relationship MI headers provide inherent correlation abilities, which can be leveraged by many composition and messaging extensions.

7.3.6. Correlation in reliable messaging

Every message that participates in a WS-ReliableMessaging sequence carries sequence information with it. This data consists of a sequence identifier that represents the series of messages required to follow the messaging rules of the sequence, along with a message identifier that identifies how the current message fits into the overall sequence. As a whole, this information can be considered correlation-related. However, its primary purpose is to support the enforcement of reliability rules.

7.3.7. Correlation and SOA

Correlation is a key contributor to preserving service autonomy and statelessness. Though simple by nature, the ability to tie messages together without requiring that services somehow manage this association is an important function of correlation, primarily because of how common message associations are in enterprise SOAs.

Case Study

The PO Submission Process we described in Chapter 6 consists of a complex activity involving the TLS Purchase Order and the RailCo Order Fulfillment Services. In our previous examples we explained how the path of the PO message can be determined and extended dynamically at runtime and how it spans multiple services.

For each service that receives the PO message to understand the context under which it should process the message contents, it needs to be able to differentiate the message from others. It accomplishes this by associating a unique value with the message. In this case, the message identifier used is a value partially auto-generated and partially derived from the message PO number.

SUMMARY OF KEY POINTS

• Correlation is a required part of any SOA, as it enables the persistence of activity context across multiple message exchanges, while preserving the loosely coupled nature of service-oriented solutions.
• WS-* specifications implement correlation in different ways, but many specifications increasingly are relying on WS-Addressing for a form of standardized correlation.
• Even though values from a message's content can be used for correlation purposes, SOAP headers are the most common location for correlation identifiers.
• Correlation is an essential part of messaging within SOA, as it preserves service statelessness and (to an extent) supports message autonomy.