Our first BPEL business process example was synchronous because this was the easiest case. However, in the real world, we will mostly use asynchronous processes. Most business processes are long running. It makes no sense for a client to wait (and be blocked) for the entire duration of the process. A much better alternative is to model the BPEL process as asynchronous. This means that the client invokes the process, and when the process completes, it performs a callback to the client. This has a few consequences:
- For the BPEL process to be able to perform a callback to the client, the client must be a service and implement a certain port type (usually defined by the BPEL process WSDL)
- The partner link type for the client will have to specify two roles
- The BPEL process will not
<reply>to the client. Rather it will<invoke>the callback
Let us now focus on our business process and modify it for asynchronous invocation, presented in the next sequence diagram. We have to perform the following steps:
- Modify the BPEL process WSDL, where the operation invoked by the client will now have only the input message.
- Define the client port type and the operation, which the BPEL process will invoke for the callback. We will do this in the WSDL of the BPEL process.
- Modify the partner link type, where we will add the second role.
- Modify the BPEL process specification. We have to modify the partner link and replace the
<reply>activity with an<invoke>.
The modified sequence diagram is shown as follows. It is very similar to the previous example, except that the initial travel request is asynchronous and the final answer is delivered as a callback.
The modified WSDL for the BPEL process will have to specify the TravelApprovalPT port type, which will now specify an input message only. It will also have to declare the ClientCallbackPT port type, used to return the result to the client (asynchronously, using a callback). This is shown in the following figure:
Let us first modify the TravelApprovalPT port type used for client interaction, which will now define only the input message:
... <portType name="TravelApprovalPT"> <operation name="TravelApproval"> <input message="tns:TravelRequestMessage" /> </operation> </portType> ...
Next we define the client callback port type (ClientCallbackPT) with the ClientCallback operation. The response message is TravelResponseMessage. Notice that the WSDL only specifies this port type, which is implemented by the client.
... <portType name="ClientCallbackPT"> <operation name="ClientCallback"> <input message="aln:TravelResponseMessage" /> </operation> </portType> ...
We need to modify the partner link type for the interaction with the BPEL process, called the travelLT link type. We have to add the second role, travelServiceCustomer, which characterizes the client to which the BPEL process will perform a callback on the ClientCallbackPT port type. This is done in the WSDL of the BPEL process:
<plnk:partnerLinkType name="travelLT"> <plnk:role name="travelService" portType="tns:TravelApprovalPT" /> <plnk:role name="travelServiceCustomer" portType="tns:ClientCallbackPT" /> </plnk:partnerLinkType>
Finally, we modify the BPEL process definition. Here we first have to modify the client partner link, where we have to specify the second role—the partnerRole. Here, this is travelServiceCustomer, which characterizes the BPEL process client.
<partnerLinks> <partnerLink name="client" partnerLinkType="trv:travelLT" myRole="travelService" partnerRole="travelServiceCustomer"/> ...
Next, we change the last activity of the BPEL process. We replace the<reply> activity with the<invoke> callback. For the callback, we use the client partner link and invoke the ClientCallback operation on the ClientCallbackPT port type. The message signature has not changed, so we use the same variable as before, TravelResponse.
...
<!-- Make a callback to the client --> <invoke name="SendResponse" partnerLink="client" portType="trv:ClientCallbackPT" operation="ClientCallback" inputVariable="TravelResponse" />
</sequence>
</process>
Our BPEL process is now asynchronous!
To execute a BPEL process, we need a runtime environment. In Chapter 1 we provided an overview of BPEL servers. Later chapters give a detailed description of the Oracle SOA Suite.
Note
You can download both the synchronous and asynchronous BPEL process examples with the corresponding services from http://www.packtpub.com. They can be deployed to the Oracle SOA Suite using JDeveloper. For more information on Oracle SOA Suite and JDeveloper, refer to Chapter 4.