ActiveBPEL® Designer User’s Guide

Previous | Next

Tutorial Part 3: Working with Orchestration Interfaces

If you have not already done so, complete or review Tutorial Part 1: Starting a New Process and Tutorial Part 2: Planning and Designing a Process.

In Part 2 of the tutorial, you learned how to create a top-down design by arranging BPEL activities on the Process Editor canvas. Now you will begin creating an executable process based on WSDL files.

In the Project Explorer view of ActiveBPEL, you should have the following:

By completing Part 3 of the tutorial, you will be able to:

Step 1: Viewing the WSDL and schema needed for the process

A Web Services Description Language (WSDL) file describes business operations that are invoked to carry out the activities of a BPEL process. WSDL files, and the schema types and elements they import, are required in order to create a valid executable BPEL file. A good practice is to include relevant WSDL and schema files in your orchestration project so that you can easily deploy the files in the project to a deployment package.

Normally you would create an orchestration project folder and import WSDL files into it. We will take a shortcut for the tutorial, since the WSDL files are already imported for the completed loan process, as shown in the following illustration:

The WSDL and schema file definitions are as follows:

loanProcess.wsdl

WSDL for the BPEL process orchestration describing the request operation. The BPEL process starts by receiving a loan applicant’s request for a loan.

loanApproval.wsdl

WSDL describing the approve operation for the loan approver service. The service is invoked to approve or deny requests for large loans

riskAssessment.wsdl

WSDL describing the check operation for the risk assessment service. The service is invoked to check the risk level of an applicant applying for a small loan.

loanMessages.wsdl

WSDL containing the message definitions for data exchanged among the service partners. This WSDL is imported by the other WSDLs.

loanRequest.xsd

Schema that defines the data types used in messages. The schema is imported into loanMessages.wsdl.

Step 2: Using the Interfaces View

When you import a Web Services Description Language (WSDL) file into an orchestration project, the WSDL is displayed in an expandable tree structure so you can see its elements. In addition, the two most significant elements for BPEL design are added automatically to the Interfaces view: port types and partner link types.

A port type is a required element of WSDL. It describes the operation to use for invoking a Web service and the message(s) to be exchanged between Web services.

A partner link type describes the role(s) played by a Web service within a BPEL process. It is not usually provided in a WSDL. It is an extension element added and required for BPEL processes.

  1. In the Interfaces view, expand the partner link types to reveal the role and operation, as shown in the example:

    2. expanded partner link type in Interfaces view

  2. Rest your mouse on a port type and use hover help to view location and details for each WSDL, as shown in the example. Later, when you have many WSDL, you can use the toolbar filter arrow to select a subset of interfaces for just the process in focus or its project.

Hover help shows project location and namespace for selected WSDL file.

Tip: We have already added partner link types to the WSDLs. When you have your own WSDLs, you can use a Designer wizard to automatically add partner link types.

Step 3: Viewing the Loan Approval and Risk Assessment Services

In the Interfaces view, we see three partner link types, which each have one role. The role is that which a Web service plays in a BPEL orchestration:

The Tutorial project includes the actual risk assessment and loan approval Web services. These services have been built as BPEL processes. In Part 9 of the tutorial, we will deploy them to the ActiveBPEL embedded server for running and remote debugging the BPEL process.

  1. In the Tutorial project, expand the Partner Services folder.
  2. Note that files exist with .bprd extensions. Later, we will deploy the two services, using an Ant target contained in the .bprd files.

Note that the Partner Services folder was uniquely created for the tutorial. When you create your own Orchestration Project, there is no default folder for partner services.

Tip: If you want to deploy the partner services now, refer to Tutorial Part 9: Deploying the Process for instructions on starting up the server and executing the necessary scripts.

Continue to Tutorial Part 4: Using the Operation Wizard to Create Web Interaction Activities.

Copyright (c) 2004-2008 Active Endpoints, Inc.