毛 新生, Web 2.0 首席架构师，资深技术主管
2007 年 9 月 18 日 从亨利福特开始通过装配线生产福特汽车，直到今日，我们一直都在想办法来更好地、更快地、更可靠地、更经济地完成工作。业务流程是一种非常好的方法。业务流程可以被定义为一个具有各种不同功能的活动相连的一组有相互关系的任务。如何将分布的Web服务组合实现业务流程，对企业实现全球化和虚拟化具有重要意义。BPEL（Business Process Execution Language，业务流程执行语言）是业界认可的标准，也是SOA实现组合服务和服务编排的重要技术基础。这是《SOA：原理方法实践》的第 10 章。本章将重点介绍 BPEL 的基本特性和使用模式。
引言
《SOA：原理方法实践》是一本全面探讨 SOA 理念、SOA 方法学、设计模式和案例分析的书籍。这本书由 IBM 新技术研究院 Web 2.0 首席架构师毛新生领衔执笔，汇集了IBM 软件开发中心众多 SOA 专家们的经验和智慧。
本书首先从作者的实际经验出发，分析 SOA 产生的根源，然后分析 SOA 的相关开发技术，最后结合实例讲述完整 SOA 项目的开发过程。我们将陆续推出此书的第 1、4、10 章。
更多推荐书籍请访问 developerWorks 图书频道。
如果您对本书有任何的建议、意见或者问题，欢迎与本书作者和 IBM 技术专家 交流。
第 10 章：业务流程简述
 | |
|
|
书名：《SOA：原理•方法•实践》
作者：毛新生 主编
出版社：电子工业出版社
出版日期：2007 年 07 月
ISBN：978-7-121-04264-5
购买：
中国互动出版网 、dearbook
| |
推荐章节:
更多推荐书籍，请访问 developerWorks 图书频道。
如果您对本书有任何的建议、意见或者问题，欢迎与本书作者和 IBM 技术专家 交流。
|
|
|
业务流程可以被定义为一个由各种不同功能的活动相连的一组有相互关系的任务，它们依照一定的业务逻辑和顺序依次执行。业务流程有起点和终点，而且它们都是可重复的。业务流程是企业实现商务目标的方法。对于企业而言，业务流程是企业重要的知识资产，是企业的核心竞争力的体现，一个精心设计和执行的业务流程能够为企业创造价值并节约成本。
在著名作家佛里德曼的获奖作品《世界是扁平的：21世纪简史》（THE WORLD IS FLAT: A Brief History of the Twenty-first Century）一书中，对经济全球化有着精彩的论述。它描绘了一个由互联网、通信基础设施和新型软件搭建的全球舞台；在这个舞台上，人们能够以多种方式分享知识、劳动、娱乐和发现，并且创造新的商业机会。佛里德曼举例说："如今沃尔玛是美国最大的公司，然而它什么也不生产，只是建立了这个非凡的供应环节，从世界各地进口非常便宜的商品……并把世界各地的产品送到消费者手里。它是一个全球组装线。"
在经济全球化的过程中，企业的边界变得模糊，企业会将任务分解为一系列的子任务，企业只关注于自己的核心竞争力所在，并将其他工作分包给最合适的人来完成。企业需要通过业务流程将这些片断有机地组织在一起。在这里我们可以深刻地认识到业务流程对企业的重要性。
定义业务流程并对其做出文档所花费的时间和努力是完全值得的。在一个反映中国传统医学的电视剧中，当配置药剂的时候，掌柜把自己反锁在药房里，只有他会根据"秘方"将不同的药材调配成救死扶伤的灵药。然而只有他一人掌握这个过程是非常危险的。对于现代企业来说这更是不可能的，我们不可能只让配件制造主任了解企业的配件制造知识，然后让他每晚独自装配所有的零件。只要定义了配件制造业务流程，配件制造工人可以随时来去，而且任何配件制造工人都可以随时取代另一个人的工作，这是因为工厂里的所有配件制造工人都理解并遵循业务流程。我们可以学习、改变、评估，然后再次改变配件制造业务流程，因为该流程对于每个人都是可见的，而非局限于配件制造主任。
现代业务流程管理系统的历史可以追溯到工作流系统。简单地来讲，工作流定义了业务流程中的参与者（Who）、所执行的工作（What）及何时执行（When）。在企业IT环境中，工作流软件通常与企业应用集成（Enterprise Application Integration，EAI）系统结合在一起，成为企业应用的"黏合剂"，实现业务流程的自动化和流水线化。
传统工作流系统的最大缺陷就是：它们大多采用了专有技术。这使得业务流程与企业应用的结合变得非常复杂，通常需要很长时间进行部署和实施，而与企业外部系统进行集成则更加困难，无法适应全球化浪潮和互联网时代对企业灵活、无缝集成的需求。人们开始考虑利用Web服务的开放性和标准化，来解决业务流程与企业应用之间的互操作性问题。
10.1 BPEL 简史
2002年7月，IBM、微软、BEA提交了Business Process Execution Language for Web Services（BPEL4WS）1.0的规范。业务流程执行语言基于XML和Web服务技术，它融合了早期的IBM的Web Services Flow Language（WSFL）及微软的XLANG规范的很多特点。
随后许多主要供货商如SAP和Siebel（已被Oracle并购）等公司陆续加入规范的制定，并催生了多项修改和改进，并于2003年3月发布了1.1版。2003年4月，BPEL被提交结构化信息标准促进组织（OASIS）以实现标准化，并组建了Web服务业务流程执行语言技术委员会（WSBPEL TC），该努力使BPEL在业界获得更为广泛的认可。目前该技术委员会正在致力于下一代规范的制定工作，并将该规范重命名为WS-BPEL 2.0。
虽然除BPEL之外还有一些业务流程规范，但是到目前为止，BPEL是最为成熟和被广泛支持的技术。WebSphere Process Server 6.0提供了BPEL4WS1.1规范兼容实现，并支持制定中的WS-BPEL 2.0草案。除此之外还增加了对人员任务（WS-BPEL Extension for People）和Java语言（BPELJ）等扩展的支持。在下文中，我们将利用WebSphere Integration Developer 6.0和WebSphere Process Server 6.0来演示如何创建和运行BPEL流程。
关于本文涉及的 BPEL规范，可以从下面网址获得：业务流程执行语言（1.1 版）
10.2 BPEL的基本特性
相对于对象组装技术，服务组装更为复杂。人们必须面对SOA环境中异构的、松耦合的、自主的服务。它们间的交互关系是动态的、按需发生的，而且缺少中央控制。因此，BPEL提供的服务组装模型提供了下列特性。
（1）灵活性：服务组装模型应该具有丰富的表现能力，能够描述复杂的交互场景，而且能够快速地适应变化。
（2）嵌套组装：一个业务流程可以表现为一个标准的Web服务，并被组装到其他流程或服务中，构成更粗粒度的服务，提高了服务的可伸缩性和重用性。
（3）关注点分离：BPEL只关注与服务组装的业务逻辑；其他关注点，比如服务质量（QoS，Quality of Service），事务处理等，可被作为附加扩展，由具体实现平台进行处理。
（4）会话状态和生命周期管理：与无状态的Web服务不同，一个业务流程通常具有明确的生命周期模型。BPEL提供了对长时间运行的、有状态交互的支持。
（5）可恢复性：这对于业务流程（尤其对长时间运行的流程）是非常重要的。BPEL提供了内置的失败处理和补偿机制，对于可预测的错误进行必要的处理。
10.3 BPEL模型
BPEL模型可以帮助我们更好地理解如何使用BPEL描述的业务流程，如图10-1所示。流程（Process）由一系列活动（Activity）组成；流程通过伙伴链接（Partner Link）来定义与流程交互的其他服务；服务中可以定义一些变量（Variable，在BPEL4WS中被称为Container）；流程可以是有状态的长时间运行过程，流程引擎可以通过关联集合（Correlation Set）将一条消息关联到特定的流程实例。
图10-1 BPEL模型示意
1．伙伴（Partner）
在BPEL中，一个流程可以调用其他服务，也可以响应来自客户端的请求。也就是说BEPL流程实例既可以作为服务的请求者，也可以扮演服务的提供者。BPEL把与流程交互的其他服务称为伙伴（partner）。在异步通信环境中，流程与伙伴之间的会话可能是双向的，这在复杂的商务流程中非常常见。
在流程与伙伴的通信过程中，它们会扮演不同的角色。比如当订单流程被外部服务调用的时候，它作为"PurchaseOrderProcess"角色来提供服务，然而当它请求发货服务的时候，它则扮演"InvoicecClient"角色，如图10-2所示。由于在流程执行过程中，一个流程可能会调用多个伙伴服务，又可能接收多个伙伴的请求，因此为了消除在通信过程中的多义性，我们需要明确服务和流程所扮演的角色。
图10-2 订单流程示意
在BPEL中，这种流程与伙伴的合作关系是通过<partnerLink>元素来定义的。这样如果在流程的活动中需要指定与特定伙伴的交互，只需要引用partnerLink的名称即可。而且通过partner links的抽象，在流程建模时，我们不必指定具体的服务端点，而将流程与具体服务的绑定推迟到组装或运行时来完成。这种动态伙伴关系为流程带来了极大的灵活性，也增强了流程的可复用性。比如，我们在开发环境中使用的伪服务实现，在生产环境中无需须修改流程就可以将服务端点替换为主机应用。
在<partnerLink>元素中，可以通过"myRole"和"partnerRole"属性来定义流程和伙伴的角色。如果流程作为服务的提供者，需要使用myRole属性，而当流程作为服务的请求者时，则使用partnerRole属性。
partnerLink通过引用partnerLinkType来定义流程与伙伴服务之间的通信接口（实际上是WSDL文档中的Port Type）。伙伴链接类型声明了两个（也可能是多个）服务之间的关系。服务链接类型定义了一组角色，其中每个角色指明一组Port Type，即明确了该角色所提供的服务接口。partnerLinkType通常被定义在WSDL文档中，被BPEL流程所引用。
下面的代码片段显示了如何利用partnerLink和partnerLinkType定义流程与伙伴的合作关系。我们实现了一个股票购买流程，在这个流程中需要通过伙伴StockQuote获取当前股票信息：
<bpws:partnerLinks>
<bpws:partnerLink myRole="StockServiceRole" name="StockService"
partnerLinkType ="ns:StockServicePLT"/>
<bpws:partnerLink name="StockQuote" partnerLinkType="ns:PartnerPLT"
partnerRole ="partnerRole"/>
…
</bpws:partnerLinks>
|
我们还需要在流程对应的WSDL文档中定义partnerLinkType：
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:
plnk="http:// schemas.xmlsoap.org/ws/2004/03/partner-link/" … >
<plnk:partnerLinkType name="StockServicePLT">
<plnk:role name="StockServiceRole">
<plnk:portType name="wsdl0:StockService"/>
</plnk:role>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="PartnerPLT">
<plnk:role name="partnerRole">
<plnk:portType name="ns:net.xmethods.services.stockquote. StockQuotePortType"/>
</plnk:role>
</plnk:partnerLinkType>
<import location="urn_xmethods-delayed-quotes.wsdl" namespace=
"http://www. themindelectric.com/wsdl/net.xmethods.services.stockquote. StockQuote/"/>
</definitions>
|
2．变量（variables）
在BPEL中，我们可以使用变量来保存和传递流程的状态信息。变量的数据类型由WSDL定义，既可以是XML Schema内置的简单类型，又可以是自定义的复杂数据类型：
<bpws:variables>
<bpws:variable name="symbol" type="xsd:string"/>
<bpws:variable name="UserInfo" type="ns1:UserInfoBO"/>
...
<bpws:variables>
|
上面的代码，展示了如何在BPEL中使用<variable>元素来定义变量。值得注意的是，与常见的编程语言类似，BPEL中的变量是有作用域的；每个变量只有在定义它的作用域和所包含的作用域内才是可见的。在下面的章节中，我们将介绍如何使用BPEL来操纵和传递数据。
此外，WS-BPEL提供了一些内置的函数来支持变量内容的处理：
（1）getVariableProperty（variableName, propertyName）为获取变量属性函数：输入参数为变量名称和属性名称，结果为属性值。
（2）getVariableData（variableName, partName?, locationPath?）为获取变量数据函数：输入参数为变量名称、part名称，以及XPath表达式，其中partName，和locationPath为可选参数。输出结果为指定变量的全部或部分的数据内容。
3．活动（Activity）
BEPL流程是由一系列步骤所组成的，它们被称为活动。WS-BPEL定义了丰富的活动类型，一般来说可以把它们划分为两大类：基本活动和结构化活动。基本活动描述了流程内的一个具体步骤，比如接收请求、调用伙伴服务、变量赋值等。而结构化活动则描述了如何组织和管理流程的控制流。在下面的章节中，我们将对活动进行详细讲解。
4．关联集合（Correlation Set）
BPEL提供了声明性机制，以指定服务实例中相关联的操作组。一组相关标记可定义为相关联的组中所有消息共享的一组特性。这样的一组特性称为关联集合。每个关联集都在一个作用域中进行声明并属于该作用域。属于全局流程作用域的关联集称为全局关联集；属于局部作用域的关联集称为局部关联集。在流程开始时，全局关联集处于未初始化的状态。在其所属的作用域的执行开始时，局部关联集处于未初始化的状态。
相关集在其语义上类似于延迟绑定的常数。相关集的绑定由特别标记的消息发送或接收操作来触发。相关集在其所属的作用域的生存期中只能初始化一次。在初始化之后，它的值就可被认为是业务流程实例的标识别名。在多方业务协议中，相关集合非常有用。初始者流程发送启动会话的第一个消息，从而定义了标记该对话的相关集中的特性值。所有其他参与者通过接收提供相关集中的特性值的传入消息来绑定会话中的相关集。比如一个旅行社订票流程，当该流程启动之后，用户需要能够查询该流程状态，并能取消该流程，这就需要相关集的支持来确保后续的请求消息绑定到相同的流程实例中。
10.4 BPEL活动
我们将首先介绍常用的基本活动。
1．Receive（接收）/ Reply（回答）
<receive>活动从流程的外部伙伴那获取数据，并将其保存到流程变量。通常一个Receive是一个流程的初始点，它会阻塞执行直到匹配的消息的到达。
<reply>活动发送消息给伙伴来应答通过receive活动所接收到的消息。receive和reply的组合对应着WSDL portType上定义的一个请求-响应操作。如果receive活动对应着一个单向（one-way）操作，则不能在流程中定义对应的reply活动。
<bpws:receive createInstance="yes" name="Receive" operation="buy"
partnerLink ="StockService" portType="ns0:StockService" />
…
<bpws:reply name="Reply" operation="buy" partnerLink="StockService"
portType=" ns0:StockService" />
|
上面就是BPEL中包含receive和reply活动的片段。值得注意的是，receive和reply活动中都是通过"partnerLink"来引用预定义伙伴关系的，而且需要设置"portType"和"operation"属性来声明流程实现的WSDL portType和操作。此外，如果将receive活动作为流程的起始点，则需要将receive活动的createInstance属性设置为"yes"，它指明了当流程接收到匹配的消息时会创建新的流程实例来处理该请求。在BPEL流程中我们还可以定义更为复杂的消息响应机制，可以将特定的消息关联到相应的流程实例中。CorrelationSet（关联集合）就是为了解决上述问题而出现的。
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语法和使用模式，包括一些比较复杂的特性，比如补偿和错误处理等。
参考资料
-
以服务为中心的企业整合讨论企业整合（集成）的新发展：以服务为中心的集成（Service-Oriented Integration，简称 SOI）。 您将了解到什么是 SOI，推动 SOI 发展的因素以及SOI 带来的价值。作者讨论了 SOI 解决方案所涉及的要素，和这些要素相关的技术、标准以及IBM的产品支持，最后作为总结将它们包括在 IBM 的集成参考架构中，指出如何实现各种集成需求。
-
以服务为中心的企业整合－案例分析以一个经过简化的实际案例为例，介绍了以服务为中心的企业集成的基本步骤，从业务分析，到服务建模，到架构设计，到系统开发的整个生命周期。以服务为中心的企业集成涉及到的主要技术被穿插在各个步骤中进行了详细的讲解。
-
IBM SOA 企业架构师工具包——利用 IBM 提供的企业体系结构软件开发工具使您的业务需求与 IT 相符合。
-
SOA 落地中国专栏与 IBM 中国开发中心合作，收集了 IBM 工程师在中国实施 SOA 解决方案的经验。希望这些来自中国 SOA 专家的文章能给您企业的实际问题带来解决思路。
- 访问本书的 前言和目录。更多推荐书籍请访问 developerWorks 图书频道。如果您对本书有任何的建议、意见或者问题，欢迎与本书作者和 IBM 技术专家 交流。
关于作者 | 
| | 毛新生先生现任 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。 |
对本文的评价
| 
