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.