In the first half of this chapter, we explained how to invoke an asynchronous web service from a BPEL process instance. Hence, the BPEL process instance may remain active for a very long time. For example, a loan approval process may take weeks to be completed. If a BPEL process instance is expected to remain active for an undetermined period of time, the BPEL process itself should be deployed as an asynchronous process because the BPEL process also cannot reply back to its caller within a definite time period due to external asynchronous web service invocations, which happen within the BPEL process. In this section, we will model an asynchronous BPEL process and compare it with a synchronous BPEL process.
Oracle JDeveloper editor supports the creation of an asynchronous BPEL process via a predefined process definition template. You can create an asynchronous BPEL process with following steps:
Template is the most important option in order to create an asynchronous BPEL process. The Create BPEL Process window is shown in the following screenshot:
A synchronous BPEL process uses the <receive>
, <reply>
activity pair to receive the request from the caller and to send the response back to the caller, respectively. The <receive>
and <reply>
activities use a single WSDL two-way operation during a synchronous request response interaction. But for an asynchronous BPEL-process execution, we use a <receive>
and <invoke>
activity pair, as we have explained in the Understanding asynchronous service invocations section. But there are some differences which are as follows:
<invoke>
activity to send the request and it uses the <receive>
activity to capture the response from the external web service.<receive>
activity is used to capture the request from its caller to start execution within the BPEL process, and it uses the <invoke>
activity to send the response back to its caller.Thus, even though the mechanism of setting up an asynchronous BPEL process and setting up an asynchronous web service invocation is similar, the semantics are a little bit different when it comes to the BPEL activity which is responsible to handle the request and the response of the communication.
If you compare the request and response handling in a synchronous and an asynchronous BPEL process, you will realize the only difference is that the synchronous BPEL process uses the <receive>
and <reply>
activities to handle the initial request and final response from the BPEL process and the asynchronous BPEL process uses the <receive>
-<invoke>
activities to handle the initial request and final response.
Thus, the synchronous BPEL process uses a <reply>
activity to send the response to its caller, and the asynchronous BPEL process uses a <invoke>
to send the response to its caller.
So why can't we use the <reply>
activity instead of the <invoke>
activity in both cases?
This is because, based on the WS-BPEL 2.0 specification, the <reply>
activity can be used only for synchronous communication. In case of an asynchronous communication, the <invoke>
activity always has to be used.
Improve the sample BPEL process such that it asynchronously invokes the search services to bookstores A and B. Then, improve it such that the BPEL process also can be invoked asynchronously.
Q1. What are the types of WSDL operations that can be used for an asynchronous communication?
Q2. Based on what characteristic of the messages, does the BPEL runtime figure out the correlation between the outgoing request message and the incoming response message?
Q3. How many <receive>
activities can be there with the createInstance
attribute value set to yes
, in a working BPEL process?
Q4. Explain why is it not intuitive to invoke an asynchronous web service from a synchronous BPEL process.