WS-BPEL语言基础

本文主要是介绍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>

...

</variables>

...

</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 元素确定了被流程服务所调用的伙伴服务

<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”>

</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 子元素

<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 属性的变量是为流程定义所处理的每个输入和输出消息定义的。这个属性的值是来自于伙伴流程定义的消息名称。

16.1.1. reply元素
当制订了同步交换的时候，哪里有receive 元素，哪里就有 reply 元素。reply 元素负责建立细节，关于返回响应消息到所要求的客户端伙伴服务。由于这个元素与它相应的receive 元素的相同的partnerLink 元素关联，它重复了许多同样的属性（表16.3）。

表16.3. reply 元素属性

属性               描述

partnerLink       建立在receive元素中的相同的partnerLink 元素。

portType  显示在receive元素中的相同的portType 元素。

operation  来自于receive元素中的相同的operation 元素。

variable  流程服务的variable 元素拥有返回到伙伴服务的消息。

messageExchange WS-BPEL 2.0规范被提议增加了这个可选属性。它允许明确地与消息活动   关联的reply元素能够接收消息（比如receive元素）。

示例16.9. reply 元素与先前显示的 receive 元素可能的配对

<reply partnerLink=“client”

portType=“tns:TimesheetSubmissionInterface”

operation=“Submit”

variable=“TimesheetSubmissionResponse”/>

16.1.1. switch、case及otherwise元素
这三个结构化的活动元素允许我们增加条件化的逻辑到我们的流程定义中，与在传统编程语言中使用的所熟悉的select case/case else 结构相类似。switch 元素建立了条件逻辑的工作范围，在其中多个case 结构能够嵌套，以检查使用condition 属性的各种条件。当condition 属性解析为“true”的时候，定义在相应case 结构中的活动就被执行。

otherwise 元素能够被添加作为switch 结构末尾的catch all。当所有前述的case 条件失败时，otherwise 结构中的活动就被执行。

示例16.10. case 元素的框架，在其中condition 属性使用getVariableData函数来对 EmployeeResponseMessage 的变量内容和0值作比较

<case condition=

“getVariableData('EmployeeResponseMessage'，

'ResponseParameter')=0”>

...

</case>

...

</otherwise>

</switch>

注意

在WS-BPEL2.0中提议了将switch、case、与 otherwise 元素替换为if、elseif、与 else 元素。

16.1.2. assign、copy、from及to元素
这组元素只是提供给我们在进程变量之间复制值的能力，它允许我们贯穿整个进程来传送数据，因为信息会在进程的执行过程中接收和修改。

示例16.11. 在该 assign 结构中， TimesheetSubmissionFailedMessage 变量的内容被复制到两个不同的消息变量中

<copy>

</copy>

<copy>

</copy>

</assign>

注意 copy 结构可以处理各种数据传输函数（例如，只有部分消息能够被抽取和复制到变量中）。 from 与 to 元素同样也可以包含可选的 part 与 query 属性，允许引用变量的特定的部分或特定的值。

16.1.3. faultHandlers、catch及catchAll元素
这个结构包含多个catch 元素，每个都提供活动为特定类型的错误条件进行异常处理。故障会通过接收WSDL定义的故障消息来生成，或者它们可以通过使用throw元素被明确触发。faultHandlers 结构可以由catchAll 元素构成（或终止）以提供缺省的错误处理活动。

示例16.12. faultHandlers 结构包含catch 与 catchAll 子结构

<catch faultName=“SomethingBadHappened”

faultVariable=“TimesheetFault”>

...

</catch>

...

</catchAll>

</faultHandlers>

16.1.4. 其他WS-BPEL元素
下列表格提供了对WS-BPEL语言其他相关部分的简要描述。

表16.4. 快速参考表提供了对附加WS-BPEL元素的简短描述（按照字母顺序排列）

元素
描述

compensationHandler
WS-BPEL流程定义能够定义出补偿流程，当确定的条件发生时加入一系列的活动以证明补偿的正当性。这些活动就被保留在compensationHandler结构中。（更多关于补偿的信息，参见第6章中的业务活动一节。）

correlationSets
WS-BPEL使用这个元素来实现相关性，主要和进程实例的消息关联。消息可以属于多个correlationSets。更进一步，消息属性可以在WSDL文档中定义。

empty
这个简单的元素允许你声明在特定的条件下没有活动应该发生。

eventHandlers
eventHandlers 元素使得进程响应处理逻辑执行过程中的事件。这个结构可以包含onMessage 和 onAlarm 子元素，在特定类型的消息到达时触发处理活动（分别在预定义的一段时间后，或者在指定的日期和时间）

exit
参见下面的 terminate 元素描述。

flow
flow 结构允许你定义一系列会并发产生并需要在所有都结束执行后完成的活动。在flow 结构中的活动之间的从属关系使用子元素link来定义。

pick
与 eventHandlers 元素类似，这个结构也能够包含子元素onMessage 和 onAlarm ，但更多地用于响应针对进程执行挂起的外部事件。

scope
在流程定义中的部分逻辑能够被细分到使用这个结构的范围中。它允许你定义variables、faultHandlers、correlationSets、compensationHandler以及eventHandlers元素定位到这个范围。

terminate
该元素有效地终止进程实例。WS-BPEL 2.0规范建议这个元素重命名为exit。

throw
WS-BPEL支持众多的故障条件。使用 throw 元素允许你明确地触发故障状态以响应特定的条件。

wait
wait 元素能够被设置成在进程中引入有意识的延迟。它的值可以是指定时间或是预定义的日期。

while
这个有用的元素允许你定义循环。它包含了condition 属性，与case 元素一起，只要在“true”的时候，它会继续执行在while结构中的活动。

16.1.7. getVariableProperty与getVariableData功能

WS-BPEL提供内置函数，允许存储在变量中或者是与变量关联的信息能在业务流程执行期间被处理。

getVariableProperty（variable name， property name）

这个函数允许从变量中接收全局的属性值。它完全接受了作为输入的值和属性名称，并返回所要求的值。

getVariableData（variable name， part name， location path）

由于变量通常用于管理状态信息，这个函数要求提供访问数据的其他部分处理逻辑。getVariableData 函数具有一个强制的变量名称参数和两个能够用于指定变量数据的可选变量。

在我们的示例中我们多次使用 getVariableData 函数来从变量中获取消息数据。

示例16.5. 两个 getVariableData 函数被用于接收来自于不同变量的特定数据

getVariableData （"InvoiceHoursResponse"，

"ResponseParameter"）

getVariableData （"input"，"payload"，

"/tns:TimesheetType/Hours/..."）

16.1.8. sequence元素

sequence 结构允许你组织一系列的活动以便它们以预定义的、有顺序的次序执行。WS-BPEL提供了大量能够用于在流程定义中表示工作流逻辑的活动。在本节中剩余的元素描述解释了一组基本的用于我们将要进行案例研究示例的一部分活动。

示例16.6. sequence 结构框架仅包含了WS-BPEL所提供的许多活动元素中的一些

<sequence>

...

</receive>

...

</assign>

...

</invoke>

<reply>

...

</reply>

</sequence>

注意 sequence 元素可以嵌套，允许你在序列中定义序列。

16.1.9. invoke元素

该元素识别了伙伴服务的操作，这是流程定义计划在其执行过程中要调用的。invoke 元素配备了五个常见属性，进一步详细说明了条文的细节（表16.1）。

表16.1. invoke元素属性

属性	描述
partnerLink	该元素通过相应的 partnerLink 来命名伙伴服务。
portType	该元素用于识别伙伴服务的 portType 元素。
operation	流程服务需要发送请求到的伙伴服务操作。
inputVariable	输入消息将用于和伙伴服务操作进行通信。注意这里所提及的是作为变量，因为它引用了具有messageType 属性的WS-BPEL变量。
outputVariable	当基于请求-响应的MEP进行通信的时候采用该元素。返回值存储在单独的variable元素中。

示例16.7. invoke 元素确定了目标伙伴服务的细节

<invoke name=“ValidateWeeklyHours”

partnerLink=“Employee”

portType=“emp:EmployeeInterface”

operation=“GetWeeklyHoursLimit”

inputVariable=“EmployeeHoursRequest”

outputVariable=“EmployeeHoursResponse”/>

16.1.10. receive元素

receive 元素允许我们建立流程服务期望从外部客户端伙伴服务中接收请求的信息。在这个案例中，流程服务被视作是等待调用的服务提供者。

receive 元素包含一组属性，它们中的每一个都被赋值，涉及到预期进来的通信（表16.2）。

表16.2. receive 元素属性

属性	描述
partnerLink	客户端伙伴服务在相应的partnerLink结构中被识别。
portType	流程服务portType 会等待从伙伴服务中接收请求消息。
operation	会接收请求的流程服务操作。
variable	进来的请求消息将会被存储在流程定义的variable 结构中。
createInstance	当这个属性被设置成“yes”的时候，这个特殊请求的可能负责创建新的进程实例。