Message Correlation

So, I have been trying to figure out how asynchronous, reliable messaging in web services will occur at the wire level (not api). This seems like an easy enough task, however my small brain has been in overdrive trying to crack the nut.

Part of the problem seems to be the ambiguous use of the term 'message correlation' throughout the various specs. I'm now of the opinion that at least three levels of message correlation exist:

Correlation at the Business Process / 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 distincition 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.

** One other item of interest is that "retransmission" information is NOT sent in the ws-routing information. In theory, you would need this to increase reliability. One could guess that this was intentionally left out and in the ws-* fashion, reliability will become its own spec (think ws-reliability or ws-sla).