这两者共同点在于关注图形化流程和等待状态的内置支持。图形对于BPM建模者和编排开发者来说都是重要的工具。图形可以提供某个流程的快速概述。其作为一 个强大的工具手段的同时也要注意到其简易性。可能看上去相似的图会有完全不同的意义，这取决于语言标记或底层的可执行流程语言。还有就是流程图的作用非常 值得考虑。在业务分析的情况下，流程图的目的就是要为其他人提供解释。它们提供概述，并允许某种程度的模糊性。而在可执行流程语言的情况下，图则是详细描 述一个计算机系统行为的流程的一部分。所以，这些流程必须是准确且有精确的解析。 等待状态的内置支持自然更技术化些，但在两者种都可以找到。如果一个业务分析者画了一个业务流程图，不同的活动可能与不同的资源相关联。某些活动对于人员 可能会转换为任务，而其它活动可能会转换为计算机系统上执行的软件片段。当自动化一个流程时，流程引擎驱动其执行。这意味着引擎内部可能自动地执行某些活 动。另一方面，当流程引擎外执行活动时，流程引擎需要跟踪当前状态信息，并等待，直到接收到外部实体发来的信号为止。比如，一个外部触发器也许就是web 应用下用户点击了一个按钮，从而预示某个任务的完成。类似的，一个ERP系统可能会通知流程引擎某个发票单的处理已经完成。等待状态的概念也许有点抽象， 且你也许想知道为什么这于工作流或流程语言会有关系。因为传统编程语言象java语言并不知道持久的等待状态，这是一个非常重要的方面。 本文认为业务流程的分析与实现的鸿沟比现今工作流工具的市场所提供的更大。另外其提供了一个更现实的处理此种状况的方式。本人将会用足够的深度解释当前的 标准和动机，以便你可以了解它们是如何联系在一起，且为什么。在此讨论中，我将标识出每个被讨论技术的优势与弱势，并描述使用它们的正确的方式和不正确的 方式。 在本文的最后，会引入一种新的技术，被称为流程组件模式。这种框架能处理多种流程语言且能为更好地支持从分析流程图转换到可执行流程的流程语言提供支持。
