Time for action – creating an asynchronous BPEL process

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:

  1. Navigate to File | New | From Gallery…. A form up called New Gallery pops up.
  2. Select SOA Tier from the Categories list and then select Service Components.
  3. Now, the Items list shows a set of available service component options. Select BPEL Process and click on OK, as shown:
    Time for action – creating an asynchronous BPEL process
  4. Then, a new form named Create BPEL Process pops up. This form lets you configure the initial template of the BPEL process. Select the following options:
    • BPEL 2.0 Specification
    • Name to Asynch_BPEL_Process
    • Template to Asynchronous BPEL Process
    • The other options are set automatically based on the template

    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:

    Time for action – creating an asynchronous BPEL process
  5. Then the initial asynchronous BPEL process is created and you can see the workflow from the design area as follows:
    Time for action – creating an asynchronous BPEL process
  6. Once you initialize the output variable in invoke activity, the BPEL process can be tested for its asynchronous functionality.

What just happened?

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:

  • An asynchronous web service invocation uses the <invoke> activity to send the request and it uses the <receive> activity to capture the response from the external web service.
  • In an asynchronous BPEL process, the <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.

Using the <invoke> activity instead of <reply>

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.

Have a go hero – an asynchronous BPEL process with asynchronous service invocations

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.

Pop quiz

Q1. What are the types of WSDL operations that can be used for an asynchronous communication?

  1. Solicit-response
  2. One-way
  3. Request-response
  4. Notification

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?

  1. One
  2. Two
  3. Any number

Q4. Explain why is it not intuitive to invoke an asynchronous web service from a synchronous BPEL process.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset