Databases Reference
In-Depth Information
Correlating the callback
The first complexity this causes is that whenever a client submits a request to the
process via the
submitBid
operation, the BPEL engine, when sending a response,
will set the value of
<wsa:RelatesTo>
based on the header contained in the
initiateAuction
request (not the value in the
submitBid
request). So we can't use
WS-Addressing to correlate the response of the auction process back to the client.
Initially, the obvious answer might appear to be just to use the
auctionId
to correlate
the result of the bid back to the client. However, while the
auctionId
allows us to
uniquely identify a single instance of an auction, it doesn't allow us to uniquely
identify a bidder. This, may seem strange at first, but recall we may have several
clients calling the auction process at the same time, all waiting for a response. We
need to ensure that each response is returned to the appropriate instance.
Thus the calling client will need to pass a unique key in the
submitBid
request
message (for example,
bidId
) that the auction process can include in the response.
Assuming we are using BPEL to implement the client, we then need to implement a
correlation set based on this property in the calling process, so that the BPEL engine
can route the response to the appropriate instance of the client process.
Specifying the reply to address
The second complexity is that whenever a client submits a request to the auction
process, via the
submitBid
operation, the BPEL engine will ignore the
<wsa:replyTo>
and will attempt to send the reply to the client which initiated the auction.
This highlights the other issue, that our auction process supports two callbacks—one
to return the auction result, the other to return the bid result. Yet the reply to address
on the partner link is being fixed with the initial invocation of the process, forcing
both callbacks to be routed to the same endpoint, which is not what we want.
