WSDL for the BPEL Process
The business travel BPEL process is exposed as a web service. We need to define the WSDL for it. The process will have to receive messages from its clients and return results. So it has to expose a port type that will be used by the client to start the process and get the reply. We define the
TravelApprovalPT port type with the TravelApproval operation:
We have already said that the BPEL process is synchronous. The TravelApproval operation will be synchronous request/response type:
<?xml version="1.0" encoding="utf-8" ?>
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:emp="http://packtpub.com/service/employee/"
xmlns:aln="http://packtpub.com/service/airline/"
xmlns:tns="http://packtpub.com/bpel/travel/"
targetNamespace="http://packtpub.com/bpel/travel/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
...
<portType name="TravelApprovalPT">
<operation name="TravelApproval">
<input message="tns:TravelRequestMessage" />
<output message="aln:TravelResponseMessage" />
</operation>
</portType>
...
We also have to define messages. The TravelRequestMessage consists of two parts:
• employee: The employee data, which we reuse from the employee travel status web service definition
• flightData: The flight data, which we reuse from the airline web service definition
...
<import namespace="http://packtpub.com/service/employee/"
location="./Employee.wsdl"/>
Chapter 3 <import namespace="http://packtpub.com/service/airline/"
location="./Airline.wsdl"/>
...
<message name="TravelRequestMessage">
<part name="employee" type="emp:EmployeeType" />
<part name="flightData" type="aln:FlightRequestType" />
</message>
...
For the output message, we use the same message used to return the flight information from the airline web service: the TravelResponseMessage defined in the aln namespace. This is reasonable, because the BPEL process will get the TravelResponseMessage from both airlines, select the most appropriate (the cheapest) and return the same message to the client. As we have already imported the Airline WSDL, we are done.
When writing the WSDL for the BPEL process we usually do not have to define the bindings (<binding>) and the service (<service>) sections. These are usually generated by the BPEL execution environment (BPEL server).
Before we can start writing the BPEL process, we still need to define partner link types.
Partner Link Types
Partner link types represent the interaction between a BPEL process and the involved parties, which includes the web services the BPEL process invokes and the client that invokes the BPEL process.
In our example, there are three different partners: the client, the employee travel status service, and the airline service. Ideally, each web service should define the corresponding partner link types (in the WSDL). In real-world scenarios, this may not be the case. Then we can wrap the partner web service with a WSDL that imports the WSDL of the web service and defines the partner link types.
Alternatively, we can define all partner links in the WSDL of the BPEL process. However, this is not recommended as it violates the principle of encapsulation.
We define three partner link types, each in the corresponding WSDL of the web service:
• travelLT: This is used to describe the interaction between the BPEL process client and the BPEL process itself. This interaction is synchronous. This partner link type is defined in the WSDL of the BPEL process.
T
• employeeLT: This is used to describe the interaction between the BPEL process and the Employee Travel Status web service. This interaction is synchronous too. This partner link type is defined in the WSDL of the Employee web service.
• flightLT: This describes the interaction between the BPEL process and the Airline web service. This interaction is asynchronous and the Airline web service invokes a callback on the BPEL process. This partner link type is defined in the WSDL of the Airline web service.
T
We already know that each partner link type can have one or two roles and for each role we must specify the portType it uses. For synchronous operations, there is a single role for each partner link type, because the operation is only invoked in a single direction.
For example, the client invokes the TravelApproval operation on the BPEL process. Because it is a synchronous operation, the client waits for completion and gets a response only after the operation is completed.
Note that if TravelApproval were an asynchronous callback operation, we would have to specify two roles. The first role would describe the invocation of the TravelApproval operation by the client. The second role would describe the invocation of a callback operation. This callback operation would be invoked by the BPEL process and would call the client to return the result. We will make our example process asynchronous later in this chapter. Please remember that there is an asynchronous relation between the BPEL process and the Airline web service.
As we have already figured out, we need three partner link types. The first two have to specify a single role, because they deal with synchronous operations. The third requires us to specify both roles, because it is asynchronous.
Partner link types are defined within a special namespace: http://schemas.xmlsoap.org/ws/
2003/05/partner-link/. The reference to this namespace has to be included first:
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:emp="http://packtpub.com/service/employee/"
xmlns:aln="http://packtpub.com/service/airline/"
xmlns:tns="http://packtpub.com/bpel/travel/"
targetNamespace="http://packtpub.com/bpel/travel/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/
partner-link/">
...
Now we can add the definitions for the partner link types. First, we define the travelLT link type in the BPEL process WSDL. This is used by clients to invoke the BPEL process. The only role required is the role of the travel service (our BPEL process). The client uses the
TravelApprovalPT port type to communicate with the BPEL service:
...
<plnk:partnerLinkType name="travelLT">
<plnk:role name="travelService">
<plnk:portType name="tns:TravelApprovalPT" />
</plnk:role>
</plnk:partnerLinkType>
...
The second link type is employeeLT. It is used to describe the communication between the BPEL process and the Employee Travel Status web service and is defined in the WSDL of the Employee web service. The interaction is synchronous, so we need a single role, called
T
employeeTravelStatusService. The BPEL process uses the EmployeeTravelStatusPTT on the Employee web service:
...
<plnk:partnerLinkType name="employeeLT">
<plnk:role name="employeeTravelStatusService">
<plnk:portType name="tns:EmployeeTravelStatusPT" />
</plnk:role>
</plnk:partnerLinkType>
...
Chapter 3
The last partner link type is flightLT, used to describe the communication between the BPEL process and the Airline web service. This communication is asynchronous. The BPEL process invokes an asynchronous operation on the Airline web service. The web service, after it has completed the request, invokes a callback on the BPEL process. Therefore we need two roles:
• The first role describes the role of the Airline web service to the BPEL process, which is the airline service (airlineService). The BPEL process uses the
FlightAvailabilityPT port type to make the asynchronous invocation. T
• The second role describes the role of the BPEL process to the Airline web services.
For the Airline web service, the BPEL process is an airline customer, thus the role name is airlineCustomer. The Airline web service uses the FlightCallbackPT port type to make the callback.
T
This partner link type is defined in the WSDL of the Airline web service:
...
<plnk:partnerLinkType name="flightLT">
<plnk:role name="airlineService">
<plnk:portType name="tns:FlightAvailabilityPT" />
</plnk:role>
<plnk:role name="airlineCustomer">
<plnk:portType name="tns:FlightCallbackPT" />
</plnk:role>
</plnk:partnerLinkType>
...
Understanding partner link types is crucial for developing a BPEL process specification. Sometimes it helps to make a diagram of all the interactions. Once the partner link types are defined, we have finished the preparation phase and are ready to start writing the business process definition.