Databases Reference
In-Depth Information
From a decision perspective, a key driver as to which to choose is the length of time
it takes for
Process B
to service the request, as asynchronous messaging supports far
longer processing times. In general, once the time it takes for
Process B
to
return a response goes above 30 seconds, you should consider switching to
asynchronous messaging.
With potentially many instances of
Process A
and
Process B
running at the same time, BPEL needs to ensure that each reply
is matched (or correlated) to the appropriate request. By default,
BPEL uses WS-Addressing to achieve this. We look at this in more
detail in
Chapter 16
,
Message Interaction Patterns
.
One way messaging
A variation of asynchronous messaging is one way messaging (also known as fire
and forget). This involves a single message being sent from the calling process, with
no response being returned.
If we look at the following screenshot, you will notice that just like the asynchronous
request,
Process A
uses the
<invoke>
activity to send a message to
Process B
.
Once
Process A
has sent the message, it continues processing until it completes, that
is, it never stops to wait for a response from
Process B
. Similarly,
Process
B
, upon
receipt of the message, continues processing until it has completed and never sends
any response back to
Process
A
.
A simple composite service
Despite the fact that BPEL is intended primarily for writing long running processes,
it also provides an excellent way to build a composite service, that is, a service that is
assembled from other services.
Let's take a simple example: say I have a service that gives me the stock quote for
a specified company, and that I also have a service that gives me the exchange rate
between two currencies. I can use BPEL to combine these two services and provide
a service that gives the stock quote for a company in the currency of my choice.
