2．Invoke请求 

　　<invoke>活动允许业务流程同步或异步调用由合作伙伴提供的服务，服务实现可以是单向或请求 响应操作。Invoke活动使用”partnerLink”来引用伙伴服务。同过”portType”和”operation”指定相应的WSDL接口和操作：

　　<bpws:invoke name=”GetStockQuote” operation=”getQuote”
partnerLink=”StockQuote”
　　portType=”ns2:net.xmethods.services.stockquote.StockQuotePortType” >
</bpws:invoke>
 
　　如果在请求服务的过程中发生异常，则可以通过错误响应和补偿机制来加以处理，这对业务流程，特别是长时间运行的流程是非常重要的，我们将在后面的章节进行讲解。

　　3．Assign赋值 

　　<assign>活动的作用是用新的数据来更新变量的值。Assign活动可以包括任意数量的基本复制操作：

　　<bpws:assign name=”Assign”>
　　  <bpws:copy>
　　    <bpws:from> China</bpws:from>
　　    <bpws:to variable=”country”/>
　　  </bpws:copy>
　　</bpws:assign>
 
　　assign活动还可把端点引用复制到合作伙伴链接，或把合作伙伴链接复制到端点引用，以实现服务的动态绑定。

　　4．Wait等待 

　　<wait>活动会暂停流程执行，等待一段给定的时间或等到某一时刻才继续运行。在WebSphere Process Server 6.0中，开发者可以非常灵活地指定wait中的到期条件，比如等待多少秒，等到特定的一个日期，或是使用内置的日期表现法。也可以使用Java代码来动态指定等待时间。 BPEL也提供了丰富的结构化活动，可以灵活地控制流程执行。

　　5．Sequence顺序 

　　<sequence>活动定义一组按顺序先后执行的活动。执行顺序是sequence活动中嵌套活动的先后顺序。当sequence中的最后一个活动完成后，该sequence活动也就完成了。

　　6．Flow流程 

　　<flow>活动可以描述更为复杂的活动执行顺序。我们可以利用flow指定一个或多个并行执行的活动。为了定义任意的控制结构，可以在并行的活动中使用链接。 flow能进一步表达直接或间接嵌套在其中的活动之间的同步相关性，link（链接）用来表达这种同步相关性。

　　flow活动出现的所有link必须在flow活动中分开定义，并通过名称进行标识。flow活动中嵌套的活动需要通过source或target属性来标明该活动为哪个链接的源或目标活动。在flow活动中，对于每一个link必须有且仅有一个活动作为它的源活动，同样有且仅有一个活动作为它的目标活动。目标活动会在源活动完成之后执行。这样flow内部的活动就可以通过活动构成一个有向图。

　　我们还可以在link的源上定义transition（变迁）条件，当源活动完成之后，BPEL引擎会检查变迁条件是否满足，如果link的转移条件满足目标活动就会执行。
　
　　7．Switch分支 

　　<switch>活动与传统的结构化语言的功能类似，从一组分支情况中选择一个特定的活动分支加以执行。switch由case元素定义的一个或多个条件分支的有序列表组成，后面可跟也可以不跟一个otherwise分支。以case分支的出现顺序检查，第一个条件是true的分支被选择并被作为被执行的活动。如果有条件的分支都未被选择，那么otherwise分支将被选择，如图10-3所示。

　　图10-3 分支结构示例
 
　　在IBM的WPS中，用户可以使用Java代码，内置的数据（true或false等）等定义条件表达式。

　　8．While–While循环 

　　<while>活动也继承于传统的结构化编程思想，提供了while-do循环结构的支持。它可以包含一个或多个活动。它指定反复执行其内部活动，直到成功条件不被满足为止。在WPS中允许其使用Java代码来描述条件表达式。

　　9．Pick 选取（在WPS中被称为Receive Choice） 

　　<pick>活动会等待一组相互排斥事件中的一个事件的发生，然后执行与发生的事件相关联的活动。它会阻塞业务流程执行，以等待某一特定的事件发生，比如接收到一个合适的消息或超时警报响起。当其中任何一个事件被触发后，业务流程就会继续执行，pick也随即完成了，不会再等待其他事件的发生。

　　每个pick活动必须至少包括一个onMessage事件。onMessage事件的语义等同于有关变量属性的可选类型的receive活动。pick活动还可以定义onAlarm事件用于指定超时警报。

　　如图10-4所示描述了一个订单业务流程，它会利用pick活动来等待客户明确地确认或取消订单，并进行下一步处理，如果客户在指定的时间内没有响应，则会触发onAlarm事件并通知客户。

　　图10-4 选取活动示例
 
　　pick活动也可以作为业务流程的起始点，指定流程可以接收多种不同的消息，并让流程在接收到特定消息后创建新的流程实例来处理消息。这里与receive活动类似，我们需要将pick活动的createInstance属性设置为”yes”。当然这时候就不应该定义onAlarm超时事件。这是一个非常方便的特性，比如用户希望能够分别接收并处理来自网页、电子邮件或即时消息发送的请求，就可以通过pick活动非常自然地描述业务流程。

　　10.5 BPEL异常管理

　　faultHandlers、catch及catchAll元素 

　　活动执行过程中发生异常，业务流程必须对错误进行处理。与Java等语言类似，BPEL提供了异常处理机制。用户可以在业务流程中添加faultHandler来捕获并处理相应的异常。faultHandler与特定的Scope关联，用于捕获Scope内产生的异常。当异常发生时，BPEL正常执行流结束，控制流转入faultHandler内执行。

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

　　<faultHandlers>
　　 <catch faultName=”SomethingBadHappened” faultVariable= “TimesheetFault”>
 …
　　 </catch>
 <catchAll>
 …
 </catchAll>
　　</faultHandlers>
 
　　当异常在特定的Scope内产生时，如果被此Scope内定义的FaultHandler捕获，则该Scope状态被置位为Failed，当异常被处理后，外部Scope继续执行。如果异常无法被此Scope内FaultHandler捕获或无FaultHandler定义，则该Scope状态被置为Failed，并且将异常抛出到外部Scope继续处理，直到异常被处理为止。这个流程也与Java的异常处理机制非常相像。

　　10.6 BPEL事务与补偿机制

　　事务（transaction）对于软件工程师来说是一个非常重要的概念。按照非正式的表述方式，事务是指一组作为同一单元的活动，要么全部成功，要么全部失败。这种”全部或者没有”的语义是数据库访问的基础。按照正式的表述，事务包括如下属性：原子性、一致性、隔离性和持久性（Atomic、Consistent、Isolated和Durable）–ACID。

　　事务对于业务交互来说至关重要，为了保证一致性，一个ACID事务用到的数据库条目通常会在处理过程中被锁定。如果事务失败，数据库将会回退到之前的状态。这一功能由数据库提供商提供。

　　对于一组被调用的Web服务，BPEL也可以采用类似的思路，使用Web服务的相应规范来实现业务流程的事务支持。WPS 6.0提供了WS-Atomic标准的支持。

　　但是，通常我们无法锁定跨越企业的资源。当进行酒店预订时，您的旅行代理无法在预定过程中（或者在打预定电话的过程中）锁定酒店的预定数据库或者让系统主动停下来。取而代之的操作是，连锁酒店数据库的本地ACID事务作为一个整体，包括以下几个任务：更新房间总量，添加信息到预订表和生成一个确认号。如果旅行代理需要取消预定操作，一个补偿动作将被完成。某些时候补偿需要一定的代价。例如，如果预定取消得太晚，可能需要收取一定费用。

　　由于一个业务流程可能需要运行几天、几个月甚至几年，而且流程可能涉及外部服务。在流程完成前，单个活动有可能已经完成，如果随后某个事件或错误发生而导致流程取消，已经完成的活动需要被复原。这种情况下，我们无法使用简单的事务处理机制来实现回退，我们需要补偿支持来完成这一任务。

　　补偿是管理业务数据的一种特定方式，它总是业务逻辑的一部分。补偿与数据库为ACID事务提供的原子性回滚不同。补偿可以避免另外一个问题；Internet上的任何人都可以锁定公司的数据可能会引发的拒绝服务攻击。采用补偿方案意味着数据不会被长时间锁定，但同时也失去了ACID事务，至少隔离性保证无法满足，因为数据在最初的修改和补偿操作之间是可见的。在BPEL中，Compensation（补偿）用来还原已经完成的活动。一旦进行补偿，它就要流程中已经运行完成的所有活动都会依照特定的逻辑进行补偿。

　　在工作流中，每个Invoke活动的调用都被称为一个转发服务（forward service），用于执行特定的服务调用。相关联用于补偿调用行为的服务被称为补偿服务。补偿服务仅当转发服务完成时才能够被调用。当流程中发生故障时，执行可选的补偿服务来补偿转发服务的行为。当一个服务活动完成时，如果已经定义了补偿服务，那么就向工作流的补偿域（Compensation Sphere）注册补偿服务及其输入数据。在流程实例结束时，补偿域查看是否抛出了故障。如果这个流程成功地完成，那么就不需要补偿任何活动。另一方面，如果这个流程失败了，那么您就需要执行补偿。如果需要流程补偿，补偿域就会调用它在后进先出（last-in first-out）队列（与转发服务完成的次序相反）中注册的补偿服务。如图10-5所示是一个结合了错误处理与补偿机制的例子。第1个和第2个请求服务在同一个作用域中，它们都成功完成调用，作用域成功结束。属于流程作用域的第3个请求也成功完成。然而第4个请求调用却失败了，触发了错误处理程序。在第6步，错误处理程序执行补偿活动，将依次调用已注册的补偿处理程序，参见第7至第10步。

　　图10-5 错误处理与补偿机制示例
 
　　10.7 抽象流程

　　BPEL并不是只能用来指定可执行流程，您还可以用它来指定抽象流程。抽象流程主要用于定义某一个伙伴为了达到业务目的和它的其他伙伴交换的消息和可能的顺序。它可以被看做可执行业务流程的外部视图，省略了部分内部执行细节和复杂性。在BPEL中，描述抽象流程的语言是用于描述可执行流程的语言的子集，这使得您可以在同一种流程语言中指定可执行流程及其抽象视图。

　　一般来说，抽象流程可以用来呈现可执行流程的某些方面，通过抽象手段使得人们易于理解和沟通；或者以简单的抽象流程作为设计流程的起点，通过不断精化和改进，构建出复杂的可执行流程。抽象流程还可以用来实现协议匹配，来判断两个业务伙伴是否能够互相交互。

　　10.8 BPEL开发

　　BPEL作为一种可执行语言，不但需要良好的运行环境，也需要设计和开发支持。我们仅简单介绍一下IBM对BPEL建模和开发的支持。

　　WebSphere Business Modeler能够对企业业务流程进行建模，持续地优化执行业务的方式。它为业务线和IT员工提供全面的、用户友好的建模和协作能力，推动建模、工作流构建和模拟特性的无缝集成，如图10-6所示。

　　WebSphere Integration Developer V6.0通过提供易用的创作工具以使集成开发人员能快速地构建和调试复合的业务集成应用。它可以将WebSphere Business Modeler建立的业务流程模型导入并转换为BPEL，并部署到WebSphere Process Server上运行调试，如图10-7所示。

　　图10-6 使用WebSphere Business Modeler描述业务流程

 
　　图10-7 使用WebSphere Integration Developer开发BPEL流程
 
　　10.9 本章小结

　　在任何企业中建立业务流程使其自动化，都可以减小风险并且降低维护成本。随着BPEL技术的发展，您可以创建基于Web服务技术的业务流程。在本章，我们简要地讨论了业务流程管理的基本概念，重点介绍了BPEL语法和使用模式，包括一些比较复杂的特性，比如补偿和错误处理等。

　　关于作者

　　毛新生先生现任IBM中国开发中心Web 2.0首席架构师。此前他曾任IBM软件集团企业解决方案部大中华区和北亚地区首席架构师与IBM SOA中国设计中心技术主管，在企业级软件方面拥有广泛、扎实、深厚的理论功底和丰富的设计与项目实施经验。2006年，毛新生先生被授予“IBM资深技术主管”称号（STSM ，Senior Technical Staff Member），成为中国内地第一位获此殊荣的IBM技术人员，在全球也仅有1000多位IBM员工享有这样的荣誉。毛新生先生于2000年加入IBM，曾先后在北京大学和 IBM中国研究院从事研发工作，以研究人员，开发经理和架构师的身份从事过信息检索，语音技术及其中间件，门户，普及计算，Linux，网格计算，Web Service和SOA等领域的很多工作。毛新生先生毕业于北京大学，拥有计算机专业硕士学位。如果您想找到更多关于毛新生先生的文章，您可以搜索 毛新生的BLOG。