组合服务的一种方法是使用业务流程执行语言（Business Process Execution Language，BPEL）将服务定义为业务流程，或者将它们表示为业务状态机 (business state machines)。编排这样一系列服务的调用的主线代码在一个称为流程编排引擎 (process choreography engine) 的特殊容器中运行。容器提供的功能可以支持甚至跨企业的边界执行长时间运行的流程，承受计划的和未计划的停用，并且促进企业到企业（business-to-business，B2B）的协作。
这是我们关于 IBM 的面向服务的体系结构（Service-Oriented Architecture，SOA）的编程模型系列的第三篇文章。上一篇文章介绍了 SOA 编程模型的概念和服务数据对象 (Service Data Object)。
业务流程
业务流程编排中的服务编排的概念对于二十世纪七十年代的 FORTRAN 编程人员来说或许并不陌生。它只不过就是调用函数或者子例程的主线代码的概念，其中每个函数或者子例程实现了更大的程序的一个单独的部分。现在，在二十一世纪，子例程变成了 Web 服务。主程序的实现语言是用于 Web 服务的 BPEL（请参阅参考资料以获得更多关于 BPEL 的信息）。执行环境是 IBM WebSphere® Business Integration Server Foundation 中的 Business Process Choreography 容器。而程序可以将许多可能跨多个企业的长时间运行的任务组合在一起来实现一个业务功能。
图 1. 简单的业务流程
图 1
展示了一个简单的内部旅行审批和预订流程的 BPEL 流程，涉及检查请求数据的程序、实际管理审批的人工任务，以及为实际执行预订而与合作伙伴进行的 B2B 交互。
由于没有重复提及许多关于 BPEL 的参考资料和教程（请参阅参考资料），因此我们在这里概要地列出了 BPEL 的一些特性以及 IBM 的 WebSphere Business Integration 中的 BPEL 实现所提供的扩展：
-
可以与多个合作伙伴交互的长时间运行的业务流程。所有的交互都是通过标准的无状态 Web 服务调用执行的。相关性用来利用应用程序级数据处理特定的实例，例如根据员工序号审批某人的旅行请求。补偿功能用来在必要时（部分地）撤消流程的作用，例如，在已经预订了一个航班之后取消旅行请求。
-
将人员整合到流程。一些业务流程的步骤常常是人工执行的（例如，在审批或者异常处理工作流中）。这些步骤包括分配人员工作的复杂情景识别 (context-aware) 的情况，例如双人监控原则 (four eyes principle)，该原则规定第二个审批步骤由除第一个审批者之外的审批者来执行。这些要求可以通过将人工任务作为流程步骤来满足。Business Process Choreography 引擎和 IBM WebSphere Studio Application Developer Integration Edition 工具提供了对人工任务的支持。
-
将流程嵌入到 Java™ 2 Platform, Enterprise Edition (J2EE)，并且除 XPath（它是 BPEL 中的标准）之外，在流程中使用 Java 作为首选语言。当任何 Java 功能超出 BPEL 范围时，IBM 和 BEA Systems Inc. 就会在一个称为 BPELJ 的研究计划中提出对 BPEL 的 Java 扩展。这些扩展使编程人员能够使用 Java 代码段来实现流程中的活动，在 BPEL 允许表达式的地方使用 Java 作为表达式语言，以及使用 Java 操作流程中的工作数据。
-
服务质量。生产系统所需的服务质量扩展，例如微调事务边界、适当地修复错误情况或者产生审核日志的功能。
-
与 WebSphere 集成。流程编排引擎与事务引擎和 WebSphere 中的 Activity Service 集成在一起。与人有关的流程利用 WebSphere 用户目录和安全性。BPEL 流程是作为 WebSphere 应用程序部署的一部分进行部署的。业务流程的管理集成到 WebSphere 管理控制台中。
您可以使用 IBM Rational® 和 WebSphere 工具套件中的可视化业务流程编辑器来构建 BPEL 流程。将服务接口导入到资产视图 (asset view) 使您能够从 BPEL 流程调用外部服务。该工具套件还有一个用于调试流程的可视化调试器，包括调试长时间运行的流程的并行分支以及通过适当的用户界面与面对人 (human-facing) 的活动进行交互的功能。该工具套件同样也允许测试 BPEL 流程，以及将它们作为服务进行部署。
业务状态机
工作流过程与可能采取多个步骤和路径的动作或动词——例如，CreatePurchaseOrder 或者 BookTravel——相似，调用许多 Web 服务、Java 类或 Enterprise JavaBeans (EJB)。
如果工作流过程是一个动词，那么业务状态机就是一个表示事物 的名词，例如订购单、故障单或保险单应用程序。这里，动词——例如 CreatePurchaseOrder 或 BookTravel——是对事物的操作。业务状态机上的操作可以调用任何服务，例如直接通过状态机指定的 BPEL 流程或者 Java 代码。
两种方法——过程或者状态机——中没有哪个是更好的。两者在功能上都是等价的服务抽象。无论选择哪一个对当前任务来说都是很好的服务抽象。
业务状态机是由状态转移图以图形方式指定的，状态转移图显示其状态、状态间可能的转移和触发状态转移的事件，以及作为结果的操作。图 2 是一个表示 PurchaseOrder 的简单状态机的流程图。
图 2. 表示订购单的业务状态机
节点（矩形）表示 PurchaseOrder 的可能状态，可以是 Created、Ready、InApproval、Purchased、Canceled、Shipped、Delivered 或者 Archived。弧线（箭头）表示可能发生的事件，导致 PurchaseOrder 从一个状态转移到另外一个状态。
业务状态机可以通过 BPEL 流程来实现。如果这样的话，事件就仅仅是 Web 服务描述语言 (WSDL) 所描述的流程的 portType 上的操作。当前状态（存储在一个变量中）决定了哪些事件（操作）是活动的。如果调用者试图调用无效的操作，那么运行时将抛出异常。您也可以查询状态机的当前状态来确定操作的有效性。
当一个事件发生时（例如，当调用一个操作或者定时器超时的时候），状态机转换到新的状态并执行与这个转换相关联的动作（例如调用操作或者方法）。在图 2 中，转移是通过带有事件注释的弧线、可选的条件以及将要执行的动作来反映的。转移只在其相关联的条件为真时才执行。在状态进入和退出时可能执行其他动作。在图 2 中，处于 Ready 状态的状态机具有两种可能的事件（已启用的操作）：purchase 和 Cancel。对于 purchase 操作来说，有两个可能的条件：要么需要审批，要么不需要审批。
当调用者调用购买操作时，业务状态机框架执行以下操作：
- 确定操作对于当前状态是否有效。
- 执行状态的退出动作（如果存在的话）。
- 计算与该事件相关联的所有转移的条件。假定对于此次购买需要审批，就选择转移到
InApproval 状态，而忽略到 Purchased 状态的转移。
- 执行与该转移相关联的动作，在本例中即
doApprovalAction()。例如，这个操作可能发送电子邮件给销售经理或者简单地调用另一个 SOA 组件（如 BPEL 流）上的操作。
- 进入新的
InApproval 状态。
- 执行新的状态的进入动作（如果存在的话）。
您可以使用 Rational/WebSphere 工具套件的可视化业务状态机编辑器来创建业务状态机。这个工具以类似的方式处理业务状态机和业务流程：它们可以具有相同的外部服务关系，并且它们的测试和部署环境完全相同。
总结
IBM 用于 SOA 的编程模型提供了若干构造新的面向服务的应用程序或者将现有的应用程序组合成服务框架的方法。本文重点介绍了使用业务流程执行语言的业务编排方法，它与调用传统的过程性编程中的子例程相似，增加了对于长时间运行的工作和并行工作的支持。业务状态机是另一个编程模型构件，它可以用 BPEL 来表示。没有哪种方法是更好的。选择最适合当前问题的方法。后续的文章将介绍其他组件类型，它们是 SOA 开发人员的常备工具。