WS-BPEL语言基础（上）

 

16.1. WS-BPEL语言基础
在我们能够设计编排层之前，我们需要很好地理解如何正式地表达流程的操作特征。本书使用WS-BPEL语言来演示流程逻辑如何能够被作为具体定义的一部分来描述（图16.1），从而能够通过相适应的编排引擎来实现和执行。

 

图16.1. 常见的WS-BPEL流程定义结构

 

虽然你很可能会使用流程建模工具并因此不需要从草稿开始编写你的流程，WS-BPEL元素的知识仍旧是有用的和必需的。WS-BPEL建模工具经常会涉及到这些元素和结构，而且你可能深入到它们生成的代码中做进一步的精化。

注意

如果你已经轻松了解了WS-BPEL语言，请向前跳到面向服务业务流程设计（循序渐进的流程）章节。

16.1.1. BPEL4WS与WS-BPEL简史
在我们进入WS-BPEL语言的细节之前，让我们简要讨论一下这个规范是如何形成的。Web服务业务流程执行语言（BPEL4WS）最初在2002年7月被构思和发布，伴以BPEL4WS 1.0规范，这是IBM、Microsoft和BEA合作的成果。这个文档提议了从先前的各种语言中得到灵感的编排语言，例如IBM的Web服务流程语言（WSFL） 与Microsoft的XLANG规范。

随着来自于SAP和Siebel Systems等其他贡献者的加入，版本1.1的BPEL4WS规范在一年不到的时间，于2003年5月发布了。这个版本获得了更多的关注与厂商支持，导致了大量的商业上遵循BPEL4WS的可用编排引擎。正是在这个发布之前，BPEL4WS规范被提交到OASIS技术委员会，使得这个规范能够被开发成为一个官方的、开放的标准。

技术委员会正在下一个版本BPEL4WS的最终发布流程中。它已经宣布了语言本身被重新命名为Web服务业务流程执行语言，或者是WS-BPEL（并被赋予2.0版本号）。WS-BPEL所规划的变更目前已经对外公布，并可在OASIS的Web网站www.oasis-open.org上获得。

在本节的元素描述中加入了注释，以利于指出BPEL4WS与WS-BPEL之间的语法变动。为了简单起见，在本书中我们提到的业务流程执行语言就是指WS-BPEL。

16.1.2. 先决条件
现在是学习WS-BPEL语言的时候了。如果你还没有准备好，推荐你在继续本节之前阅读第6章。第6章中涉及了编排、协调、原子事务和业务活动等相关概念，因而在此就不再重复。本章同时也假设你已经通读了第13章中提供的WSDL教程。

16.1.3. process元素
让我们从WS-BPEL流程定义的根元素开始。它使用name 属性来给一个名称赋值，并用于建立流程定义相关的命名空间。

示例16.1. process 定义框架

<process name=“TimesheetSubmissionprocess”

targetNamespace=“http://www.xmltc.com/tls/process/”

xmlns=

“http://schemas.xmlsoap.org/ws/2003/03/

business-process/”

xmlns:bpl=“http://www.xmltc.com/tls/process/”

xmlns:emp=“http://www.xmltc.com/tls/employee/”

xmlns:inv=“http://www.xmltc.com/tls/invoice/”

xmlns:tst=“http://www.xmltc.com/tls/timesheet/”

xmlns:not=“http://www.xmltc.com/tls/notification/”>

<partnerLinks>

...

</partnerLinks>

<variables>

...

</variables>

<sequence>

...

</sequence>

...

</process>

process 结构包含一系列常见的子元素，在下列章节中说明。

16.1.4. partnerLinks与partnerLink元素
partnerLink 元素建立了端口类型的服务（伙伴），将参与业务流程的执行过程。伙伴服务能够担当流程的客户端，负责调用流程服务。作为替代，伙伴服务也能够被流程服务自身所调用。

partnerLink 元素的内容代表了两个合作伙伴之间的通信交换---流程服务是一个合作伙伴其他服务是另一个合作伙伴。依据通信的种类，流程服务的作用将会变化。例如，被外部服务所调用的流程服务可能担当 “工单提交流程（TimesheetSubmissionProcess）”的角色。然而，当这个同样的流程服务调用具有发票校验的不同服务的时候，它担当了不同的角色，或许是“发票客户（InvoiceClient）”。partnerLink 元素因而包含myRole 与 partnerRole 属性，分别设立了流程服务和伙伴服务服务提供者的角色。

为简单起见，myRole 属性用于流程服务被伙伴客户端服务所调用时，因为在这个情况下流程服务担当了服务提供者。partnerRole 属性识别了流程服务所调用的伙伴服务（使伙伴服务成为服务提供者）。

注意当期望的流程服务在相同的伙伴服务中担当服务请求者和服务提供者的时候，myRole 与 partnerRole 属性都能够被相同的partnerLink元素所使用。例如，在流程和伙伴服务的异步通信过程中，在伙伴服务回调期间 myRole 的设置显示出流程服务的角色。

示例16.2. partnerLinks 结构包含一个 partnerLink 元素，在该元素内流程服务被一个外部客户端伙伴所调用，并且四个partnerLink 元素确定了被流程服务所调用的伙伴服务

<partnerLinks>

<partnerLink name=“client”

partnerLinkType=“tns:TimesheetSubmissionType”

myRole=“TimesheetSubmissionServiceProvider”/>

<partnerLink name=“Invoice”

partnerLinkType=“inv:InvoiceType”

partnerRole=“InvoiceServiceProvider”/>

<partnerLink name=“Timesheet”

partnerLinkType=“tst:TimesheetType”

partnerRole=“TimesheetServiceProvider”/>

<partnerLink name=“Employee”

partnerLinkType=“emp:EmployeeType”

partnerRole=“EmployeeServiceProvider”/>

<partnerLink name=“Notification”

partnerLinkType=“not:NotificationType”

partnerRole=“NotificationServiceProvider”/>

</partnerLinks>

你会在示例16.2中注意到，每个partnerLink 元素同样也包含了partnerLinkType 属性。这涉及到partnerLinkType 结构，在下面说明。

16.1.5. partnerLinkType元素
对于包含在流程中的每个伙伴服务，partnerLinkType 元素在流程定义中确定了被partnerLink 元素引用的WSDL portType 元素。因此，这些结构典型地都直接嵌入到每个伙伴服务的WSDL文档中（包括流程服务）。

正如 partnerLink myRole 与 partnerRole 属性所定义的那样，partnerLinkType 结构为每个服务可以担当的角色包含一个 role 元素。其结果是， partnerLinkType 将具有一个或两个 role 子元素。

示例16.3. WSDL 定义 结构包含 partnerLinkType 结构

<definitions name=“Employee”

targetNamespace=“http://www.xmltc.com/tls/employee/wsdl/”

xmlns=“http://schemas.xmlsoap.org/wsdl/”

xmlns:plnk=

“http://schemas.xmlsoap.org/ws/2003/05/partner-link/”

...

>

...

<plnk:partnerLinkType name=“EmployeeServiceType” xmlns=

“http://schemas.xmlsoap.org/ws/2003/05/partner-link/”>

<plnk:role name=“EmployeeServiceProvider”>

<portType name=“emp:EmployeeInterface”/>

</plnk:role>

</plnk:partnerLinkType>

...

</definitions>

注意多个 partnerLink 元素可以引用相同的partnerLinkType。这当流程服务与多个伙伴服务具有相同关系的时候十分有用。所有的伙伴服务因而能够使用相同的流程服务的portType 元素。

注意

在2.0版本的WS-BPEL规范中，提议了portType 元素的变更以便作为role元素的一个属性存在。

16.1.6. variables元素
WS-BPEL 流程服务通常使用variables 结构来保存与即时工作流逻辑关联的状态信息。整个消息和数据集合被格式化为XSD schema 类型，能够在处理过程中被置入变量并在以后获取。数据的类型能够被赋予 variable 元素，它需要用下面三个属性之一来预定义： messageType， element，或 type.

messageType 属性允许变量包含整个WSDL定义的消息，而 element 属性完全引用了XSD元素结构。type 属性能够用于仅代表XSD simpleType，如 string 或 integer。

示例16.4. variables 结构仅包含一些后续被工单提交流程所使用的 variable 子元素

<variables>

<variable name=“ClientSubmission”

messageType=“bpl:receiveSubmitMessage”/>

<variable name=“EmployeeHoursRequest”

messageType=“emp:getWeeklyHoursRequestMessage”/>

<variable name=“EmployeeHoursResponse”

messageType=“emp:getWeeklyHoursResponseMessage”/>

<variable name=“EmployeeHistoryRequest”

messageType=“emp:updateHistoryRequestMessage”/>

<variable name=“EmployeeHistoryResponse”

messageType=“emp:updateHistoryResponseMessage”/>

...

</variables>

典型地来讲，具有 messageType 属性的变量是为流程定义所处理的每个输入和输出消息定义的。这个属性的值是来自于伙伴流程定义的消息名称。