Databases Reference
In-Depth Information
Message routing
The first task for the aggregator is to route bids through to the appropriate instance
of the auction process. As with our earlier
UserRegistration
example, we can use
a correlation set to route messages to the appropriate instance. In this example, we
will create a correlation set based on the element
auctionId
, which is included in the
message payload for
initiateAuction
and
submitBid
.
At first glance, this looks pretty straightforward, as we can use correlation sets for
aggregation in much the same way as we have already covered. However, this
scenario presents us with an additional complexity; which is that a single instance
of a BPEL process may receive multiple messages of the same type at approximately
the same time.
To manage this, we need to implement a queuing mechanism, so that we can
process each bid in turn before moving onto the next. This is achieved by
implementing the interaction between the client submitting the bid and the
auction process as asynchronous.
With asynchronous operations, BPEL saves received messages to the
BPEL delivery queue. The delivery service then handles the processing
of these messages; either instantiating a new process or correlating the
message to a
waiting
receive
or
onMessage
activity in an already
running process instance.
If a process is not ready to receive a message, then the message will
remain in the queue until the process is ready.
This introduces a number of complexities over our previous correlation example.
This is because a BPEL process can only support
one inbound Partner Link
(for
example, client), for which the BPEL engine generates a corresponding concrete
WSDL. This defines all operations that can be invoked against that BPEL process
(as well as any corresponding callbacks).
However, for any
single
instance of a BPEL process, the BPEL engine expects that
any requests received via that partner link will always be from the same client, so
upon receipt of the initial request,
initiateAuction
in the case of the auction process,
it sets the conversation ID and the reply to address based on that request. These
values are then fixed for the duration of that process.
