Databases Reference
In-Depth Information
Theoretically,
Process B
could take as long as it wants before sending a reply, but
typically
Process A
will only wait for a short time (for example, 30 seconds) before
it times out the
<invoke>
operation under the assumption that something has
gone wrong. Thus, if
Process B
is going to take a substantial period of time before
replying, then you should model the exchange as an Asynchronous Send-Receive
(refer to the following section).
Asynchronous messaging
With asynchronous messaging, the key difference is that once the caller has sent the
request, the send operation will return immediately, and the BPEL process may then
continue with additional activities until it is ready to receive the reply. At this point,
the process will block until it receives the reply (which may already be there).
If we look at the following screenshot, you will notice that just like the synchronous
request
Process A
uses the
<invoke>
activity to call an asynchronous web service.
However, the difference is that it doesn't block waiting for a response, rather it
continues processing until it is ready to process the response. It then receives this
using the
<receive>
activity.
Conversely,
Process B
uses a
<receive>
activity to receive the initial request and an
<invoke>
activity to send back the corresponding response.
While at a logical level, there is little difference between synchronous and
asynchronous messaging (especially if there are no activities between the
<invoke>
and
<receive>
activity in
Process A
), at a technical level there is a key difference.
This is because with asynchronous messaging, we have two
<invoke>
,
<receive>
pairs, each corresponding to a separate web service operation. One is for the request
and the other is for the reply.
