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.
Here, we will create an empty WS BPEL 2.0 process with the Synchronous BPEL Process template, as shown in the following screenshot:
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.
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:
AsynchPartnerLink
.Once this is done, the WSDL will automatically get copied to the project as well.
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:
Here you can configure Partner Link, Port Type, and Operation as follows:
AsynchPartnerLink
These parameters point to the operation at the external web service which accepts the request message.
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:
AsynchPartnerLink
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.
<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.
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:
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).