谬误 5：业务过程执行必须是集中化的。

    让我们在这个谬误上花点时间。Bruce解释了他面临的一个新问题：

    事实上，如果[他的BPMN使用者]已经做出了他们BPM运行时的决策，那么它通常就是BPEL。它是一个标准、一个日用品，而且可以找到开源实现。它被IBM和 Oracle用在他们的BPM运行时中。因此，在选择BPEL时有强制性因素。但是BPMN和BPEL不是都在进行标准化吗？不，这当然不合逻辑。
    在“双向工程已死”营地（roundtripping-is-dead camp）待了大约一年之后，我现在发现自己不得不再次面临这个问题。在我的BPMN培训中，例如，学生想要知道在他们的BPMN图中使用什么策略或模式才能非常匹配他们期望的BPEL实现。这并不是我一开始期望去考虑的问题。

    BPMN/BPEL双向工程已经成为这个行业的圣杯。这最初本是由BPMI.org提出的愿景，该组织缔造了BPML和BPMN。这儿发生了什么？在一些公司给BPMN增加执行语义的时候连一个中介编制语言都没有，他们怎么可能为以人为中心的过程创建一个成功的市场？其他人认为这个问题来自于我们没有找到合适的协调语言这一事实。例如，Arzul Hasni认为在双向工程上GRAFCET会是比BPEL更好的候选。GRAFCET是工业自动机的专用编程语言（Arzul在他的帖子中给出了细节）。基本上，它非常接近BPEL。
    Ouyiang、Dumas、van der Aalst和ter Hofstede在创建BPMN/BPEL映射上做了卓越的工作。对于那些像我一样早就忘记了大学数学的人，我发布了BPMN和BPEL的UML图，它们可能对于你理解两个规范的语义（即，它们可以表达的事物）分歧有所帮助。来自这个研究组的结论非常的清楚：

    未来工作的一个可能方法是扩展提议的技术，覆盖BPMN模型更大的子集，如对相关的异常处理和其它高级结构（如OR-joins）建模。不幸的是，BPMN的许多高级结构并没有细化，依旧处于由相关标准化团体改进的过程中。
集中化过程引擎的概念并不新鲜。这是自90年代早期以来该领域已取得成果的99.99%的幕后基础。通过这个优秀的介绍可以很好的理解对集中化架构的关注，它由Fujitsu Computer Systems（该公司也在XPDL上投资，为BPMN创建一个可交换的格式）的研发副总裁Keith Swenson撰写。

    不幸的是，这种观点是有缺陷的，我非常愿意花些时间解释这一点。使用这种思考方式，我们完全忽略了业务过程本来的天性：通过转换资源给组织增加价值。像Source-to-make、Quote-to-cash……这样的过程都沿着工作流活动移动“东西”，这些活动最终（且有望）给转换中或消费中的资源增加价值。信息系统在此只是推进、捕获和报告这些资源和活动的状态。是的，你可以携带任何一个描述物理概念的业务对象：购买订单、发票、库存项、员工、客户……它们都有生命周期（可用状态图描述--参见图2）。
    我愿意举一个工作申请业务过程（即Candidate-to-Employee过程）的例子，它抽取一个候选者的申请，并将它处理到候选者要么被雇用要么申请被拒绝的位置。
    以下就是典型的工作申请信息模型。

图1 工作申请数据模型

    这个工作申请有一个生命周期（请记住工作申请的数据模型——内容——独立于它的生命周期，反之亦然）：

图2 工作申请生命周期

    工作申请生命周期本身独立于任何Candidate-to-Employee业务过程。这是一块很少变化的业务逻辑，即使与之交互的过程可能经常变化。一家公司可能有几个这样的过程为这个相同的生命周期服务：例如，一个用于副总裁职位，一个用于经理，一个用于其它所有的员工。另一种情况可能是因为规章制度，一些过程可能涉及额外的活动（检查背景……）。这些过程变体是非常平常的。但是，在很大程度上一个工作申请就是一个工作申请，即使也存在一些工作生命周期变体，它们在很大程度上与它们的过程变体没有瓜葛。
    现在的问题是，你将如何动手实现这个工作申请生命周期组件？我要使用的方法是创建一个实现所有动作的服务，这些动作将导致状态转换：

图3 工作申请服务

    所有这些服务操作将有效执行一些会导致状态转换的业务逻辑。什么是实现这个服务的最好的语言？Java/C#？BPEL？GRAFCET？
    我的偏好是如BPEL这样的一门面向消息的编制语言，因为这些资源生命周期是长期运行的（日、周、月、年）。为了说明这点，让我们举一个客户资源的例子：作为一个客户，我这周刚刚取消了一个与信用卡公司12年的关系，（这使得我的客户生命周期实例迁移到了它的最终态）因为必须支付额外的费用，我觉得违反了计费过程……是的，过程确实麻烦，他们可以完全无需改变我所喜欢的账单生命周期就能给他们的过程增加一个活动，但是他们没有，相反他们选择了最大化费用。对于这种长期运行的生命周期（不是过程），BPEL是一个理想的实现语言，因为它理解消息（接收、发送、调用）、关联消息，它可以处理并行流程（是的，一个资源可以有组合状态）。此外，BPEL引擎被设计来自动处理过程实例状态数据的持久化（dehydration/hydration），这个工作的麻烦相对少些。
    BPEL实现看起来就像这样（使用厂商中立的BPEL符号）：

图4 工作申请服务的实现

    我知道很多人会告诉我它是一个过程，但是它不是。它是一个实现了工作申请生命周期的服务，它独立于那些推进工作申请状态的过程和活动。一个过程是推进它的状态的活动的集合。资源生命周期和过程是解耦的，我认为这是无庸置疑的，然而每个人还是试图在没有清晰的理解资源生命周期的前提下建模和实现过程，它们或多或少“内建在”过程模型中。
    因此，大多数人将BPEL引擎作为标准选择是正确的……目前为止是这样。注意，由于SCA，你钟爱的编程语言可以很容易地被扩展结合BPEL语义。过去，我喜欢BPEL-J over BPEL，但是现在如果你需要在传统语言中表达一些业务逻辑，SCA使得在你钟爱的语言中使用编制能力这一工作真的变得非常简单（Java、C++、COBOL、PHP、ABAP……）。
    资源生命周期和编制语言之间存在如此强的关系，以致于一些领先的编制引擎提供了一个状态机范式作为创建你的编制定义的一种方法。IBM Process Server和微软Workflow Foundation就是例子（如果我还忘了哪些产品，我要在此说声抱歉。如果你知道的话，请告知我）。
    请注意，到目前为止我一直在建议使用一个编制引擎去实现那些管理资源生命周期的服务，我还没有说到业务过程或业务过程引擎。
    在了解生命周期和过程之间的关系之前，我们需要注意的是生命周期是一个非常直观的概念。大多数业务分析师随时可以轻易地描述这些生命周期（比方说使用UML符号）。可以这么说，不论他们是什么角色，组织中的任何人都可以理解这些生命周期。但是，我也要强调一下它的另一极端，几乎没有人有能力设计（使用BPMN进行图形化设计）满足涉及的所有资源生命周期的业务过程。假如你创建了这样一个模型，我们就说你现在创建了一个过程的变种。你如何能保证资源生命周期不受影响？你需要进行多少QA工作来验证它？
    过程和资源生命周期只能在过程实现时是一致的，而且可能要向过程“妥协”以确保它符合生命周期。这种活动只能由开发人员仔细地将业务分析师画出的BPMN进行映射，并重用那些管理他或她组织的核心资源生命周期的企业类服务来做到。
    现在，让我们看看业务分析师是怎样使用BPMN创建一个工作申请业务过程定义的：

图5 工作申请过程（蓝组代表人工任务边界）

    首先，BPMN连表示“资源”的符号都没有，更别提“生命周期”了。人们最多可以在过程的某一点（如上图）使用期望的状态对它的BPMN定义进行注解。这非常好，BPMN就应该是这样。其次，业务分析师完全不关心工作申请会调用哪些操作来推进它的状态。它们属于系统视角。期望业务分析师在他或她描述的用户活动间加入“调用”活动简直是痴人说梦。不幸的是，人们着手去建立的BPMN和BPEL之间的关系就是一个错误的例子。他们最终在过程符号中加入了核心BPEL操作语义，发送、接收和调用。这完全是画蛇添足，不应该被使用，除非被接收或发送的消息是一个业务消息而不是一个被调用的操作（如一份工作申请到了一个招募者的桌上）。
    怎样实现业务过程？一个业务过程执行环境是一个彼此（非集中编制的服务集合）交互的服务的装配（图6）。它描述了实现资源生命周期的编制，以及人工任务执行、事件和推进过程的简单服务调用的交互。

图6 工作申请过程实现

    好消息是我们完全拥有了实现这一愿景的必需技术，包括装配技术：服务组件架构。你在图中看到的一切可以结合SCA 1.0、BPEL 2.0、Web Services（XSD和WSDL 1.1——因为BPEL 2.0）、BPEL4People 1.0 and Human Tasks 1.0来完成。
    Bruce先前宣称：

    使用BPEL你没有忽略你不支持的元素的自由。BPEL就是BPEL，你必须支持规范中的一切。剩余的被称为私有扩展。它们只存在于它们自己的名字空间，BPEL 1.1的一个有根据的批评就是一个真正的过程需要太多的元素。BPEL 2.0要好一些，但是人工任务、子过程和其他的基本的东西仍需要2.0中的扩展，如，近乎神话的BPEL4People。

    在这个BPMS架构蓝图中，他的言论不再有效。WS-HumanTask和BPEL4People属于任务容器并且确实与BPEL本身隔离开。现在，你可以争论BPEL是否需要“子过程”，但是我会说作为一门资源生命周期服务的实现语言，它并不迫切：状态机元素极少可被重用，它们完全属于它们的资源。
    在这一点上——不幸的是——微软并没有参与SCA或BPEL4People，因此你不能将Workflow Foundation作为BPEL引擎的替代品，即使它能很好的完成工作。但是，你可以将WCF当作服务容器实现服务，你可以从SCA和你喜爱的BPEL引擎中调用这些服务。微软本身并没有装配机制，因此你甚至不能在.Net中实现这个架构蓝图。在开源方面，你可以找到大多数组件（SCA、BPEL和服务容器），但是BPEL4People容器除外。这并不要紧，基本的人工任务容器并不是太难构建（但是还没到BPEL4People和WS-HumanTask级别）。
   为了理解开发人员在这个新架构中的角色，让我们仔细看看过程模型的“面试安排（Schedule Interview）”活动（图5）。如你所见，这个活动在过程模型中被进行特别对待（这是有意义的，这是因为，如果工作申请系统宕机了，用户就不得不这么做），但是作为优化，它由业务来决定，例如，任务安排在Exchange Server上自动进行。工作申请应用生命周期提供了在候选人的申请被保留后安排面试的钩子（即，必需品）。记住工作申请服务并不知道这是如何实现的。它是人工任务也没有关系。在这一点上我认为，自动解决这种设计决策完全是不可能的。这就是过程模型必须完全和任何执行语义分离的原因。另一个不会影响过程定义的设计决策是这样一个事实：候选人申请能发生在一个不同的人工任务容器。我们能很好地将这个过程和发生在一个流行的求职站点的候选人申请“装配”在一起。一旦申请被批准面试，一个活动将给候选人发送一封邮件，告诉他或她下一步过程任务（复查录用通知，输入员工信息）。我打赌你现有的BPMS系统做不了（容易地）这件事。
    作为一个附注，你现在可以看到任务引擎并不是一个业务过程引擎真正的子组件。当然，当今的BPMS系统就是这么设计的，但是事实上它确实不是，它是架构的独立组件，管理人工任务（图6）。这些人工任务本质上总是关联一个或更多的业务过程，但是它们有它们自己的生命周期，而且直接和资源生命周期服务交互。正如Dominique Vauquier[1]在他文中所说的：“人工任务嫁接了资源生命周期”。此外，我们在前一段落看到，为了使“业务过程”能和几个任务容器进行交互，它至关重要。
    在此，我并不想描述规则或主数据管理的角色（对不住了，James），但是它们的确扮演了关键角色并且需要特殊的服务容器，这就是众所周知的BRMS（图6）。Michael zur Muehlen或Mark Proctor问的问题就变得完全不相关了，因为SCA使这变得不相关（从运行时的角度）。SCA会让你选择决策服务的非常好的调用机制（技术上可行的话，它可以和你的BPEL引擎一起运行在过程中）。SCA很大程度解耦了这个架构的元素，这使得它们可以在不同的过程中被重用，同时为每个过程选择可能的非常好的运行时配置。
    我也不会谈到B2B的角色，在我最初的两篇文章中，关于它们我说了很多。通过支持定义装配内的任意边界，这个架构蓝图支持B2B。例如，我能“装配购买订单生命周期的两个视角（买者和卖者）”。这是一个巨大的进步。传统的“集中化”执行模型在B2B边界强加了一个人工的断层，被迫使用两个不同的执行模型：在每一端的一个集中化编制，以及中间的一个装配。在某些方面，我的提议完全是基于OASIS ebXML Business Process最初的B2B过程定义，但是应用在了资源级别，而不仅仅是业务伙伴级别。这就是执行模型在组织内外都连续的原因，因为它和它的业务伙伴交互。