This chapter is from the book
This chapter is from the book
This chapter is from the book
7.3 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.
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.
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.