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

工作流组件

介绍

托尼·贝尔说

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

这恰好总结了BPM行业中一个可能并不明显的大部门。术语BPM人士是指专注于流程建模的人员。他们的出发点是对描述人员和系统如何在组织中一起工作的过程进行分析。在建模者看来，最初的重点不是技术，而是非技术业务分析人员，这些人员记录了人员和系统如何协同工作。对于该类别中的许多BPM项目，甚至都没有考虑流程的自动化。最终的目标实际上是通过记录核心业务流程来更深入地了解组织的工作方式。来自此背景的纯BPM产品旨在简化此类业务流程描述的软件支持自动化。我将本营称为BPM建模者。

WS人员是指致力于创建可执行流程的人员。可执行流程是充当软件的人工制品，可作为业务流程管理系统（BPMS）的输入。可执行过程通常具有图形表示形式。当前，只有一种可执行流程语言被大厂商采用，那就是BPEL 。 BPEL基于WS- *标准，这就是为什么专注于自动化的人们被称为WS-folks的原因。最近，随着围绕BPEL的共识日益增多，服务编排得到了推动。我将这个阵营称为业务流程开发人员。

两种动作的共同点在于将重点放在图形图上并包含等待状态。对于BPM建模人员和业务流程开发人员而言，该图都是重要的工具。图具有提供特定过程的非常快速的概览的能力。虽然这是一种强大的工具，但请注意这种简单性。由于可能看起来相似的图可能具有不同的含义，具体取决于符号或底层可执行过程语言。图的目的也是非常重要的考虑因素。对于业务分析师，流程图的目的是帮助向其他人解释。它们有助于全面了解概述，并且允许一定程度的模糊性。对于可执行的过程语言，图是指定计算机系统必须如何行为的过程的一部分。因此，这些类型的过程是精确的，并且具有非常精确的解释。

包含等待状态本质上是更技术性的，但是在两个动作中也都可以找到。如果业务分析师绘制业务流程，则不同的活动可能与不同的资源相关。一些活动可能会转化为人类的任务，而其他活动可能会转化为在计算机系统上执行的软件。当这样的过程自动化时，过程引擎将驱动执行。这意味着引擎内部可能会自动执行一些活动。否则，如果活动在流程引擎的范围之外执行，则流程引擎将需要跟踪当前状态并等待，直到从外部实体接收到信号为止。例如，这种外部触发器可能是单击Web应用程序中的按钮以指示某个任务已完成的用户。同样，ERP系统可能会通知流程引擎特定发票的处理已完成。等待状态的概念可能看起来有点抽象，您可能想知道为什么在有关工作流或流程语言的讨论中，这种关系是有意义的。这是一个重要方面，因为像Java这样的传统编程语言不支持持久性等待状态。

本文认为，分析和业务流程的实施之间的差距远远大于当今工作流工具的市场营销所暗示的差距。它还将提出一种更加现实的方式来处理这种情况。将对当前的标准和计划进行足够深入的解释，以便您了解它们与运动的关系以及原因。在讨论中，我将确定每种讨论的技术的优缺点，并描述使用它们的正确方法和不正确方法。

最后，介绍了一种新型的工作流程技术，称为流程组件模型。这种类型的框架可以处理多种过程语言，并且可以支持更好地支持从分析过程图到可执行过程过渡的过程语言。

WS-BPEL

什么是BPEL

WS-BPEL是用于服务编排的OASIS标准。服务编排意味着根据其他服务编写新服务脚本。

简而言之，这是BPEL流程的剖析：部署BPEL流程将导致为该流程发布服务。 BPEL流程指定必须发布的服务，还指定那些服务操作的实现。

接下来，我们将解释最典型的BPEL活动，以在图1所示的上下文中很好地展示BPEL的本质。BPEL流程中的每个receive都对应于在部署流程时发布的服务操作。顶部的接收活动receiveOrder充当新流程执行的起点。因此，当客户调用左侧的订单操作时。这将导致通过退出初始接收活动来开始新的流程执行。

后续步骤是invoke 。调用将调用另一个WSDL服务，并将响应消息收集在一个过程变量中。在我们的例子中，对供应商的服务调用了getQuote服务操作。

来自传入消息的信息可以存储在过程变量中。可以存储整个消息，XML代码段或XSD基本类型。诸如extractProductName的assign活动可以从一个变量（通常是基于XML的内容）中获取片段，并将其存储在另一个变量中。然后可以使用变量来构成其他调用的消息或当前接收请求的响应消息。

receive活动receiveQuote将使流程执行等待，直到供应商调用SubmitQuote服务操作。在BPEL流程的部署过程中，还会发布带有SubmitQuote操作的服务。当供应商发送与此订单有关的报价时，流程将继续执行并离开receiveQuote活动。

reply活动为当前未完成的服务请求撰写响应消息。因此，仅当receive在具有IN-OUT消息交换的服务操作中收到消息之前，才有意义答复。

请注意，当供应商调用submitQuote操作时，传入消息必须通过退出receive活动来触发流程执行以继续。这显示了BPEL的另一个功能，称为关联。在BPEL流程中，关联意味着将传入服务请求消息与正在等待此类传入消息的现有流程执行进行匹配。如果将接收节点标记为正在启动，则有关此操作的传入消息将导致创建新的流程执行。通常，传入文档中的某些数据项将被标识为唯一的相关器ID，例如订单ID。然后，可以根据将在该传入消息文档中某处出现的订单ID，将过程中稍后的接收节点的传入消息与适当的进程执行相关联。实际上，相关集可以由具有许多属性的许多单个集合组成，但是为了清楚起见，我们还保留了额外的复杂性。

合作伙伴链接标识BPEL流程能够与之通信的外部各方。从BPEL流程到伙伴的服务调用以及伙伴对BPEL流程的调用都与伙伴链接相关联。这两个方向都称为角色。每个角色对应一个端口类型，该端口类型标识用于通过partnerlink在该方向进行通信的接口。因此，partnerlink可以声明两个角色，并且需要指示两个角色中的哪个代表BPEL流程端。与partnerlink的BPEL流程角色相对应的服务是在流程部署期间将发布的服务。另一个角色将在服务调用中使用。

总结了BPEL的最重要部分。其他部分（如补偿处理，事件处理，并发执行路径和计时器）是BPEL的高级功能，因此不包括在内，因为它们与进一步的讨论不太相关。

关于BPEL的想法和评论

让我们放大以上过程的控制流程。这三个服务调用的组合揭示了BPEL语言的主要动机之一，即轻松处理异步服务交互。客户方的客户端软件将发送请求消息，然后阻塞，直到收到该服务调用的响应消息为止。这称为IN-OUT消息交换模式。如果服务绑定使用基于HTTP的SOAP，则这意味着应该阻塞http请求，直到可以通过同一TPC / IP连接发送响应为止。另一方面，流程本身需要等待，直到供应商执行SubmitQuote回调。

在企业服务总线（ESB）环境中，所有这些都非常有意义。 ESB的想法是，许多组件可以以标准化的方式连接，然后通过总线与任何其他组件进行通信。标准化（通常基于WSDL / XML）消息在该总线上交换。然后，一组适配器充当协议之间的网关，例如一方面是HTTP上的SOAP，电子邮件，FTP，RMI，另一方面是消息总线。

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

企业应用程序也可以连接到服务总线。一旦总线上的所有内容都可以作为服务使用，那么BPEL就很有意义了，因为它也基于WSDL，就像与ESB的交互也基于WSDL一样。因此，ESB是BPEL引擎的理想栖息地。

ESB主要集中在基于XML的服务之间交换基于XML的消息。 BPEL从不离开XML文档级别。通常，XPath用于剪切和粘贴传入文档的片段并将其存储在过程变量中。调用的服务，公开的服务和过程变量均基于XML。执行逻辑直接在XML世界中表达。从某种意义上说，这是一个优势，无需在构造为XML的信息与编程语言中的对象之间进行转换。对于复杂的文档和对象结构，此类转换永远都不是透明或自动的，因此需要开发工作量和运行时性能。

BPEL先进的关联功能使无需进行任何修改即可轻松利用现有消息交换。无需在消息或上下文标头中传播进程执行ID。取而代之的是，BPEL引擎基于交换文档内容中的任何信息进行关联。在每个文档交换中标识实际数据项的方式以及它们与其他文档交换的匹配方式非常灵活。这很好，因为在许多集成方案中（例如，通信协议），您无法控制要交换的文档。

但是与业务流程管理（BPM）的关联来自何处？从BPM建模者的角度来看，这种关联是有问题的。我唯一能找到的真实链接是建立在良好的营销基础之上，而不是功能。对于BPM建模人员，BPEL严重缺乏几个基本功能。但是，当BPEL用于在ESB环境中编写新服务的脚本时，BPEL（即使没有扩展名）也非常完善，因为您无法控制与之交换文档的合作伙伴。因此，就像玛莎拉蒂和悍马一样，升值在很大程度上取决于用例。

我可以找到的唯一关联是BPEL流程可以显示为图表，并且该语言支持等待状态。这意味着可以将业务分析师创建的某些流程模型转换为BPEL流程。但是这种方法有两个主要限制。首先，业务分析师应该是非技术人员。因此，分析模型中的活动与可用的Web服务相对应的机会很小（读：不存在）。第二个问题是BPEL是块结构的。分析模型通常基于图。因此通常在转换为BPEL可执行流程时，不可能保持分析人员的分析图完好无损。这正是将BPMN映射到BPEL很难并且有很多限制的原因。

将BPEL用于BPM的最主要矛盾是，分析人员应该是非技术人员，而BPEL流程中的活动归结为Web服务调用。同样，出于建模目的，BPEL流程的块结构性质也受到限制。分析师需要自由绘制框和箭头，这总是导致图形结构和任意循环。 BPEL流程没有过渡的概念。相反，BPEL流程是一个复合结构，其中顶级活动是例如序列。该序列将包含活动的嵌套列表。其中一些将是基本（或原子）活动，而某些将是复杂的活动，再次包含嵌套的活动列表。通过良好的工具，这种自上而下的活动可以非常轻松地创建BPEL流程。但是将分析模型映射到BPEL流程是非常不同的，并且通常很难说。

将BPEL用于BPM的另一个问题是有限的数据处理能力。从服务编排中需要的大部分内容是从XML文档中提取内容。但是对于BPM，通常需要在流程的各个步骤之间进行大量数据处理。 XPath和其他基于XML的转换技术根本不够。

如果您是架构师，则考虑将BPEL用于BPM，您应该问自己的一个问题是，是否要在ESB中使用核心业务流程数据。 IT行业从存储过程转移到了诸如JEE之类的企业技术，以简化管理在数据位于“云”中的新应用程序的管理。 BPEL引擎需要维护的数据与客户，客户，供应商，产品等领域模型有关。该域数据通常存储在IT基础结构中的关系数据库中。您核心业务流程中的信息必须轻松链接到关系数据库中的域信息。如果您的Java应用程序需要知道文档的客户端引用怎么办？您是否想将该文档作为BPEL引擎的流程变量，然后从该XML文档中提取带有XPath的引用？提示是，此类信息应包含在数据库的域模型中。不在BPEL引擎内部。 BPEL不会阻止将这种信息存储在域模型数据库中，但是会增加难度。您可能必须实现特殊的Web服务才能将客户参考存储在域模型中。因此，BPEL似乎很容易对您的域模型信息进行分区。小心点。

David的“ 反对BPEL案 ”， Joe McKendrick在David Chappell博客上的故事以及Jeff Davis的“ BPEL怎么了” ，都指出BPEL不太适合BPM。

不要误会我的意思。这不是BPEL扑朔迷离。我对BPEL的看法是，这是一种将新服务编写为其他服务功能的好技术。但是，它并没有兑现BPM的承诺，目前众所周知。

BPEL扩展

BPEL4People指定如何在BPEL流程中包括人工任务。 BPEL4People使用BPEL扩展机制将人工任务作为活动添加到BPEL流程。该规范定义了BPEL引擎和任务组件之间的消息交换协议。 BPEL4People引入了人员链接的概念。任务分配是选择将要负责任务的人员或小组。 BPEL4People指定如何描述人员或组。但是，选择的运行时评估以及身份信息的结构均不在规范范围内。最近，BPEL4People背后的公司决定将规范提交给OASIS进行标准化。因此，可以预见，在不久的将来，大多数BPEL实现中都会发现BPEL4People。

BPEL4People通常被视为向BPEL添加工作流功能的修复程序，从而使BPEL更适合BPM。事实并非如此。当分析师为活动建模时，他们将归结为人工任务或处理系统。 BPEL仍然强制通过基于XML的流程变量来完成这些活动之间的通信。如果开发人员需要使用XSLT添加翻译，则这是一个新活动，即使业务分析师对该技术细节不感兴趣，该活动仍会在图中弹出。 BPEL流程图中的图形活动布局仍然与Web服务和XML技术紧密结合在一起，无法在使流程可执行的同时保持完整的分析图。

BPELJ是旧的白皮书，它是将Java绑定到BPEL流程的标准化建议。这涵盖了多个方面，例如将Java代码片段包含到BPEL流程中，将Java对象作为变量以及从BPEL流程中调用Java bean。 JCP中的Java的JSR 207流程定义是试图将其形成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执行，则可能必须在两者之间添加一个Assign，以将用户提供的数据转换为Java代码期望的正确格式。这表明，通常，在将分析过程用作可执行过程的基础时，需要进行转换。

在此我要强调的另一个方面是，过程语言在复杂性和范围上可以有很大的不同。某些过程语言是受限制的，并且用于特定目的。同样，文档管理系统中用于批准的语言就是一个很好的例子。这样的语言非常简单，不需要很多技术细节。图表是流程的重要组成部分，非技术人员实际上可以通过这种方式构建完整的可执行流程。但是对于通用流程语言（如BPEL或jPDL），情况有所不同。这些语言的范围更广，因此这些语言更加复杂，并允许更多技术细节。在这些情况下，始终需要开发人员来管理技术细节。

流程开发流程

考虑到这一点，我想为自动化业务流程绘制一个更现实的分析和开发流程版本。首先，分析师创建对业务流程的描述，包括图表。然后，需要将翻译转换为可执行过程语言。这种翻译的影响将取决于分析师的技术技能和可执行过程语言的功能。无论如何，目标是对图产生最小的影响，以便业务分析师识别并理解可执行过程的图。请注意，该图只是冰山一角，因为可执行过程中可能包含许多技术细节，而分析师对此并不感兴趣。翻译后，可执行过程是软件，因此，非技术业务分析师只能以只读模式查看它。

BPM带来的最大好处是为分析人员和开发人员提供了通用语言。该图有助于加快业务分析师与开发人员之间的沟通。确实，这创造了归功于BPM的“敏捷性”。但是，业务分析师只能编辑图表并按“发布到生产”按钮的幻想是乐观的，也是不现实的。

建模细节

本节是关于在分析图与可执行过程之间建立直接链接时未在图形图符号中使用过多细节的争论。不同背景的人参加了BPMN。当人们只看到BPM的分析模型或可执行过程时，他们一定会感到惊讶，例如OMG会议上的Frank McCabe报告：

关于BPMN和BPDM之间的关系有些困惑：BPMN是“仅”一种表示法还是具有某些语义。对于BPMN团队来说，这整件事都是新闻，因为他们（包括我）都在愚蠢地假设我们正在尝试定义一种语言。对我们来说，主要问题似乎围绕着BPMN图的执行语义。对于其他人，这只是一个图表符号，我们不必担心我们的小脑袋会执行。可能会猜到哪里去了！

这表明专家建模者想要一个非常精确的符号来在图中添加很多信息。作为一种有助于处理业务流程文档的分析语言，我认为BPMN是一个非常好的选择。 David Chappell主张，建模级别的可移植性至少与实现（可执行过程）级别的可移植性同等重要：

考虑一下我们要实现的目标。流程逻辑的可移植性（将实现从一个平台迁移到另一个平台的能力）无疑是其中之一。但是人员的可移植性也很重要，它使我们能够将技能从一种过程设计工具转移到另一种过程设计工具。 BPEL可以帮助实现第一个目标，但第二个目标并不适合。创建流程的大多数人永远都不会直接使用这种复杂的基于XML的语言工作。 ...以图形方式指定流程的新兴标准是业务流程建模表示法（BPMN）。如果BPMN得到广泛支持（似乎有可能），它将使人们的流程设计技能具有可移植性。

这使我得出以下结论：如果将流程建模绑定到可执行流程，则流程的图形表示不应包含太多信息。在组织中使用BPMN进行流程建模时，最好引入一些更基本的构造，而仅使用这些构造。试图在图形图中表达太多细节的原因要求每个人都理解它们。图形符号中使用的细节越精细，它们与可执行语言匹配的机会就越小。不应低估BPMN标记的详细信息的复杂性，而应仅将其保留给与可执行流程没有直接链接的大型业务分析团队使用。

因此，我认为流程语言（可执行和不可执行）差异太大，无法在基于BPMN的1个图形流程设计器中统一它们。我确实认为，对于每种流程语言，都可以定义与该语言很好匹配的BPMN子集。设计器工具应直接支持语言的特定结构和适当的详细信息。我设想使用一种工具，使一位设计师可以在不同的过程语言之间切换个性。但是在每种情况下，对于用户而言，将使用哪种语言来建模和开发流程将是显而易见的。同样，用作不可执行的分析语言的普通BPMN是这些单独的语言之一。在这些语言之间，该工具可以帮助提出转换，但是每次这都是一次有损的单向转换。

映射和不匹配

BPMN的映射方法导致往返错误。往返的想法是在BPMN分析模型和可执行过程之间的连续切换。业务分析师使用图形表示法和BPMN属性以建模语言（如BPMN）进行工作，而开发人员以可执行语言（如BPEL）进行工作。这种方法的问题在于，实际上，要维护两组属性太难了。即使某些属性在两个视图之间共享，这仍然使业务分析师和开发人员更难以进行通信，因为单个属性可能具有与其BPEL对应物不同的BPMN属性名。另一个问题是工具供应商很难进行无损往返。

由于BPMN和BPEL成为最受欢迎的BPM技术，因此让我们放大它们之间的映射。第一个也是最重要的问题是两种语言之间的结构不匹配。 BPMN基于图，其中BPEL具有复合结构，没有对应于树的过渡。其次，并发模型存在很大差异。布鲁斯·西尔弗（Bruce Silver）很好地总结了这一点：

如何保持流程模型（例如BPMN）及其BPMS实现（例如BPEL）同步，我们称之为往返问题...如果您一直在BPMS Watch上关注此线程，您会记得BPMN可以您绘制的内容很难映射到BPEL或至少要编辑和维护的BPEL类型，但是BPMN图的子集可以自动映射。如果您控制BPMN工具，则可以通过不让用户绘制无法轻松映射到BPEL的内容来解决问题。

其他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中匹配。与BPEL相比，XPDL绝对是与BPMN更好的匹配。但是XPDL / BPMN串联与BPEL之间的最大区别是精确的执行语义。

BPDM

尽管BPDM并非新手，但仍在内部进行讨论，而不需要正式发布。通常，BPDM应该包括用于表达业务流程的模型和文件格式。由于BPMN和BPDM都在OMG上，因此将来可能会替换XPDL作为交换文件格式。关于这一倡议尚未发表太多。弗雷德·康明斯（Fred Cummins）描述了BPDM的高级目标：

该规范为BPMN图形提供了基础模型表示。这意味着BPMN流程模型将具有基于XMI（用于模型交换的XML）的建模工具之间交换的标准表示。该规范为编排流程（按照规定执行的流程）和编排（如Web服务交换中的独立流程之间的交换的规范）提供了形式表示。

Keith Swenson采取防御措施，因为BPDM可能会取代过去十五年中XPDL的辛勤工作。 Sandy Kemsley报道了Fred的演讲。

jPDL

jPDL实际上不是一个标准，但是它是我们在JBoss jBPM项目中创建的一种可执行语言。请注意，以前，jBPM仅以jPDL语言为人所知，现在jBPM是过程语言的平台，而jPDL是受支持的语言之一。该语言的目标是成为一种可执行的语言，允许在图表和技术细节之间进行清晰的分离。技术细节集中在Java平台上。

正如我们在上面看到的，BPMN对于分析人员很有用，但是它不是可执行的。 BPEL是可执行的，但不适合支持BPM。因此，在我看来，串联BPMN / BPEL仍然是一种非常笨拙的BPM方法，因为它们的匹配度不高。

另一方面，jPDL是一种可执行的过程语言，重点放在建模自由上。首先，它是基于图的。其次，有许多功能可以使流程图和技术细节之间更加脱钩。例如，在jPDL中，可以包括隐藏在图中的Java代码。这称为动作。该类别的另一个功能是可以为节点的运行时行为引用自定义Java代码。这样，开发人员可以在流程的某个图形节点中自由编码业务分析师想要的特殊行为。

同样，这种语言不会尝试统一分析模型和可执行过程模型，但是上面讨论的功能使支持“ 分析与执行”一节中概述的软件开发过程变得更加容易。 jPDL在Java社区中得到了广泛采用。

编舞

ebXML和WS-CDL是编排标准化的努力。 John Reynolds这样描述编排和编排之间的区别：

编排==执行过程

Web服务编排与特定业务流程的执行有关。 WS-BPEL是用于定义可以在业务流程引擎上执行的流程的语言。

编舞==多方协作

Web服务编排涉及描述Web服务之间的外部可观察的交互。 WS-CDL是用于描述多方合同的语言，有点像WSDL的扩展：WSDL描述Web服务接口，WS-CDL描述Web服务之间的协作。

编排是一个可执行的过程，其中编排用于指定多方协作协议。因此BPEL是一种编排语言。这意味着可以在系统上执行BPEL流程。由于编排过程定义了多方如何共同协作，所以编排过程本身无法直接部署。相反，必须为其中一位参与者进行预测。然后，该投影可以是可执行过程。

鉴于本文其余部分所概述的可执行过程语言市场的情况。没有多少可用于编排语言的坚实基础。我认为这是这种语言仍处于边缘状态的最重要原因。

过程组件模型

什么是过程组件模型

具有流程组件模型的两种技术是Microsoft的Workflow Foundation（WF）和JBoss jBPM 。 jBPM的基础记录在Process Virtual Machine中，并且与MS工作流基础所采用的方法有很多相似之处。

想法是将流程图中的活动链接到以通用编程语言实现该活动的运行时行为的组件。流程语言中的每种活动类型都对应一个实现组件。例如，Web服务调用活动，人工任务活动或电子邮件活动均与实现组件相对应。

这种方法的新颖之处在于，从BPM和工作流技术中提取了一个通用的基础层。 Workflow Foundation或Process Virtual Machine都可以视为BPM技术。相反，它们都提供了一个通用的基础框架，可以扩展以形成完整的BPM和工作流产品。或正如David Chappell在此MSDN文章中提出的那样：

通过将工作流作为Microsoft .NET Framework 3.0的一部分来实现，这种创建软件的方法将可用于需要它的任何Windows应用程序。这包括在客户端或服务器上运行的应用程序，以及最终用户，独立软件供应商（ISV）和Microsoft本身创建的应用程序。尽管需要一些时间，但Windows Workflow Foundation将成为Microsoft产品和技术中工作流的通用基础。

活动组件可以定义一组配置属性。例如，电子邮件活动可以具有收件人表达，主题和正文的配置属性。这样，每次使用同一活动实现时，都可以对其进行不同的配置。

这种新方法的含义

第一个观察结果是，可以在同一活动组件框架的顶部实现多种过程语言。每种过程语言都由许多活动类型组成。对于这些活动类型中的每一个，都可以使用通用编程语言（例如Java或C＃）来实现运行时行为。因此，可执行的过程语言只是成为一组活动类型的实现。这种活动组件最重要的部分是实现流程构造的运行时行为的代码。而且XML序列化，用于配置流程构造的设计器表单，持久性和许多其他方面都可能包含在流程构造组件中。

因为它们可以支持多种流程语言，所以流程组件模型降低了各个流程语言的重要性。相反，他们让开发人员为每个过程选择最合适的可执行过程语言。在BPM引擎仅支持一种流程语言的情况下，这可以改善分析师与开发人员之间关注点的分离。

流程语言变得可扩展。如果您正在使用BPEL，jPDL或其他语言，则可以实施自己的活动并将其添加到该语言中。也可以只公开一部分流程语言，创建非常简单的特定于域的流程语言，例如在文档管理系统中指定批准。

从这个角度来看，我们可以确定4个详细级别，这非常适合从分析模型到可执行流程模型的平稳过渡：

Craft.io图结构
活动类型选择（对应于运行时实现）
运行时实现的配置
计划B：活动的自定义编码

因此，可以设想将流程分析师和流程开发人员之间的协作提升到新水平的工具。分析人员可以使用设计器工具来指定图结构，而无需选择图中节点的活动类型。这样就可以完全自由地建模。下一详细级别是选择活动类型。例如，指定流程中的某个步骤将是人工任务或Web服务调用。这会将运行时行为与图中的图形节点相关联。下一详细级别是配置属性。分析师可能不知道Web服务端点的URL。这可能是Web服务调用节点上的配置属性。作为最后的详细信息，开发人员可以对特殊的自定义运行时行为进行编码，以作为从使用的过程语言中选择活动类型的替代方法。这种方案可以更好地支持对可执行文件开发过程的分析，如分析与执行一节所述。

过程组件模型非常适合它们所基于的编程语言。例如，jPDL非常适合Java项目，因为很容易将Java代码包含到流程中以将例如域模型对象链接到流程中。同样，Windows工作流状态机允许轻松集成C＃代码。

流程引擎的运营管理变得更加容易。可以使用某种可执行的过程语言来建模软件开发的许多方面。假设在一个项目中，您使用BPEL进行服务编排，使用jPDL管理人员和页面流的任务，以指定Web应用程序页面之间的导航。那么在一个单一框架上运行所有这些语言的能力绝对是加分。

结论

BPEL是一种可执行的流程语言，适合于集成目的，但是由于它与技术服务调用紧密结合，因此不适合支持业务流程管理。 BPMN在工程图分析图中为分析师提供服务，但它不是可执行的。 XPDL是一种较少采用的文件格式，可能会被BPDM取代。分析语言和可执行语言之间的差距仍然太大，无法实际应用。

为了为更广泛地采用BPM创建更现实的方法，我们需要首先在分析流程模型和可执行流程模型之间进行更好的区分。一旦我们放弃了非技术业务分析师可以在图表中绘制可用于生产的软件的想法，我们就可以采用一种更加现实和实用的方法来进行业务流程管理。

当将分析过程模型与可执行过程实现链接时，提示中不要在图中包含太多分析过程符号的复杂细节。通过仅使用分析语言和可执行过程语言所提供的交集，可以基于一个图为业务分析师和开发人员创建一种通用语言。

不同的环境和不同的功能要求需要不同的可执行过程语言。当前的想法是，一种流程语言将能够涵盖所有形式的BPM，工作流和业务流程，这太雄心勃勃了。如果这样的努力能够成功，那么所产生的过程语言对于实际使用来说将太复杂了。

工作流技术有一种新方法。 Microsoft的工作流基础和JBoss jBPM的Process Virtual Machine提取了运行时流程环境的通用基础。这些技术创建了一个组件模型，因此可以在该通用基础之上构建活动类型。该基础定义了用于执行活动组件的运行时环境。每种处理语言都由一组活动类型组成。活动类型的运行时行为可以用通用编程语言实现。活动成为一个组成部分。任何流程语言基本上都定义了一组活动类型。然后可以在流程组件框架之上构建流程语言，作为一组活动组件实现。

翻译自: https://www.infoq.com/articles/process-component-models/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

工作流组件