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

作者 Tom Baeyens译者 戴垚 发布于 2008年4月1日 上午1时13分

社区

Architecture,

SOA,

Java

主题

业务流程管理,

工作流/业务流程管理,

业务流程建模

标签

BPEL,

WS-BPEL

介绍

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。

1. 返回顶部

   好文章

   2008年4月1日 下午8时48分 发表人 weihong hu

   不错，收藏下来慢慢读，有些长！：）

   回复

2. 返回顶部

   没看懂Tom的意思

   2008年4月1日 下午10时4分 发表人 hying liu

   将英文原文大体过了一遍，只看到他在提 process component model。但是这个东西不正是弥补analysis process models and executable process models gap 的好东西吗，为何说要放弃“让不懂技术的业务分析员通过画图来产生马上可用的软件的念头”呢？

   回复

3. 返回顶部

   阅读全文链接的有错误

   2008年4月2日 上午12时3分 发表人 shuai che

   链接的地址都是英文的

   回复

4. 返回顶部

   Re: 阅读全文链接的有错误

   2008年4月2日 上午12时26分 发表人 James Zhang

   INFOQ是不是还没有翻译完成？

   回复

5. 返回顶部

   Re: 阅读全文链接的有错误

   2008年4月2日 上午12时45分 发表人 凉粉 小刀

   sorry，我们编辑发布时候的问题，已经修复

   回复

6. 返回顶部

   Re: 没看懂Tom的意思

   2008年4月2日 上午1时27分 发表人 gem fox

   运行时的东西过于技术化，当然应该由技术人员来负责。因为关注点的不同，直接叫BA来把所有事情搞定显然不切合实际。即使有了PCM，也只是改善了翻译和沟通的情况。就这篇文章看来，最终一种可能的形式是BA充当了类似开发中的设计者的角色；而技术人员则负责将其实现，类似开发中的开发者。

   回复

7. 返回顶部

   为什么持久化等待应该由java等编程语言完成？

   2008年4月3日 下午1时14分 发表人 Joseph Tseng

   文中提到：“一个重要原因就是象Java这样的传统编程语言不支持可持久化的等待状态。” 我也曾从JBoss的架构师口中听到这段描述，我感觉很奇怪，为什么java语言需要支持持久化等待？ 目前最流行的持久化，不就是DB或者文件么？这个职责应该是应用程序本身提供，或者一个通用的框架提供，没听说过哪个语言需要负责持久化的。大家有过这样的需求或期望吗？有人能解释一下这句话吗？

   回复

8. 返回顶部

   Re: 为什么持久化等待应该由java等编程语言完成？

   2008年4月5日 上午6时0分 发表人 gem fox

   这里的重点是“等待状态的持久化”，而非单纯的“持久化”。对于过程，至少有两个概念需要区分：过程定义和过程实例。过程定义即相当于类定义，是静态概念；过程实例即相当于类实例，是动态概念。一般的过程实例都会跨长时间段，比如几天或几周，这样等待状态的持久化问题就显得重要了。但是Java不会自动的将这些处于等待的过程实例的当前状态保存起来，需要流程引擎来完成。打个比方，你每次断电后开机，都得重新打开工具进行工作。但如果，OS支持持久化的话，应该会将断电关机瞬间的内存状况全部记下。下次开机时就重那一点开始。就像你休眠机器一样。（不知是否讲清楚，呵呵）

   回复

9. 返回顶部

   没太明白意思

   2008年4月8日 下午10时16分 发表人 grid qian

   前面的铺垫都看明白了，就是到了最关键的地方没太明白。TOM是说JBPM在业务建模和业务流程之间建立了个基础层，这个层完成了流程组件的定义工作。然后具体的过程语言再去实现它？我的理解对吗？如果对的话，JBPM是如何实现这点的呢？我简单用了一下JBOSS的TOOLS，好像他们也就是在每个流程单元中加了一些ACTION来完成时间的动作。没觉得多了什么？

   回复

10. 返回顶部

    Re: 没太明白意思

    2008年4月11日 上午1时16分 发表人 gem fox

    关于这一点，你可以去看看JBPM的参考手册了解详情。

    回复

• 更早的 >