Message Correlation
In messaging systems it is often a requirement to group
together, or correlate, messages that are related to one another. Messages can
be assigned a specific property, usually known as a correlation identifier,
which is set to the same value in all related messages.
When sending and receiving emails we use the email subject
as a loose form of correlation identifier. We send an email message with a
subject of “Help!”, and hopefully receive responses with a subject of “Re:
Help!”.
In BizTalk Server correlation sets are initialized and
followed when correlating messages in orchestrations. Every BizTalk developer
knows that you must specify at least one already-initialized correlation set
for a non-activation receive that is on a non-selfcorrelating port.
The Enterprise Integration Patterns website provides a description of
the Correlation Identifier pattern here.
|
There are two common scenarios where correlation is used in
messaging systems. The first one is when implementing a request-reply messaging
pattern using asynchronous queues. As queues only support one-way messaging
there is a need for the sender of the request messages to correlate the
response messages to the appropriate requests. The sender can send Request1,
then Request2 and then Request3 and receive Response2, then Response3, and then
Response1. There are also likely to be scenarios where a number of applications
have sent request operations to a particular queue and are all waiting for
response messages on another queue. A correlation identifier is needed to ensure
that the correct messages are received by the correct applications.
The Enterprise Integration Patterns website provides a description of
the Request-Reply pattern here.
|
A second scenario where message correlation is commonly used
is when processing a sequence of messages using an aggregator pattern. Examples
of this could be receiving a sequence of RFID messages for a particular
shipment and aggregating them to generate an invoice, or reassembling a large
document that was split into a sequence of smaller messages for transmission
over a queue. Just as with the request-reply scenario the receiving application
will need to correlate the messages in the shipment or document together based
on some correlation identifier.
The Enterprise Integration Patterns website provides a description of
the Aggregator pattern here.
|
Implementations of the request-reply and aggregator patterns
will be discussed in the Request-Response Communication, Sessions and Handling
Large Messages sections later in this section.