Time for action – implementing an asynchronous invocation

Let's take a look at how to implement an asynchronous service invocation where the asynchronous web service is represented by the following WSDL: http://svn.wso2.org/repos/wso2/carbon/platform/trunk/products/bps/modules/samples/product/src/main/resources/bpel/2.0/SampleAsynchronousProcess/Async-Server/ServerArtifacts.wsdl.

Download this external service WSDL representation.

Creating an empty WS BPEL 2.0 process

Here, we will create an empty WS BPEL 2.0 process with the Synchronous BPEL Process template, as shown in the following screenshot:

Creating an empty WS BPEL 2.0 process

Click on OK once you provide the other necessary details such as name, namespace, and directory. Then the initial BPEL process appears in the development environment. In the next step, we will create two partner links required for an asynchronous communication.

Defining the partner link with myRole and partnerRole

Here we are going to define the partner link which represents the asynchronous communication between the BPEL process and the external web service. First drag-and-drop a partner link to the Partner Links area of the canvas. Then, a form pops up. This form is used to configure the partner link. Perform the following steps to configure the partner link that was created:

  1. Name the partner link AsynchPartnerLink.
  2. Use the SOA Resource Browser icon shown in the following screenshot to locate the WSDL which represents the external web service:
    Defining the partner link with myRole and partnerRole

    Once this is done, the WSDL will automatically get copied to the project as well.

  3. Now for an asynchronous web service invocation, this partner link should have two channels which are represented by roles in the BPEL world. Choose the partner link type which has two roles. In our case, there is a partner link type called Server which has two roles called ServerProvider and ServerRequester.
  4. Now, we have to determine which roles represent the outbound (request) communication and inbound (response) communication:
    1. Select ServerProvider as the Partner Role. This is because ServerProvider represents a port type which in turn represents the operation that is exposed by the external web service.
    2. Select ServerRequester as My Role, as shown in the following screenshot. ServerRequester represents a port type which in turn represents the operation that is invoked by the external web service to send back the result. In the BPEL world, we call it the callback and that is discussed in the later sections in this chapter.
      Defining the partner link with myRole and partnerRole
    3. Click on Apply and then on OK.

Defining the invoke activity

In the previous steps, we showed how to add and configure the partner link properly. Now we can add the invoke activity that is used to invoke the external web service asynchronously via the previously defined partner link:

  1. Drag-and-drop the invoke activity from the activity palette to the design area:
    Defining the invoke activity
  2. Double-click on the invoke activity and a form pops up to configure the invoke activity parameters:
    Defining the invoke activity

    Here you can configure Partner Link, Port Type, and Operation as follows:

    • Partner Link to AsynchPartnerLink
    • Port Type to Server
    • Operation to initiate

    These parameters point to the operation at the external web service which accepts the request message.

  3. Then, set the input variable, which represents the request message to the external web service. The input variable name is AsynchInvoke_initiate_InputVariable. Then click on Apply and then on OK.

Defining the receive activity

Now we need to configure the activity that accepts the response message from the external web service. This can be done by the <receive> activity. The <pick> activity can also be used to receive an asynchronous response even though it's not discussed at this point. Follow these steps to define a receive activity:

  1. Drag a receive activity from the palette to the design area. Make sure to add the receive activity after the invoke activity we added in the previous step, as shown:
    Defining the receive activity
  2. Then double-click on the receive activity to configure the parameters:
    Defining the receive activity
  3. Here you can configure Partner Link, Port Type, and Operation as follows:
    • Partner Link to AsynchPartnerLink
    • Port Type to ServerCallback
    • Operation to onResult

    These parameters point to the operation that is exposed by the BPEL service to accept the response message that is sent by the external web service.

  4. Then set the variable that represents the response message from the external web service. You can create a new variable to handle this response message. Let's add a new variable named AsynchReceive_onResult_InputVariable.
  5. Once the preceding steps are completed, the design will look like the following screenshot:
    Defining the receive activity
  6. At this point, both the <invoke> and <receive> activities are fully configured for an asynchronous invocation.

Now what is remaining is to set up the WSDL that represents the created BPEL process and to deploy the BPEL process.

What just happened?

In the previous section, we implemented an asynchronous invocation. In this section, we explain the concepts behind an asynchronous invocation and compared it with a synchronous invocation.

First we'll discuss how an asynchronous invocation happens and why it needs a callback. Then we'll explain the concept of correlation, which maps a request for a given response in an asynchronous invocation.

Based on the knowledge of the previous chapters, we can easily implement the sample BPEL process using synchronous invocations as well, but let's explore a little bit more on practical limitations of the implementation of this BPEL process. Let's specifically focus on the external service invocations as shown in the following screenshot:

What just happened?

The Request-Response interaction during a synchronous invocation

During each invocation, the BPEL runtime acts as a client for the particular invocation and this client expects to retrieve the response of the service invocations within a predefined time. If the response is not returned within that time period, BPEL runtime declare it to be an error due to service invocation and takes the necessary actions. But in the real world, we don't know when the external services will return their output back to the BPEL process. So this scenario leads to potential service timeouts and consequently it leads the BPEL process to an erroneous state as the expected data from external services is not available. So the big question is, how we can avoid such nondeterministic service timeouts?

This problem can be easily solved by a modification to the service invocations that are implemented in the BPEL process. The modification is to redefine the external service invocation using two communication channels to handle request and response separately. Consequently, the BPEL runtime does not expect the response from external service invocations within a predefined time. Ultimately, the BPEL process now handles external service invocations in a more loosely coupled and reliable manner (refer to the following screenshot).

What just happened?

Request-Response interaction during an asynchronous invocation

Tip

In a nutshell, asynchronous invocation is useful for external services which takes a long time to process the request and respond back to the BPEL process.

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

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