过程组件模型：下一代工作流？

介绍

Tony Bear ：

BPM 族人来自金星，WS 族人来自于火星

这准确道出了 BPM 行业中或许并不明显的巨大分歧。“BPM 族人”是指那些专注过程建模的人。他们的出发点在于分析那些描述组织内人和系统协作方式的过程。在建模者眼中，最初的焦点并非技术，而是描述人和系统协作方式的非技术业务分析。过程自动化在许多这类 BPM 项目中甚至根本未被考虑。这些项目的最终目标实际是要通过记录核心业务过程来更深入地了解组织是如何运作的。由这个背景所产生的纯 BPM 产品旨在通过软件自动化来简化对这类业务过程的描述。这个阵营我称之为 BPM 建模者。

“WS 族人”是指那些专注创建可执行过程的人。可执行过程是作为业务过程管理系统（BPMS）输入的软件部件。它通常由图形化的图表表示。目前，只有一种可执行过程语言被大型提供商采用，它就是 BPEL 。BPEL 是基于 WS-* 标准的，这也是那些专注自动化的人被称为“WS 族人”的原因。随着 BPEL 逐渐得到认可，服务编制最近也受到了吹捧。这个阵营我称之为编制开发者。

两个流派的共同之处在于都关注图形化的图表且都包括了等待状态。对 BPM 建模者和编制开发者来说，图表是一个很重要的工具。图表能为某个过程提供一个快速概览。尽管这是个强大的工具，但对于这种可察觉的简单性要保持警惕。因为，看起来相似的图表会由于所使用的符号或底层可执行过程语言的不同，其含义会有巨大区别。另外，图表的用途也是一个非常重要的考虑因素。对于业务分析师来说，过程图表的目的是为了帮助向另一个人解释业务过程。这些图表提供了一个整体概览，一定程度的模糊性是允许的。对于可执行过程语言，图表是定义计算机系统必须遵循的行为方式的过程的一部分。因此，这种过程必须含义明确且能被准确地解释。

本质上，等待状态的包含是个更技术性的话题，但在两个流派中也都找到它的踪迹。当业务分析师绘制业务过程时，不同的活动可能会关联到不同资源。一些活动会翻译成人工任务，而另一些则会翻译成可在计算机系统中执行的一段软件代码。假如这一过程是自动完成的，过程引擎会驱动过程的执行。这意味着引擎内部会自动地执行一些活动。否则，如果活动在过程引擎外执行，那么引擎就需要跟踪当前状态并在接收到外部实体发来的信号前保持等待。例如，这个外部触发器可能是用户对 Web 应用中表示任务完成按钮的一次点击。类似的还有，ERP 系统可能通知过程引擎某个发票已经处理完毕。等待状态的概念或许显得有些抽象，你或许会问这和工作流或过程语言的讨论有什么关联性。一个重要原因就是象 Java 这样的传统编程语言不支持可持久化的等待状态。

这篇文章认为业务过程的分析和实现间的差距远比当前工作流工具市场所显现出的还要大。同时，本文还提出了解决这种状况更现实的办法。文中对当前标准和项目进行了足够深入地探讨，以便让你可以理解它们与这些流派的关联方式及其原因。在讨论中，我会指出每一个被提及技术的优缺点，以及正确使用它们的方式。

文末，我会介绍一种名为过程组件模型的工作流新技术。这种框架可以处理多种过程语言，为那些能将分析过程图更好地转换成可执行过程的过程语言提供了支持。

WS-BPEL

什么是 BPEL

WS-BPEL 是一个用于服务编制的 OASIS 标准。服务编制就是将一组现有服务组合成一个新服务。

这是对 BPEL 过程的简单地剖析：部署一个 BPEL 过程会导致为该过程发布一个服务。这个 BPEL 过程会指定必须发布的服务，以及这些服务操作的实现。

接下来以图 1 显示的过程为例，我们会通过解释一些最典型的 BPEL 活动来向您展示一幅关于 BPEL 基础的优秀画卷。在 BPEL 过程中，每一个接收（receive）活动都对应一个过程部署时要发布的服务操作。最上面的接收活动 _receiveOrder_ 是一次新的过程执行的起点。因此，每当客户调用左边的订购（order）操作，就会通过离开初始接收活动来启动一次新的过程执行。

下一步是调用（invoke）活动。调用活动会调用另一个 WSDL 服务并将响应消息收集到一个过程变量里。在我们的例子里，_getQuote_ 在供应商上被调用。

来自输入消息的信息可以被存储在过程变量中。整个消息都可以被存储，包括 XML 片断或 XSD 基本类型。象 _extractProductName_ 这样的赋值（assign）活动可以从一个变量中（一般是基于 XML 的内容）提取部分信息，然后将之保存到另一个变量中。这样，变量就可被用来为其他调用或当前请求的响应合成消息。

接收活动 _receiveQuote_ 将使过程实例处于等待状态，直到提供商调用 _submitQuote_ 服务操作。拥有 _submitQuote_ 操作的服务也会在 BPEL 过程部署时发布。当供应商传入了与这个订单有关的报价后，过程将继续执行并离开 _receiveQuote_ 活动。

应答（reply）活动用来为未完成的服务请求组织一条响应消息。因此，应答活动只有在这种情况下才有意义：在进入一个具有 IN-OUT 消息交换的服务操作前，接收操作接收到了一条消息。

注意，在供应商调用 _submitQuote_ 操作时，输入消息必须通过离开这个接收活动来触发过程继续执行。这是 BPEL 的另一特性，它被称为关联（correlation）。在 BPEL 过程中，关联是指输入服务请求消息和当前正在等待此消息的过程实例间的匹配。假如一个接收节点被标记为开始，该操作上的输入消息将会创建一个新的过程实例。一般说来，输入文档中的某些数据项这时会被标记为一个唯一的关联 ID，如订单 ID。根据输入消息文档中包含的订单 ID，过程中接收节点的输入消息稍后会关联到对应的过程实例上。在现实中，关联集可以由多个属性的多个个体集合组成，但为了简单起见，那些额外的复杂性略去不谈。

伙伴链接（partner links）用来标识那些参与 BPEL 过程通信的外部团体。从 BPEL 过程到伙伴的服务调用和伙伴对 BPEL 过程的调用都关联到伙伴链接。这两个方向都被称为角色（roles），每一个角色对应一个端口类型（port type）。端口类型指定了伙伴链接中该方向的通信接口。因此一个伙伴链接可以声明两个角色，需要指出这两个角色中的哪一个代表了 BPEL 过程端。与伙伴链接中 BPEL 过程角色相对应的服务会在部署过程的时候发布。另外一个则会在服务调用时使用。

这里总结了 BPEL 的大部分基本内容。另外一些是 BPEL 的更高级特性，如补偿处理（compensation handling）、事件处理（event handling）、并发执行路径和定时器。因它们与以后的讨论没有太大的关系，所以没有在这里介绍。

对 BPEL 的思考和评论

让我们近距离看一下上述过程的控制流程。这三个服务调用一起揭示了 BPEL 语言的关键动机，即简化异步服务交互的处理。在客户侧，客户端软件发出一条请求消息后就会被阻塞，直到收到该服务调用的响应消息。这就是 IN-OUT 消息交换模式。假设服务绑定使用 SOAP over HTTP，这意味着该 HTTP 请求在响应通过相同的 TCP/IP 连接发出之前都应该被阻塞。同时，在另一侧过程自己也要等待提供商来执行 _submitQuote_ 回调。

所有的这些在企业服务总线（ESB) 环境中都有很大的意义。ESB 的思想是：多个组件按标准方式进行连接，然后通过总线与其他组件进行通信。总线上交换的消息也是标准的（通常基于 WSDL/XML）。一组适配器充当协议（例如 SOAP over HTTP、email、FTP、RMI）和总线之间的网关。

WS-BPEL 也是基于 WSDL 的，自然能绑定到基于 XML 的技术（如 Web 服务）。

此外，企业应用也可以被连接到服务总线上。一旦任何东西在总线上都可作为一个服务使用，就像与 ESB 的交互也是基于 WSDL 的一样，BPEL 因其技术基础是 WSDL 而显得意义非凡。因此，ESB 是 BPEL 引擎理想的栖息地。

ESB 主要关注在基于 XML 的服务之间交换基于 XML 的消息。BPEL 从来没有脱离 XML 文档。XPath 一般用于剪贴输入文档的片段，然后将之保存到过程变量中。被调用的服务、被暴露的服务和过程变量都是以 XML 为基础的。执行逻辑也直接用 XML 表示。在某种程度上这是个优势，因为无需在 XML 信息结构和编程语言对象之间进行转换。对于复杂文档和对象结构，这种转换从来都不是透明和自动的，需要进行开发和运行时性能调优。

BPEL 复杂的关联能力使之可以很方便地使用现有消息交换而无需任何修改。不用将过程实例 ID 放入消息或上下文的头部，BPEL 引擎可以根据交换文档中的任何信息片段完成关联操作。这种在每一个文档交换中标识数据项和它们与其他文档交换匹配的方法可以非常灵活。这非常有用，因为在很多集成场景中你无权控制交换文档所用的通信协议。

但与业务过程管理（BPM）的联系从何谈起呢？从 BPM 建模者的角度看，这种关联是有疑问的。我唯一找到的现实联系是基于良好的市场营销而非特性。对于 BPM 建模者来说，BPEL 缺少了几个重要的基本特性。但是当你在一个你无法控制和哪个伙伴进行文档交换的 ESB 环境中用它编写新服务的时候，BPEL（即使不包括扩展）是完备的。因此，就像 Maserati 和 Hummer（译者：两种汽车品牌），喜好与否的关键在于你如何用它。

我能发现的唯一关联是 BPEL 过程可以用图表示，以及语言支持等待状态。这意味着某些由业务分析师创建的过程模型可以被转换成 BPEL 过程。但是这种方法有两个主要的局限性。第一，业务分析师被假定为非技术人员。所以，分析模型中的活动与现有 Web 服务相对应的机会非常少（意思是：不存在）。第二个问题是 BPEL 是块（block）结构。分析模型通常是以图为基础的。因此，一般说来，不加修改的把分析图转换成 BPEL 可执行过程是不可能的。这也是 BPMN 与 BPEL 难以映射，以及局限性如此之多的原因。

使用 BPEL for BPM 的最突出的矛盾在于：分析员被假定为不懂技术，而 BPEL 过程中的活动最终对应到 Web 服务调用。此外，BPEL 过程的块结构天性对于建模也有太多的限制。分析员需要自由地画出方块和箭头，它总是产生一个图结构和任意循环（arbitrary cycles）。BPEL 过程并没有变迁的概念。相反，一个BPEL 过程是一个组合结构，其顶级活动是一个顺序活动（sequence）。这个顺序活动包括一个嵌套的活动序列。其中一些是基本（或原子）活动，而另一些是复杂活动。复杂活动又会包含一个嵌套的活动序列。通过好的工具，这些自上而下的活动可以很方便地被用来创建一个BPEL 过程。但是将一个分析模型映射到一个BPEL 过程则是完全不同的事情，并且很难说这种不同很小。

使用BPEL for BPM 的另外一个问题是BPEL 有限的数据处理能力。从XML 文档中提取内容片段是你在服务编制中最需要的功能。但对于BPM 来说，过程步骤之间通常需要完成大量的数据处理。XPath 和其他的基于XML 的转换技术显然是不够的。

如果你是打算使用BPEL for BPM 的架构师，你应该扪心自问一下是否想让核心业务数据出现在ESB 中。在IT 行业从存储过程转移到如JEE 这样的企业技术过程中，对构建数据在“云中”的新应用的管理更方便了。BPEL 引擎需要维护的数据和领域模型（如顾客、客户、提供商等等）有关。这些领域数据通常存储在IT 基础设施的关系数据库中。核心业务过程中的信息必须能够很方便地链接到关系数据库中的领域数据。假如你的JAVA 应用需要了解一个文档的客户引用怎么办？你想将那个文档作为过程参数传给BPEL 引擎，然后使用XPATH 从那个XML 文档中抽取引用吗？这就暗示这个信息应该包含数据库的领域模型中，而不是在BPEL 引擎中。BPEL 并没有阻止你把这种信息存储在领域模型数据库中，但是它为这种做法添加了困难。你可能必须实现一个特殊的Web 服务来获取存储在领域模型中的客户引用。所以，BPEL 可能会很容易让你的领域模型信息支离破碎。要小心。

David 的 BPEL 反例（Case against BPEL），Joe McKendrick 就 David Chappell 的博客所写的文章，以及Jeff Davis 的“BPEL 怎么了（What’s wrong with BPEL）”，都持类似的观点：BPEL 不适合BPM。

别误会，我没有贬低BPEL。我的观点是BPEL 非常适合将一组现有服务组合成一个新服务。但从我们目前所了解的情况看，它没有交付它对于BPM 的承诺。

BPEL 扩展

BPEL4People 定义了在 BPEL 过程中包含人工任务的方式。BPEL4People 使用 BPEL 扩展机制将人工任务作为活动加入到一个 BPEL 过程中。这个规范定义了 BPEL 引擎和任务组件之间的消息交换协议。BPEL4People 引入了人员链接（people link）的概念。任务分配就是对负责一项任务的人员或组的选择（Selection）。BPEL4People 规定了人员或组的描述方式。但是，对于选择（Selection）的运行时计算和身份信息结构并没有包括在规范当中。最近，支持 BPEL4People 的公司决定将此规范提交给OASIS 进行标准化。因此，在不久的将来有望在大多数BPEL 实现中找到BPEL4People。

BPEL4People 加入的工作流功能，通常被视为是对 BPEL 修正，这有助于 BPEL 更好的与 BPM 相适应。但这种情况不现实。当分析员建模活动时，他们通常将之对应到人工任务或系统处理。BPEL 仍然强制活动之间的通信需由基于 XML 的过程变量完成。如果开发者需要加入一个使用 XSLT 的转换，即使业务分析师根本不关心这个技术细节，它也会是一个突然出现在图中的新活动。BPEL 过程图的图形活动布局仍然与 WEB 服务和 XML 技术的耦合过于紧密，以致于无法在保持分析图完整的同时使过程可执行。

BPELJ 是一个旧的白皮书，它是关注Java 和BPEL 过程绑定的标准提案。其中涵盖了多个方面内容，如在BPEL 过程中包含Java 代码片段，将Java 对象作为变量和从BPEL 过程调用Java beans。JCP 中的 JSR 207 Process Definition for Java 试图将此作为 Java 标准。但自从 2003 后，就没有看到这方面的任何进展。

即使有了这些扩展，BPEL 的主要问题依旧存在。当它用于业务过程管理时，它不能很好地支持过程建模。业务分析师在建模时不能自由发挥，因为图需要与 WSDL 服务建立直接和紧密的关系。BPM 需要将图和底层技术解耦。分析师必须能完全自由地画图，而开发者必须能够在不改动图的情况下把过程执行嵌入到应用架构中。BPEL 对此无能为力。这意味这 BPEL 很烂吗？不。假如 BPEL 被作为一种从细粒度服务中创建粗粒度服务的集成技术来使用的话，它拥有你需要的一切特性。

BPMN

什么是 BPMN

BPMN 目前被作为一种建模符号使用。它定义了用于过程建模的方框和箭头的外观。对于 BPMN 是否应该定义执行语义和它是否应该只关注图形表示的问题上，以前和现在都有非常多的讨论。

这个规范包括图形形状，含义描述和每个结构的属性集合。BPMN 期望解决 BPMN 结构和属性与特定过程执行语言的映射问题。规范本身就包括了一个这样的 BPMN 和 BPEL 映射。BPMN 没有定义 XML 或其他文件格式。一个可能性是 BPDM（见下）在未来会定义一个这样的文件格式。在给出对于 BPMN 的思考和观点之前，我想首先给出一些关于分析过程和可执行过程之间差异的更多背景。

分析和执行

当某人用方框和箭头画了一个图，这个图可以表示许多不同的事物：

• 文档，向其他人解释人和系统是如何一起工作来达成某个目标的
• 一个可执行过程，就像任何其他软件一样，向计算机系统解释其行为方式
• 一个与某个软件技术部件（如 Java 类）相关联的状态机，它可能和任何业务过程都没有关系
• 一种通信协议，描述多方间的消息交换
• Web 应用的一组页面，箭头表示导航选择

让我们进一步看看图的这两个用途：为分析而画的图和为一个可执行过程而画的图。首先，业务层面的人员不会考虑系统的边界。对于一个分析过程中的自动化模块而言，分析员通常不知道它如何执行或在哪个系统上执行。第二，当分析员为业务过程写文档时，其目的是为了向另一个人解释人和系统协作的方式。作为描述的一部分，图有助于给出一个快速的概览。过程描述可以假设读者对被解释过程的上下文已知。因此过程描述的详细程度可以变化。

这与可执行过程区别非常大，后者是业务过程管理系统（BPMS）的输入。可执行过程精确定义了这个 BPMS 应该如何运转。从这点来讲，它就是软件，与编程语言唯一不同之处就是所用的语言。所以可执行过程语言向系统解释了它该做什么。

当使业务过程自动化时，分析和可执行过程的联系来自于这一共同需求：一个计算机系统需要跟踪业务过程中所有活动的进展。为了达到这个目的，活动结束时需要告知管理这些信息的系统。系统或许可以自己执行某些活动，这些活动被称为自动活动。

即使在今天，许多 BPM 系统的市场营销都是这样：“让你的业务分析师画出业务过程的工作方式，然后这个图形描述将在 BPMS 上运行。”哪个经理愿意让一个不懂技术的业务分析师画的东西运行在生产线上？！BPM 系统的机会在于如下事实：业务过程分析图可以和可执行业务过程图看起来非常相似。图可以促进分析员和开发者的沟通，但始终是开发者负责可执行过程的所有技术细节。

当分析员画的图作为可执行过程的基础时，假如可执行过程语言不能灵活地将图和技术解耦，图就有可能不得不进行改变。例如，假设需要先收集一个人提供的输入信息，然后再将其作为输入传给 Java 代码去执行，业务分析师可能会对此建模成两个连续活动。但是，如果要用 BPEL 使这个过程可执行，可能必须加入一个赋值活动来将入参转换成 Java 代码需要的格式。这说明当分析过程作为可执行过程的基础时，通常需要进行转换。

另一方面我想指出的是：过程语言在复杂度和适用范围上可以有很大的不同。一些过程语言能力有限，只适用某一特定用途。一个文档管理系统中用于批准的语言就是一个好例子。这种语言可以非常简单而且不需要太多的技术细节。这种图在过程中占很大比重，非技术人员确实可以用这种方法构建一个完全可执行的过程。但对于象 BPEL 或 jPDL 这样的通用过程语言而言，情况就不一样了。这些语言有更大的适用范围，因此它们更加复杂而且需要更多的技术细节。此时，总是需要一个开发者来管理技术细节。

过程开发的过程

在知道了这些之后，我想勾勒出一个对于业务过程自动化更实际的分析和开发过程例子。首先，一个分析员创建了一个包括图的业务过程描述。然后需要将它翻译成可执行过程语言。这种翻译的影响将取决于这个分析员的技术技能和可执行过程语言的能力。任何情况下的目的都是使转换对图影响最小，这样业务分析师才能认识和理解可执行过程图。注意，图只是冰山的一角，因为对分析师毫无兴趣的可执行过程将包括大部分的技术细节。翻译之后，可执行过程就成为了一个软件，非技术出身的业务分析师只允许以只读方式查看它。

BPM 带来的巨大优势是分析员和开发者拥有一门公共语言。图方便了业务分析师和开发者的沟通。这的确实现了由 BPM 带来的‘敏捷’。但是幻想出现业务分析师在编辑图表之后点一下‘发布成产品’按钮就万事大吉的情景显然过于乐观且不现实。

建模细节

这节将论证这一观点：当需要在分析图和可执行过程间建立直接关系时，图中不要包括太多的细节。参与 BPMN 的人员背景是不同的。当人们仅仅只站在 BPM 的分析模型或可执行过程侧面看问题的时候，他们必然会象 Frank McCabe 在一次 OMG 会议中所发表的报告那样感到惊讶：

关于 BPMN 和 BPDM 的关系有些争论：BPMN‘仅仅’是一个符号，或者它确实有某种语义？所有的这些对 BPMN 团队来说都是新闻，因为他们（包括我）都愉悦地认为我们正在努力定义一种语言。对于我们来说，最大的问题好像是关于 BPMN 图的执行语义；对其他人来讲，它只是一个图形符号，完全不需要我们操心执行的事儿。你可能会猜到事情接下来会怎样。

这表明建模专家需要一种非常准确的符号以便在图上能放置大量的信息。作为一种帮助记录业务过程的分析语言，我认为 BPMN 是一个很好的选择。 David Chappell 提倡建模层次的移植性和实现（可执行过程）层次的移植性至少同样重要。

想一想我们一直以来想要达到的目标，过程逻辑的移植性——把实现从一个平台移到另一个平台的能力——无疑是其中之一。但是人的移植性——允许我们把技能从一种过程设计工具转移到另一种工具的能力——也很重要。BPEL 潜在地可以帮助完成第一个目标，但却不适合第二个；大部分创建过程的人从来不会直接使用这种复杂的基于 XML 的语言工作……正在崛起的图形化定义过程的标准就是业务过程建模符号（BPMN）。如果 BPMN 得到广泛的支持——这好像是可能的——它将使人的过程设计技能可以移植。

这让我得出这样的结论：假如要将过程建模绑定到可执行过程上，过程的图形化表示不应该包括太多的信息。当在你的组织中使用 BPMN 来进行过程建模的时候，最好引入一个更基本的子集，并且只使用它们。因为，试图在图形化的图表中表达太多的细节需要所有人都能理解它们。图形符号中的细节越细，它们与可执行语言匹配的机会就越小。BPMN 符号细粒度细节的复杂性不应该被低估，且应该只用在与可执行过程没有直接联系的大型业务分析师团队中。

因此，我认为过程语言（可执行的和非可执行的）的区别太明显，以致于不能把它们统一到一种基于 BPMN 的图形过程设计器中。我确实认为为每一个过程语言都可定义一个与之很好匹配的 BPMN 子集。设计工具应该直接支持特定于这种语言的结构和适当粒度的细节。我可以预见到这样的一种工具，其中设计者可以在不同过程语言间切换身份。但是在每一种情形中，使用者都很清楚用哪种语言建模和开发过程。同样，作为一个非执行的分析语言使用的普通 BPMN，是那些单独的语言之一。工具可以帮助处理转换，但每次都是一个有损，单向的转换。

映射和失配

BPMN 的映射方式会使双向工程出错。双向工程的思想是在 BPMN 分析模型和可执行过程之间可以不断地切换。业务分析师使用象 BPMN 这样的建模语言，使用图形符号和 BPMN 属性；开发者使用象 BPEL 这样的可执行语言。很明显，这种方式的问题在于在实际应用中很难维护两套属性。即使在两个视图中可以共享一些属性，但是业务分析师和开发者仍然会因为一个属性在 BPMN 和 BPEL 中含义不同而难以相互沟通。另外一个问题是工具厂商很难创建一个支持无损双向工程的工具。

既然 BPMN 和 BPEL 正在成为最受关注的 BPM 技术，让我们进一步看看两者的映射。第一个也是最显眼的问题是两种语言的结构不匹配。BPMN 是基于图形的，而 BPEL 是一个没有变迁的树形组合结构。第二，两者的并发模型差异巨大。Bruce Silver 对此有很好的总结：

如何使过程模型（如 BPMN）和对应的 BPMN 实现（如 BPEL) 保持同步，就是我们所说的双向工程问题……如果你一直在跟踪 BPMN Watch 上的这个话题，你就会记得 BPMN 让你画出的东西并不能很方便地映射到 BPEL——至少映射到一种你愿意编辑和维护的 BPEL，但 BPMN 的有些子集是可以自动映射的。假如是你控制 BPMN 工具，你可以通过禁止用户画那些不能映射的东西来解决这个问题。

其他 BPM 技术

XPDL

XPDL 是工作流管理联盟（ WfMC ）自 1993 年以来将 BPM 建模者统一到一个标准下的结果。这个标准关注于用来存储和交换过程模型的 XML 格式。XPDL 过程是基于图形的，这意味着它比 BPEL 树形结构更适合业务分析师。一个 XPDL 过程还可以在一个过程图中包含图形信息，如活动在过程图中的坐标。当过程建模者和模拟工具之间交换过程模型的时候，这个功能非常方便。XPDL 还有任务管理功能，包括泳道。这种过程语言不会象 BPEL 那样为不同活动定义明确的执行语义。

John Pyke 和 Keith Swenson 不断地强调 XPDL 并不是要与 BPEL 竞争。相反，他们认为 XPDL 是一种文件交换格式。假如这就是目标，那它们很可能会被即将到来的 BPDM 取代——如果后者曾见光的话。

与基于 WSDL 的 BPEL 不同，XPDL 是技术中立的。这意味着 XPDL 有一个单独的间接层来为所谓的‘应用’服务。XPDL 2.0 明确地为适应 BPMN 而设计。XPDL 本质上是基于图形的，所以它更适合 BPMN。在 XPDL 2.0 中，规范明确指出所有的 BPMN 属性都可以匹配到 XPDL。XPDL 绝对比 BPEL 更适合 BPMN。但 XPDL/BPMN 组合和 BPEL 的很大程度的区别在于后者有精确的执行语义。

BPDM

尽管 BPDM 不是新东西，但它依旧还处于内部讨论阶段，没有正式发布。通常，BPDM 应该包括表示业务过程的模型和一个文件格式。因为 BPMN 和 BPDM 都在 OMG，未来它可能取代 XPDL 成为一种交换文件格式。关于这个项目还没有多少正式的信息。Fred Cummins 如此描述 BPDM 的宏观目标：

规范提供了 BPMN 图形的底层模型表示。这意味着 BPMN 过程模型会有一个标准表示，以便在基于 XMI(模型交换 XML) 的建模工具间的交换模型。规范为编制过程（那些按规定执行的过程）和编排（描述多个独立过程间进行交换的规范，这种交换仿佛发生在一个 Web 服务交换中）提供了正式的表示。

Keith Swenson 保守地声称 BPDM 可能将取代最近 15 年在 XPDL 上的努力工作。 Sandy Kemsley 对 Fred 的介绍进行了汇报总结。

jPDL

jPDL 实际上不是一个标准，而是我们作为 JBoss jBPM 项目一部分创建的一种可执行语言。注意，jBPM 以前只支持 jPDL 语言，但 jBPM 现在是一个过程语言平台，jPDL 只是所支持的语言之一。这种语言的目的是成为一种可以清晰地把图和技术细节解偶的可执行语言。技术细节集中在 Java 平台。

正如我们以上所见，BPMN 适合分析员，但它是不可执行的。BPEL 是可以执行的，但不适合 BPM。因此，我认为 BPMN/BPEL 组合依旧是 BPM 蹩脚的解决方案，因为它们不能很好的匹配。

从另一个方面来讲，jPDL 是一门关注自由建模的可执行语言。首先，它是基于图的。第二，具有大量支持更好解耦过程图和技术细节的特性。例如，使用 jPDL，可以在图中加入隐藏的代码。它们被称为动作。这种风格的另一特性是可以引用节点运行时行为的客户化 Java 代码。这样，开发者就可以自由地开发出分析员在某个过程节点中想要的特殊行为。

另外，这种语言并不试图统一分析模型和可执行过程模型，但上述特性使它能够更容易地支持分析和执行小节所讲的软件开发过程。jPDL 已在Java 社区里得到了广泛采纳。

编排

ebXML & WS-CDL 是编排的标准化成果。 John Reynolds 这样描述编制和编排的区别：

**> 编制 == 可执行过程

Web 服务编制与执行特定的业务过程相关。WS-BPEL 是一种用来定义可以在一个编制引擎中执行的过程语言。

编排 == 多方合作

Web 服务编排与描述 Web 服务间外部可见的交互相关，WS-CDL 是一种描述多方契约的语言，有些类似 WSDL 扩展；WSDL 描述 Web 服务接口，WS-CDL 描述 Web 服务间的合作。** 编制是一种可执行过程，而编排是用来指定多方合作的协议。所以 BPEL 是一种编制语言。这意味着 BPEL 过程可以在一个系统上执行。因为一个编排过程定义了多方合作的方式，一个编排过程本身并不能被直接部署。相反，必须为一个参与者采用一个投影，而那个投影可以是一个执行过程。

在这个余下文章中，我将描绘可执行过程语言市场现状。编制语言没有坚实的构建基础。在我看来，这是这种语言仍处于边缘化最重要的原因。

过程组件模型

什么是过程组件模型

微软的工作流基础（WF）和 JBoss jBPM 是两种具有过程组件模型的技术。jBPM 的基础在过程虚拟机中有记录，它与微软工作流基础所采取的方式有很多相似之处。

它的思想是将过程图中的活动与一个实现该活动运行时行为的组件相关联，组件由一种通用编程语言实现。过程图中的每一个活动都对应一个实现组件。例如，一个Web 服务调用活动，一个人工任务活动或一个电子邮件活动都对应一个实现组件

这种方法的创新之处在于从BPM 和工作流技术中提取了一个公共基础层。WF 或过程虚拟机都不能被认为是BPM 技术。相反，它们提供的是公共基础层，可以把这个基础层扩展成为功能齐全的BPM 和工作流产品。或像 David Chappell 在这篇 MSDN 文章中明确表达的：

通过把工作流作为 Microsoft .NET Framework 3.0 的一部分实现，这种创建软件的方式对任何需要它的 Windows 应用都有裨益。包括运行在客户端和服务器端的应用，以及被最终用户、独立软件提供商和微软自己创建的应用。尽管需要些时间，Windows 工作流基础将会成为微软产品和应用的工作流基础。

一个活动组件可以定义一组配置属性。例如，一个电子邮件活动可以有接收者，主题和正文的配置。这样，同一个活动实现在每次被使用的时候可以进行不同的配置。

这种新方法的意义

首先，可以观察到的是在同一活动组件框架上可以实现多个过程语言。每一个过程语言由多个活动类型组成。对于每一个活动类型，运行时行为可以用诸如 Java 或 c#这样的通用编程语言实现。因此可执行过程语言就成为了一组活动类型的实现。这种活动组件最重要的部分是实现过程结构运行时行为的代码。但同时 XML 序列化，配置过程组件的设计窗体，持久化和许多其他部分都可能被包括在过程结构组件中。

因为它们可以支持多种过程语言，过程组件模型降低了单种语言的重要性。相反，它们使程序员可以为每一个过程选择最适合的可执行过程语言。与一个 BPM 引擎只支持一种过程语言相比，这种方式有效地分离了分析员和开发者间的关注点。

过程语言可扩展。假如你正在使用 BPEL、jPDL 或其他语言，你可以只实现你自己的活动并把它们加到语言中。也可以只暴露过程语言的子集，创建非常简单的领域特定过程语言，例如文档管理系统中用来指定批准的语言。

从这个角度看，我们可以定出 4 个层次的细节，它们非常适合平滑地将分析模型转换到可执行过程模型：

1. 过程图形结构
2. 活动类型选择（对应运行时实现）
3. 运行时实现的配置
4. B 方案：一个活动的客户化编码

因此可预见工具会将过程分析员和过程开发者之间的合作带到下一个层次。分析员可以使用设计工具来定义图的结构，但不用选择图中节点的活动类型。这将给建模者带来完全的自由。第二层的细节是选择活动类型。例如，指定过程中的某个步骤是人工任务，或是一个 Web 服务的调用。这就把图中节点和运行时行为关联了起来。第三层的细节是属性配置。分析员可能不知道 Web 服务端点的 URL。那可能是 Web 服务调用节点的一个配置属性。做为最后一层细节，特定的客户化运行时行为可以由开发者编码实现，作为从所用过程语言里选择一个活动类型的替代方案。这个模式更好地支持了开发可执行过程的分析活动，该过程在分析与执行小节中已经讲过。

过程组件模型和支撑它的编程语言间配合得非常好。例如，jPDL 非常适合Java 项目，因为它可以很方便地将Java 代码（如领域模型对象）包含进一个过程。同样的，Windows 工作流状态机可以容易地集成C#代码。

过程引擎的操作管理变得更容易。软件开发的很多方面可以用某种可执行过程语言建模。设想这样的一个项目，你用BPEL 来做服务编制，jPDL 来管理人工任务，pageflow 来定义一个WEB 应用的页面流转。在一个框架里能够同时运行这些语言是一个有利因素。

结论

BPEL 是一种可执行过程语言，它适合做集成，但因它与技术服务的紧密耦合而不适合业务过程管理。BPMN 适合分析员做分析图，但不能执行。XPDL 是一种较少采用的文件格式，可能会被 BPDM 替代。分析语言和执行语言的鸿沟仍然不可逾越。

为了创建一个更实际的能被普遍采用的 BPM 方法，我们需要从理清分析过程模型和可执行过程模型的区别开始。一旦我们放弃了让不懂技术的业务分析师画出马上可以执行的软件的念头，我们就可以找到一个更现实的业务过程管理方法。

当把一个分析过程模型和一个可执行过程实现联系起来的时候，这暗示了不要给图中的分析过程符号包括太多的复杂细节。只使用分析语言和执行过程语言所提供的交集，可以为业务分析师和开发者创建一门以单一图表为基础的通用语言。

不同的环境和不同的功能需求要求不同的可执行过程语言。目前想用一种过程语言覆盖所有的 BPM、工作流和编制的想法过于宏大。即使这一想法能够实现，最终的过程语言也会因太复杂而没有实用价值。

工作流技术有了新的发展。微软的工作流基础和 JBoss jBPM 的过程虚拟机为运行时过程环境抽取了一个共同基础。这些技术创造了一个组件模型，这样就可以在这个共同基础上构建活动类型。基础定义了活动组件执行的运行时环境。每一种过程语言由一组活动类型组成。活动类型的运行时行为可以用一种通用编程语言实现。一个活动成为了一个组件。任何过程语言基本上都定义了一组活动类型。接着，一个过程语言就可以在过程组件框架基础上被构建成一组活动组件。

作者简介

Tom Baeyens 是 JBoss jBPM 的缔造者和领导者。他也是 JSR 207 Process Definition for Java 和 JSR 208 Java Business Integration 的专家组成员之一。在名为过程开发的博客中，Tom 热情地分享了寻找BPM 目标和当今软件架构之间匹配方法的经验。在所有开发者的基本工具目录中都能有BPM、工作流和编制基础之前，他是不会休息的。

查看英文原文： Process Component Models: The Next Generation In Workflow?

译者简介：戴垚，2000 年计算机硕士毕业后一直从事软件开发管理工作，目前在一家大型外企担任开发部门经理。关心软件技术和相关工具的动态，深信技术的使用应以创造价值为根本。目前致力于 SOA 的研究，希望能对业已复杂的企业环境有所帮助。参与 InfoQ 中文站内容建设，请邮件至 china-editorial@infoq.com 。