当您用 BPEL 定义业务流程时，您实际上定义了一个由现有服务组成的新 Web 服务。该新 BPEL 复合 Web 服务的接口使用一组端口类型来提供类似任何其他 Web 服务的操作。要调用用 BPEL 描述的业务流程，则必须调用生成的复合 Web 服务。图 3 是我们流程的示意图。

　　图 3:出差安排示例 BPEL 流程

　　在开发此示例 BPEL 流程的过程中，您将经历下列步骤:

　　熟悉相关的 Web 服务
　　为此 BPEL 流程定义 WSDL
　　定义合作伙伴链接类型
　　开发此 BPEL 流程:
　　定义合作伙伴链接
　　声明变量
　　编写流程逻辑定义。

　　第 1 步:列出相关 Web 服务的清单

　　在您开始编写 BPEL 流程定义之前，必须先熟悉从业务流程中调用的 Web 服务。这些服务称作合作伙伴 Web 服务。本示例使用雇员出差状态 Web 服务以及美国航空公司和达美航空公司 Web 服务(这两个 Web 服务具有相同的 WSDL 描述)。(同样，本示例中使用的 Web 服务是虚构的。)

　　雇员出差状态 Web 服务雇员出差状态 Web 服务提供 EmployeeTravelStatusPT 端口类型，通过它可以使用 EmployeeTravelStatus 操作检查雇员出差状态。此操作将返回雇员可以使用的乘机标准(可能为经济舱、商务舱或头等舱)。(见图 4。)

　　图 4:雇员出差状态 Web 服务

　　航空公司 Web 服务航空公司 Web 服务是异步的;因此它指定了两个端口类型:第一个端口类型 FlightAvailabilityPT 用于使用 FlightAvailability 操作检查航班可用性。为返回结果，该 Web 服务指定了第二个端口类型 FlightCallbackPT。此端口类型指定 FlightTicketCallback 操作。

　　尽管航空公司 Web 服务定义了两个端口类型，但它只实现 FlightAvailabilityPT。FlightCallbackPT 则由作为 Web 服务客户端的 BPEL 流程实现。图 5 是此 Web 服务体系结构的示意图:

　　图 5:航空公司 Web 服务

　　第 2 步:为 BPEL 流程定义 WSDL

　　接下来，我们必须将此业务出差 BPEL 公开为 Web 服务。因此，第二步是为它定义 WSDL。此流程将必须从它的客户端接收消息并返回结果。它必须公开 TravelApprovalPT 端口类型，后者将指定一个输入消息。它还必须声明 ClientCallbackPT 端口类型(用于使用回调将结果异步返回给客户端)。图 6 说明了此流程。

　　图 6:此 BPEL 流程的 WSDL

　　第 3 步:定义合作伙伴链接类型

　　第三步是定义合作伙伴链接类型。合作伙伴链接类型表示 BPEL 流程与相关方(包括 BPEL 流程调用的 Web 服务以及调用 BPEL 流程的客户端)之间的交互。

　　本示例包含三个不同的合作伙伴:客户端、雇员出差状态服务和航空公司服务。理想情况下，每个 Web 服务都应在 WSDL 中定义相应的合作伙伴链接类型。(实际情形可能不是这样的。)然后，我们可以使用 WSDL 包装合作伙伴 Web 服务(导入 Web 服务的 WSDL 并定义合作伙伴链接类型)。或者，我们可以在 BPEL 流程的 WSDL 中定义所有合作伙伴链接。但由于此方法违反了封装原则，因此不建议使用。

　　对于本示例，我们定义了三个合作伙伴链接类型(每个类型位于 Web 服务的相应 WSDL 中):

　　travelLT:用于描述此 BPEL 流程客户端与此 BPEL 流程本身之间的交互。此交互是异步交互。此合作伙伴链接类型在此 BPEL 流程的 WSDL 中定义。

　　employeeLT:用于描述此 BPEL 流程与雇员出差状态 Web 服务之间的交互。此交互是同步交互。此合作伙伴链接类型在雇员 Web 服务的 WSDL 中定义。

　　flightLT:描述此 BPEL 流程与航空公司 Web 服务之间的交互。此交互是异步交互，且航空公司 Web 服务对此 BPEL 流程调用一个回调。此合作伙伴链接类型在航空公司 Web 服务的 WSDL 中定义。

　　每个合作伙伴链接可以拥有一个或两个角色，我们必须为每个角色指定它使用的 portType。对于同步操作，由于操作只是单向调用，因此每个合作伙伴链接类型仅有一个角色。例如，此 BPEL 流程对雇员出差状态 Web 服务调用 EmployeeTravelStatus 操作。由于它是同步操作，因此此 BPEL 流程等待完成并仅在完成操作后取得响应。

　　对于异步回调操作，我们必须指定两个角色。第一个角色描述客户端操作调用。第二个角色描述回调操作调用。在本示例中，BPEL 流程与航空公司 Web 服务之间存在一个异步关系。

　　正如我们已经指出的，我们需要三个合作伙伴链接类型:两个链接类型指定两个角色(因为它们是异步的)，一个链接类型指定一个角色(因为它是同步的)。

　　合作伙伴链接类型在特殊命名空间http://schemas.xmlsoap.org/ws/2003/05/partner-link/ 的 WSDL 定义。首先，我们在客户端使用的 BPEL 流程 WSDL 中定义 travelLT 链接类型以调用此 BPEL 流程。所需的第一个角色是出差服务(即，我们的 BPEL 流程)的角色。客户端使用 TravelApprovalPT 端口类型与此 BPEL 服务通信。第二个角色 travelServiceCustomer 描述了此 BPEL 流程将在 ClientCallbackPT 端口类型中对其执行回调的客户端的特征:

<plnk:partnerLinkType name=”travelLT”>

<plnk:role name=”travelService”>
<plnk:portType name=”tns:TravelApprovalPT” />
</plnk:role>

<plnk:role name=”travelServiceCustomer”>
<plnk:portType name=”tns:ClientCallbackPT” />
</plnk:role>

</plnk:partnerLinkType>
 
　　第二个链接类型是 employeeLT。它用于描述此 BPEL 流程与雇员出差状态 Web 服务之间的通信，并在此雇员 Web 服务的 WSDL 中定义。此交互是同步交互，因此我们需要一个名为 employeeTravelStatusService 的角色。此 BPEL 流程使用雇员 Web 服务上的 EmployeeTravelStatusPT:

<plnk:partnerLinkType name=”employeeLT”>

<plnk:role name=”employeeTravelStatusService”>
<plnk:portType name=”tns:EmployeeTravelStatusPT” />
</plnk:role>

</plnk:partnerLinkType>
 
　　最后一个合作伙伴链接类型 flightLT 用于描述此 BPEL 流程与航空公司 Web 服务之间的通信。此通信是异步通信。此 BPEL 流程对航空公司 Web 服务调用一个异步操作。此 Web 服务在完成请求后对此 BPEL 流程调用一个回调。因此，我们需要两个角色。第一个角色描述航空公司 Web 服务对于此 BPEL 流程服务的角色，即航空公司服务 (airlineService)。此 BPEL 流程使用 FlightAvailabilityPT 端口类型进行异步调用。第二个角色描述了此 BPEL 流程对于航空公司 Web 服务的角色。对于航空公司 Web 服务而言，此 BPEL 流程是一个航空公司客户，因此角色名称为 airlineCustomer。航空公司 Web 服务使用 FlightCallbackPT 端口类型进行回调。此合作伙伴链接类型在航空公司 Web 服务的 WSDL 中定义:

<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>
 
　　了解合作伙伴链接类型对于开发 BPEL 流程规范至关重要。有时，它可以帮助生成所有交互的图表。定义合作伙伴链接类型后，我们已经完成了准备阶段，并准备开始编写业务流程定义。