Databases Reference
In-Depth Information
<wsa:RelatesTo>urn:62772860C2DE8F6A0634D09B</wsa:RelatesTo>
<wsa:ReplyTo>
<wsa:Address>
http://www.w3.org/2005/08/addressing/anonymous
</wsa:Address>
<wsa:ReferenceParameters>
<ins:tracking.conversationId>…</ins:tracking.conversationId>
<ins:tracking.parentComponentInstanceId>…
</ins:tracking.parentComponentInstanceId>
</wsa:ReferenceParameters>
</wsa:ReplyTo>
</env:Header>
<env:Body>
…
</env:Body>
</env:Envelope>
The first one of interest is
wsa:To
. This will contain the address specified in the
wsa:ReplyTo
endpoint reference of our request reference, which allows the Service
Infrastructure to route the response to the appropriate endpoint.
In addition, if we look at the message above, we can see that the property
<wsa:RelatesTo>
contains the value of
wsa:MessageId
specified in the original
request. It's this value that enables the endpoint to correlate the response back to the
original request. In our case, this enables the BPEL engine to route the response from
Process B
back to the instance of
Process A
, which sent the original request.
In the preceding example, it's quite feasible for
Process A
and
Process
B
to send multiple messages to each other. Any further exchange of
messages between the two process instances will just contain the same
<wsa:RelatesTo>
property within the SOAP header.
Using BPEL correlation sets
For situations where WS-Addressing isn't appropriate or available, BPEL provides
the concept of correlation sets. Essentially, correlation sets allow you to use one or
more fields present in the body of all correlated messages (for example,
orderId
)
to act as a pseudo conversation ID (equivalent to the
<wsa:MessageID>
and
<wsa:RelatesTo>
properties in WS-Addressing).
