工作流组件
介绍
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 processes are graph based, which means that their more suitable for business analysts then the BPEL tree structure. An XPDL process also includes the graphical information such as the coordinates of the activities in a process diagram. This is handy when exchanging process models between the process modeller and eg a simulation tool. XPDL includes task management capabilities including swimlanes. The process language doesn't define exact execution semantics for the different activities like BPEL does.
John Pyke and Keith Swenson keep stressing that XPDL doesn't compete with BPEL. Instead, they point out that XPDL is the file exchange format. In that goal, they might be surpassed by the upcoming BPDM , if that ever sees the light of day.
In contrast to BPEL, which is based on WSDL, XPDL is technology neutral. This means that XPDL has a separate level of indirection introduced to address so-called 'applications'. XPDL 2.0 is explicitly designed to fit with BPMN. By nature, XPDL is graph based, so it fits with BPMN much better. And in XPDL 2.0, the specification makes sure that all the BPMN properties can be matched in XPDL. XPDL is definitely a better match with BPMN then BPEL. But the big differentiator between the XPDL/BPMN tandem and BPEL is the precise execution semantics.
BPDM
Although BPDM is not new, it is still being discussed internally without an official release. Mostly, BPDM should include a model for expressing business processes and a file format. Since both BPMN and BPDM are at OMG, it might become a replacement for XPDL as an exchange file format in the future. Not much has been published yet on this initiative. Fred Cummins describes the high level goals of BPDM :
The specification provides an underlying model representation for BPMN graphics. This means that BPMN process models will have a standard representation for exchange between modelling tools based on XMI (XML for Model Interchange). The specification provides formal representations for both orchestration processes (those that are performed as prescribed) and choreography (the specification of exchanges between independent processes as in a Web services exchange).
Keith Swenson goes defensive as BPDM might replace the hard work that has been put into XPDL for the last decade and a half. And Sandy Kemsley reports about a presentation of Fred.
jPDL
jPDL is in fact not a standard, but it is an executable language that we have created as part of the JBoss jBPM project. Note that previously, jBPM was known only for the jPDL language, where now jBPM is a platform for process languages and jPDL is one of the supported languages. The goals of this language are to be an executable language that allows for a clean decoupling between the diagram and the technical details. The technical details are focused on the Java platform.
As we saw above, BPMN is good for analysts, but it isn't executable. BPEL is executable, but it's not suited for supporting BPM. So the tandem BPMN/BPEL is in my opinion still a very clumsy approach to BPM cause they don't match very well.
jPDL on the other hand is an executable process language that puts the focus on modelling freedom. First of all, it's graph based. Second, there are a number of features that enable more decoupling between the process diagram and the technical details. For instance, in jPDL, it's possible to include pieces of Java code hidden from the diagram. This is called actions. Another feature in that category is the possibility of referring to custom Java code for the runtime behaviour of nodes. That way, the developer can freely code the special behaviour that the business analyst wants in a certain graphical node of the process.
Also this language doesn't try to unify the analysis model and the executable process model, but the features discussed above make it much easier to support the software development process outlined in section Analysis versus execution . jPDL has got significant adoption in the Java community.
Choreography
ebXML & WS-CDL are choreography standardization efforts. John Reynolds describes the difference between orchestration and choreography like this:
Orchestration == Executeable Process
Web Service Orchestration relates to the execution of specific business processes. WS-BPEL is a language for defining processes that can be executed on an orchestration engine.
Choreography == Multi-party Collaboration
Web Service Choreography relates to describing externally observable interactions between web services. WS-CDL is a language for describing multi-party contracts and is somewhat like an extension of WSDL: WSDL describes web services interfaces, WS-CDL describes collaborations between web services.
Orchestration is an executable process, where choreography is used to specify multi-party collaboration protocols. So BPEL is an orchestration language. It means that a BPEL process can be executed on a system. Since a choreography process defines how multiple parties collaborate together, a choreography process itself cannot be deployed directly. Instead, a projection has to be taken for one of the participants. Then that projection can be an executable process.
Given the situation in the executable process language market as sketched in the rest of this article. There are not many solid foundations for orchestration languages to build upon. That is in my opinion the most important reason why this type of languages is still marginal.
Process component models
What are process component models
The two technologies that have a process component model are Microsoft's Workflow Foundation (WF) and JBoss jBPM . The foundations of jBPM are documented in The Process Virtual Machine and there are many similarities with the approach taken by MS's workflow foundation.
The idea is that activities in a process graph are linked to a component that implements the runtime behaviour of that activity in a general purpose programming language. Each activity type in a process language corresponds to one implementation component. For example a web service invocation activity, a human task activity or an email activity all correspond to an implementation component.
The novelty of this approach is that a common base layer is extracted from the BPM and workflow technologies. Workflow Foundation nor the Process Virtual Machine can be considered as BPM technologies. Instead, they both provide a common base framework that can be extended to form fully fledged BPM and workflow products. Or as David Chappell formulates it in this MSDN article:
By implementing workflow as a part of Microsoft .NET Framework 3.0, this approach to creating software will be available for any Windows application that needs it. This includes applications running on clients or on servers, as well as applications created by end users, by independent software vendors (ISVs), and by Microsoft itself. Although it will take some time, Windows Workflow Foundation will become the common foundation for workflow in Microsoft products and technologies.
An activity component can define a set of configuration properties. For example, an email activity can have configuration properties for recipient expression, subject and body. This way, the same activity implementation can be configured differently each time it is used.
Implications of this new approach
A first observation is that multiple process languages can be implemented on top of the same activity component framework. Each process language is composed of a number of activity types. For each of those activity types, the runtime behaviour can be implemented in a general programming language like eg Java or C#. So an executable process language just becomes a set of activity type implementations. The most important part of such an activity component is the code that implements the runtime behaviour of the process constructs. But also the XML serialization, the designer forms to configure the process construct, persistence and many other aspects can potentially be included in a process construct component.
Because they can support multiple process languages, process component models reduce the importance of the individual process languages. Instead, they let developers select the most appropriate executable process language for each process. This improves the separation of concerns between analysts and developers over a situation where a BPM engine only supports one process language.
Process languages become extensible. If you're using BPEL, jPDL or another language, you can just implement your own activities and add them to that language. It's also possible to only expose a subset of the process language, creating very simple domain specific process languages, for example to specify approvals in a document management system.
In this perspective, we can identify 4 levels of detail, which perfectly fits with a smooth transition from analysis model to executable process model:
- Process graph structure
- Activity type selection (corresponds to the runtime implementation)
- Configuration of the runtime implementation
- Plan B: Custom coding of an activity
So tooling could be envisioned that takes the collaboration between process analysts and process developers to the next level. An analyst could use a designer tool to specify the graph structure without selecting the activity type of the nodes in the diagram. That would allow to model in complete freedom. The next level of detail is selecting the activity type. For instance specifying that a certain step in the process will be a human task or a web service invocation. This associates the runtime behaviour with the graphical node in the diagram. The next level of detail is the configuration properties. Analysts will probably not know the URL of a web service endpoint. That might be a configuration property on a web service invocation node. And as the last level of detail, special custom runtime behaviour could be coded by a developer as an alternative to selecting an activity type from the used process language. This scheme supports much better the analysis to executable development process as outlined in section Analysis versus execution .
Process component models fit very well with the programming language they're based on. jPDL for example fits very well in a Java project cause it is very easy to include Java code into a process to link eg your domain model objects into the process. Similarly, windows workflow state machines allow easy integration of C# code.
Operational management of process engines becomes easier. Many aspects of software development can be modelled in some kind of executable process language. Suppose that in one project you use BPEL for service orchestration, jPDL for managing the tasks for people and pageflow to specify the navigation between pages of a web application. Then the ability to run all of these languages on one single framework is definitely a plus.
结论
BPEL is an executable process language, which is good for integration purposes, but it's not suited for supporting Business Process Management cause of its tight coupling with technical service invocations. BPMN serves the analysts in drawing analysis diagrams, but it's not executable. XPDL is a less adopted file format, which might be superseded by BPDM. The gap between analysis languages and executable languages still remains too big to be practical.
In order to create a more realistic approach to BPM for widespread adoption, we need to start by making a better distinction between analysis process models and executable process models. Once we abandon the idea that non-technical business analysts can draw production-ready software in diagrams, we can come to a much more realistic and practical approach to business process management.
When linking an analysis process model with an executable process implementation, the clue is not to include too many of the sophisticated details of the analysis process notation in the diagram. By using only the intersection of what the analysis language and the executable process language offers, a common language can be created for the business analyst and the developers, based on one single diagram.
Different environments and different functional requirements require different executable process languages. The current idea that one process language would be able to cover all forms of BPM, workflow and orchestration is just too ambitious. And if such an effort would succeed, the resulting process language would be way too complex for practical usage.
There is a new approach to workflow technology. Microsoft's workflow foundation and JBoss jBPM's Process Virtual Machine extract the common foundations for runtime process environments. These technologies create a component model so that activity types can be build on top of that common foundation. The foundation defines a runtime environment for the execution of activity components. Each process language is composed of a set of activity types. The runtime behaviour of the activity types can be implemented in a general purpose programming language. An activity becomes a component. Any process languages basically defines a set of activity types. A process language can then be build on top of the process component framework as a set of activity component implementations.
关于作者
Tom Baeyens is founder and lead of JBoss jBPM . He has participated in the expert groups of JSR 207 Process Definition for Java and JSR 208 Java Business Integration. In the blog called Process Developments , Tom shares his passion to find a match between the BPM goals and today's software architectures. He will not rest until all developers have the BPM, workflow and orchestration basics in their repertoire.
工作流组件