|
Message Correlation is the concept of tying messages
together. Usually, it occurs when one service calls another service
asynchronously and passes in a unique correlation token. When
the invoked service finishes, it calls the initiating service
and passes back the original token. This allows the initiator
to correlate the two calls. This is common for the request
/ response message
exchange pattern.
Correlation at the Web Service Orchestration
Level
Imagine a WSO engine is running a single orchestration script,
however there are 50 instances of this 'process' in play. A WSO
engine must be able to take an in-bound message and correlate
it to the proper instance of the process. An example of this is
described in the BPEL4WS script titled, "Message Correlation".
Correlation at the SOAP Router Level
In a service network, documents are passed across enterprises.
Company A shouldn't care about the physical location of where
Service X is running inside of Company B. This abstraction takes
place in the SOAP router. It magically gets a SOAP document to
the right place by using internal routing tables and acts as a
proxy between domains. So, a service network will send a document
from A to B and potentially use multiple go-betweens (aka, intermediaries,
SOAP routers, etc.) as the transportation vehicle. Along the way
(or at the end) a fault may occur. If this happens, the service
network must be able to backtrack and send the fault code back
to the originator. This means that it must tell each Router that,
"I am message #968, please pass on that I failed." In this context,
message correlation is used by an intermediary to *dynamically
or statically* create a reverse path for the purpose of fault
notification.
|
Correlation at the SOAP Server Level
If SOAP Server (A) sends SOAP Server (B) a message (M1) in an
asynchronous fashion; it may want a response (M2) back (e.g. an
answer to a request). When (B) sends (M2) (the response) to (A),
(A) must be able to determine that (M2) correlates (is the response)
to (M1). It appears as thought this type of message correlation
also is taken care of by WS-Routing
(although I'm not sure). Unlike many network protocols, a service
network must be able to send asynchronous, bi-directional &
correlated, reliable messages without utilizing a virtual
circuit. The downside of this is that it means that any initiator
or receiver must be able to sniff the routing path to determine
where to send the message back. This seems to violate the distinction
between SOAP routing and SOAP serving, but it appears as though
it is a necessary evil. Thus, the reverse message path in WS-Routing
not only sends fault information but also provides the necessary
information for a SOAP server to send an 'application-level reply'
back to the initiator.
* Note that SOAP 1.2 clearly states that 'message
correlation' is out of scope for SOAP.
|
