要想完全总结出BPM业界大的分支不是那么容易的。术语BPM-folk涉及关注流程建模的人员。他们的起点是流程的分析，当然这里的流程描述了一 个组织中人员与系统是如何协同工作的。以建模者的视角来看，起初的焦点并不在技术，而在于非技术的业务分析，这些业务分析描述了人员和系统是如何协同工作 的。对于这类的许多BPM项目，甚至不考虑流程的自动化。其最终目标实际上是要通过文档化核心业务流程来创建更多洞察组织工作模式的点。源自此背景的纯 BPM产品则致力于使得业务流程描述的软件支持自动化更简便。我将这些人员称为BPM建模者。

　　WS-folk涉及关注于创建可执行流程的人员。可执行流程是软件工件，可看作为业务流程管理系统(BPMS)的输入。可执行流程一般都有图形化描述。同 时，只存在一个被大厂商广泛采用的可执行流程语言，那就是BPEL。BPEL基于WS-*标准，这就是为什么关注于自动化的人员是位于WS-folk之上 的原因。当前，服务编排随着围绕BPEL越来越多的舆论也有所推进。我将这些人员称为编排开发者。

　　这两者共同点在于关注图形化流程和等待状态的内置支持。图形对于BPM建模者和编排开发者来说都是重要的工具。图形可以提供某个流程的快速概述。其作为一 个强大的工具手段的同时也要注意到其简易性。可能看上去相似的图会有完全不同的意义，这取决于语言标记或底层的可执行流程语言。还有就是流程图的作用非常 值得考虑。在业务分析的情况下，流程图的目的就是要为其他人提供解释。它们提供概述，并允许某种程度的模糊性。而在可执行流程语言的情况下，图则是详细描 述一个计算机系统行为的流程的一部分。所以，这些流程必须是准确且有精确的解析。

　　等待状态的内置支持自然更技术化些，但在两者种都可以找到。如果一个业务分析者画了一个业务流程图，不同的活动可能与不同的资源相关联。某些活动对于人员 可能会转换为任务，而其它活动可能会转换为计算机系统上执行的软件片段。当自动化一个流程时，流程引擎驱动其执行。这意味着引擎内部可能自动地执行某些活 动。另一方面，当流程引擎外执行活动时，流程引擎需要跟踪当前状态信息，并等待，直到接收到外部实体发来的信号为止。比如，一个外部触发器也许就是web 应用下用户点击了一个按钮，从而预示某个任务的完成。类似的，一个ERP系统可能会通知流程引擎某个发票单的处理已经完成。等待状态的概念也许有点抽象， 且你也许想知道为什么这于工作流或流程语言会有关系。因为传统编程语言象java语言并不知道持久的等待状态，这是一个非常重要的方面。

　　本文认为业务流程的分析与实现的鸿沟比现今工作流工具的市场所提供的更大。另外其提供了一个更现实的处理此种状况的方式。本人将会用足够的深度解释当前的标准和动机，以便你可以了解它们是如何联系在一起，且为什么。在此讨论中，我将标识出每个被讨论技术的优势与弱势，并描述使用它们的正确的方式和不正确的 方式。

　　在本文的最后，会引入一种新的技术，被称为流程组件模式。这种框架能处理多种流程语言且能为更好地支持从分析流程图转换到可执行流程的流程语言提供支持。

　　翻译自Tom Baeyens的《Process Component Models: The Next Generation In Workflow ?》