Introduction

Business Process Execution Language (BPEL) is an XML-based language that specifies the behavior of business processes. Developers from IBM®, BEA Systems, Inc., and Microsoft originally wrote BPEL, and submitted it to the Organization for the Advancement of Structured Information Standards (OASIS) Standards Committee in April 2003. BPEL describes business processes as interactions between Web services and presents a process as a Web service. IBM WebSphere® Business Integration Server Foundation V5.1 contains the implementation of this language. WebSphere Application Developer Integration Edition (Application Developer Integration) contains a graphical editor for BPEL processes and creates EAR files from business processes.

A BPEL process describes only the abstract Web services it is calling during processing. When Application Developer Integration creates an installable EAR file from the BPEL source file, the process developer must provide the actual binding and concrete service endpoint. However, there are scenarios where the service endpoint that implements an abstract Web service is unknown at process development time. Determination of the actual service endpoint address can occur only during processing of the business process.

This article explains how to achieve such a dynamic service binding. In the first section, I demonstrate how to invoke Web services from a BPEL process. Then, I illustrate how service endpoints are bound to a BPEL process using Application Developer Integration. Finally, I show you how a service binding might be overwritten at process runtime, and go through each step that is necessary to implement a BPEL business process that uses dynamic service bindings. Screenshots and detailed instructions help you to reproduce each step in Application Developer Integration.

Back to top

Invoking Web services using BPEL

This section describes how to invoke Web services from a BPEL process. It also introduces the necessary BPEL and Web Services Description Language (WSDL) elements, and explains how these elements can be created using Application Developer Integration.

Let's assume the BPEL process verifies a customer’s credit card information. The abstract WSDL that provides this operation is shown in Figure 1:

To call the verifyInformation operation from a BPEL process, the following elements in the BPEL process are necessary:

Partner link

The <partnerLink> serves as a placeholder for the credit card service in the process and is part of the BPEL file. A partner link type (see next section) further defines the partner link, and has a name which distinguishes it from other elements in the business process. It looks as follows:

<partnerLink 

    name="CreditCardService"
    partnerLinkType="wsd10:CreditCardServicePLT"
    partnerRole="ServiceRole"/>

Partner link type

A WSDL file defines partner link types. Partner link types have one or two roles. A port type is assigned to each role. If two partners are talking to each other, that is, both are invoking operations of their partner, the partner link type has two roles. If invocations of operations from one partner occur, the partner link type must have one role.

Since you do not expect any callback (asynchronous) from the credit card service, but are only interested in invoking an operation from the credit card service, you need to create one role in the partner link type and assign the port type, creditCardPort, to this role:

<plnk:partnerLinkType name="CreditCardServicePLT">
    <plnk:role name="ServiceRole">
	<plnk: portType name="wsdl1:creditCardPort"/>
    </plnk:role>
</plnk:partnerLinkType>
		

where plnk refers to the namespace http://schemas.xmlsoap.org/ws/2003/05/partner-link/.

To create the <partnerLinkType> and the <partnerLink> using the BPEL editor in Application Developer Integration V5.1, proceed as follows:

• Click the icon in the Partner Links area.
• Click on the Description tab in the details area, and type CreditCardService for the name.
• Click on the Implementation tab in the details area.
• Click New to create a new partner link type. A New Partner Link Type dialog appears.
• Accept the default settings for File and Partner Link Type.
• Select One Role for the Number of Roles.
• Type ServiceRole for First Role.
• Click Browse... to specify the WSDL file that contains the service partner port type. Select the WSDL file that contains the abstract service description of the credit card service as described above.
• Make sure that you have creditCardPort selected for the port type.
• Figure 2 shows the completed Partner Link Type dialog.
  
  Figure 2. Completed Partner Link Type dialog
  
  
• Click OK to finish the definition of partner link type and partner link.

Variables

Variables hold data that is received from or sent to the credit card service. Variable definitions for the scenario are as follows:

<variable messageType="wsdl1:informationRequest" name="creditCheckIn"/>
<variable messageType="wsdl1:informationResponse" name="creditCheckOut"/>

To create these variables using Application Developer Integration V5.1, complete the following steps:

• Click the icon in the Variables area.
• Click on the Description tab in the details area, and type creditCheckIn for the name.
• Click on the Message tab in the details area, and click Browse... to select the file that contains the message definition for this variable, as shown in Figure3.
• Select the WSDL file that contains the abstract service description of the credit card service.
• Make sure that you have informationRequest selected in the drop-down list.
  
  Figure 3. Browse dialog for selecting WSDL message for process variable
  
  
• Click OK to finish the selection of a WSDL message.
• Repeat these steps to create another variable that holds the response from the credit card service.

Invoke activity

An <invoke> activity that invokes the service:

<invoke name="creditCardCheck"

  partnerLink="CreditCardService"
  portType="wsdl1:creditCardPort"
  operation="verifyInformation"
  inputVariable="creditCheckIn"
  outputVariable="creditCheckOut"/>

To create an according <invoke> activity using Application Developer Integration V5.1, proceed as follows:

• Click the Invoke icon ( ) in the palette. Then, click on the canvas to add an invoke activity to your process.
• Click on the Description tab in the details area, and type creditCardCheck for the name.
• Click on the Implementation tab in the details area.
• Click CreditCardService in the Partner Link drop-down list, as show in Figure 4.
• Make sure that you have verifyInformation selected in the Operation drop-down list.
• Click creditCheckIn in the Request drop-down list.
• Click creditCheckOut in the Response drop-down list.
  The contents of the creditCheckIn variable will be sent to the credit card service. The data that the service sends back to the process will be stored in the creditCheckOut variable.
  Figure 4. Implementation of invoke activity
  
  

Back to top

Binding Web services to BPEL processes

As seen in the previous section, the BPEL process definition does not refer to the binding or service address of a Web service that it is invoking. The BPEL standard does not specify the definition of service bindings and addresses in a BPEL file. WebSphere Process Choreographer uses component and wiring files to connect binding and service information with the information in the BPEL file.

This section describes how service endpoints are provided for BPEL processes in WebSphere Business Integration Server Foundation V5.1.

WebSphere Studio Integration Edition automatically creates a .component file for the process as well as for the invoked Web service. This file describes the interface and implementation of the process or Web service.

For example, the .component file that is created for the credit card service from the previous section might look as follows:

<interfaces>
    <wInterface portType="wsdl1:creditCardPort"/>
</interfaces>
<implementation xsi:type="service:OutboundServiceImplementation">
    <wsdl ref="creditCardService.wsdl"
        serviceName="wsdl1:creditCardSOAPService"
        portTypeName="wsdl1:creditCardPort"
        portName="creditCardPortSOAPPort"/>
</implementation>
							

In turn, the .component file for the BPEL process contains a reference to a credit card service. This reference matches the partner link definition that is contained in the BPEL file.

<interfaces>
    ... interface of the process ...
</interfaces>
<references>
    <wReference name="CreditCardService" portType="wsdl1:creditCardPort"/>
    ... other services the process invokes ...
</references>
<implementation xsi:type="wcdlProcess:ProcessImplementation">
    ... implementation of the process ...
</implementation>
							

When deployment code is generated for the BPEL process, the component files of the process and the service are wired together. When the process executes and invokes the verifyInformation operation, it uses the credit card component file of Web services that provides information about service and port.

To create a binding between a BPEL process and a Web service using Application Developer Integration V5.1, proceed as described here:

• Right-click the BPEL process in the Services view.
• Select Enterprise Services > Generate Deploy Code. A Generate BPEL Deploy Code dialog appears. You can assign concrete bindings and ports to each Web service that is used in your process.
• In the Referenced Partners section, select CreditCardService, as shown in Figure 5.
• Click Browse... and select the WSDL file that contains the service definition of the credit card service.
• Make sure to select the port you want to use in the Port section.
  
• Click OK to start the generation of the .wiring file and the deployment code.
  Figure 5. Generate deploy code dialog
  
  

Back to top

Changing a binding at process runtime

WebSphere Process choreographer will always ask you to specify a concrete port and endpoint when you are invoking a Web service from your process. Therefore, if you do not know at process development time which service you will invoke, you need to create a dummy service that matches the service you will invoke later on in certain areas.

The dummy service must:

• Implement the same portType as the service you will invoke later on.
• Have the same binding type (doc/lit, rpc/encoded, and so forth) as the service you will eventually invoke.

Partner link settings

To enable a partner link to be bound to another service endpoint as the process instance is running, you must set the attribute resolutionScope of the partner link to computed:

<partnerLink
    name="CreditCardService"
    partnerLinkType="wsdl0:CreditCardServicePLT"
    partnerRole="ServiceRole"
    wpc:resolutionScope="computed"/>
						

To set this attribute using Application Developer Integration V5.1, proceed as follows:

• Click CreditCardService in the Partners area.
• Click on the Server tab in the details area, as shown in Figure 6.
• In the Resolution Scope drop-down box, select computed.
  
  Figure 6. Setting the resolution scope of a partner link
  
  

Variable for service endpoint

At process runtime, you need to know the service endpoint of the service you want to call. Depending on other data in your process, you might come across the service endpoint to use, or you might receive a service endpoint via a UDDI query you do during your control flow of the process. You might also submit the service endpoint when you start a process instance.

Either way, you need a variable that can hold a service endpoint. A WSDL message defines the variable that, in turn, has a complex part of type EndpointReferenceType. Figure 7 shows an example for such a message:

WSAddressing.xsd defines the complex type EndpointReferenceType. It has several parts that are complex, as shown in Figure 8:

However, if you are using an EndpointReferenceType for dynamic service binding, only the address part must be set. The restrictions that apply to the dummy service (portType and binding type must not be changed) cause other parts to have their values ignored even though they might be set.

Creating a service endpoint

For each variable that you use in a BPEL process, Application Developer Integration generates a Java class that reflects the structure of the variable. If a message type that contains a part of type EndpointReferenceType defines a variable, the class, com.ibm.websphere.srm.bpel.wsaddressing.EndpointReferenceType, holds the service endpoint data.

The following Java code snippet shows how you can initialize an instance of this EndpointReferenceType class for use in dynamic service binding. For the Java code, assume the service and binding shown in Figure 9.

com.ibm.websphere.srm.bpel.wsaddressing.AttributedURI address = new AttributedURI();
com.ibm.ws.webservices.engine.types.URI addressValue = new URI();
com.ibm.websphere.srm.bpel.wsaddressing.EndpointReferenceType e = 
    new EndpointReferenceType();

					

addressValue.setHost("myCreditCardCompany.com");	 
addressValue.setPath("/creditCardService");	 
addressValue.setPort(9080);	 
addressValue.setScheme("http");	 
address.setValue(addressValue);
e.setAddress(address);

Overwriting a service endpoint

You have enabled the partner link for the service to be overwritten, created a variable that can hold a service endpoint, and learned how to create a service endpoint that can be stored in this variable. The last thing you need to do is assign the service endpoint to the partner link you use for your invoke activity.

First, you need to add an assign activity to your process control flow before the invoke activity (see Figure 10):

Then, implement the assign activity as follows:

• Select Variable or Part in the From drop-down box, as shown in Figure 11.
• Select the variable part that contains the EndpointReferenceType in the left frame.
• Select Partner Link Reference in the To drop-down box.
• Select CreditCardService in the right frame.
  
  Figure 11. Implement assign activity
  
  

Now, you are ready to deploy and run your process. As a process instance is running in WebSphere Process Choreographer, the service endpoint information from the variable is used in the invoke activity. A dynamically chosen credit card service verifies a customer's credit card information.

Resources

• You can find further information about Process Choreographer in the WebSphere Developer Domain. The WebSphere Application Server Enterprise Process Choreographer page lists all the current articles.
  
  
• Visit the WebSphere Business Integration main page on developerWorks for more information on WebSphere Business Integration Server Foundation.
  
  
• Read the WS-Addressing specification from IBM developerWorks. You can also get the XSD file associated with this specification.
  
  
• Visit the WebSphere Studio zone on developerWorks WebSphere for comprehensive information on how to acquire and use IBM's suite of tools for application development.
  
  
• Find additional SOA and Web services technology resources on the developerWorks SOA and Web services technology zone.
  
  
• Browse for books on these and other technical topics.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Invoking Web services using BPEL
• Binding Web services to BPEL processes
• Changing a binding at process runtime
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers