本文是本系列的第一篇文章，将探讨如何将业务流程分解为不同的职责层（与不同的细节级别相对），并将讨论流程控制者的角色以及如何在需要的地方标识服务。在本系列中，您将了解一项新的分解技术，以帮助您指定与面向服务的体系结构（Service-Oriented Architecture，SOA）一致的业务流程。

引言

流程建模对基于 SOA 的 IT 项目越来越重要。您可以使用流程建模标识服务、结构需求，并定义在业务流程管理（Business Process Management，BPM）平台上执行的业务流程。

业务和 IT 涉众都能理解的流程建模是实现 SOA 和 BPM 的共同优势的必要工具：即在业务和 IT 之间实现更好的一致，并达到更好的重用。

在本系列中，您将了解 SOA 解决方案的流程驱动的建模。本文将介绍一项流程分解技术，可用于指定与基于 SOA 的目标体系结构紧密一致的流程模型，从而让您的流程模型表现出与所实现的解决方案更好的对应性。

我们为什么需要与 SOA 一致的流程模型

提供建模的好处仍然很困难，因为大部分流程建模技术都基于先于 SOA 和 BPM 的概念。通常，企业中会创建不同的流程模型来满足不同的目的。例如，流程建模可用于战略定义、组织变更、需求收集、操作优化、功能规范、用户界面流、工作指令和企业应用程序集成（Enterprise Application Integration，EAI）流等。即便使用了两个模型代表相同的流程，如果是为满足不同的目的而创建的，则二者可能会有所差异。

流程建模存在维护、可跟踪性和测试问题：

• 如果流程模型在 IT 项目的生命周期中发展，则这个模型通常源自最初创建的模糊模型，最初的目的与在周期中后来的用途并不一样。
• 为了避免前述问题，有时候会在生命周期的每个阶段创建一个全新的模型，从而带来对显式跟踪性构件的需求，而这些构件的维护费用相当高。
• SOA 项目的上游（建模）阶段的执行人员并不了解其工作下游的影响。

因此，在早期阶段开发的流程模型与所实现的实际解决方案之间的关系并不明确。或者，模型推动着解决方案向错误的方向发展。

可以使用其他不太精确的流程模型作为输入，创建与 SOA 一致的流程模型。采用指定解决方案的直接方法有很多优势：

方便移交

从业务分析人员到架构师以及从架构师到设计人员、开发人员和测试团队的流程模型移交得到改进

减少重构

减少从生命周期阶段过渡到另一个阶段的过程中模型的重构

增强可跟踪性

改善基于 BPM 和 SOA 的项目的轨迹记录

满足客户预期

通过将解决方案可视化，从而提高沟通清晰度，改善所要求的目标和将提供的结果之间的一致性，从而提高达到客户预期的比率

提高项目交付的速度

使用指导原则和模式可简化设计，提高设计准确性

定义通用语言和框架

帮助在执行人员之间交换流程模型

更为高效地进行测试和验证

在需求和所交付的结果之间联系更紧密，可帮助高效地进行测试和验证

提高重用潜力

重用服务在其他生命周期阶段中拥有明确可标识的构件的可能性越大

IBM SOA 参考体系结构

流程建模技术可通过 IBM® SOA 参考体系结构予以演示，这个参考体系结构是很多 IBM 客户的 SOA 活动的蓝图。（参考资料中提供了关于 IBM SOA 参考体系结构的更多信息。）本文重点讨论体系结构中与流程建模人员最相关的三个层：使用者层、业务流程层和服务层。

使用者层

使用者层包含组织内最终用户使用的应用程序，或外部组织（如客户或合作伙伴）的入站接口。使用者应用程序负责维护与用户的对话或会话。使用者层有时候称为表示层。

业务流程层

业务流程层中的流程由使用者层的应用程序调用（使用服务）。他们实现具体的业务目标，由多个活动组成，而这些活动可能会调用服务层提供的服务。业务流程层中的流程经常作为在 BPM 平台上执行的编排的流程实现。对于本文中的技术，有必要对长时间运行 和短时间运行 的流程加以区分：

• 长时间运行的流程也称为工作流流程，至少有一个步骤涉及以下情况：执行活动的个人，等待外部事件发生或所需时间长得惊人的处理。使用者应用程序不能从长时间运行的流程立即获得结果。
• 短时间运行的流程由完全自动化、即时完成（几乎）的服务组成。使用者应用程序在调用短时间运行的流程时几乎能够即时得到结果。

还有其他一些很好的体系结构原因可对此进行区分。

服务层

服务层以服务的形式向业务流程层和使用者层提供构建块。这些服务是自动化的，可能在业务流程中作为活动表示。图 1 突出显示了与本文相关的 SOA 参考体系结构层。

本文稍后介绍的技术需要按照这些层对流程模型进行分层。不过，在涉及更为详细的细节前，下一部分将讨论长时间运行（工作流）的流程中的人工活动。

长时间运行的流程中的人工活动

长时间运行的流程中的步骤可以与人工活动（手动工作流项目）对应。通常，此类活动由在流程中担当特定角色的企业员工执行。BPM 平台可能会提供将此活动发送到任务列表的方法，并向用户提供用户界面 (UI)，以从列表中选择任务。任务列表本身并不是流程模型中的功能，被抽象出去了。

当您决定如何在流程模型中表示人工任务时，有三种可能的选择：

• 选项 1：从流程建模的角度而言，业务流程中的人工活动是与服务层中的自动化活动类似的步骤。因此，应该据此对其建模，并在逻辑上将其视为与自动化活动处于相同的层中。
• 选项 2：从技术的角度而言，人工活动需要的用户界面应与其他消费应用程序 (consuming application) 一样受到相同的访问控制机制和其他功能的限制。人工活动也可以使用基础层提供的服务。其实现应该属于使用者层。
• 选项 3：人工活动属于业务流程层本身，因为它们由 BPM 解决方案提供和进行中介。

这些选项看起来彼此不相容，其中前两个以不同的方式打破了分层规则（请参见侧栏的内容）：

• 人工活动可能需要调用短时间运行的业务流程，如果将人工活动视为服务层的一部分，则业务流程位于较高的层中。
• 业务流程建模人员会认为人工流程活动是由业务流程调用。（调用 是从业务角度而不是技术角度而言，因为调用机制实际上是将任务分配到用户的任务队列。）如果人工流程活动是使用者层的一部分，从流程建模人员的角度而言，这实际上意味着业务流程层调用位于其上的层。

此解决方案是第三个选项的细化，其中人工活动放在业务流程层中，置于长时间运行的流程和短时间运行的流程之间。通过这样，您还能够确保人工活动不会调用长时间运行的流程层。

与 SOA 一致的流程分解

对于具有 BPM 组件的 SOA 项目，您必需遵循图 2 中所示的流程分解结构。（此框架能促进本系列第 2 部分中模式的合理性。）

所开发用于指定基于 SOA 的解决方案的功能的流程模型应该遵循图 2 中所示的分解结构。每个流程都属于其中一个层。

流程只能调用或订阅到下游层的流程中的事件，如箭头所示。它们还应该对上游层中的流程不可知。下面将对每个层进行讨论。

手动流程和客户体验流程

手动流程和客户体验流程层为较低的层的流程设置上下文。这个层中的流程在 SOA 参考体系结构中没有关联层，不过，它们能帮助解释什么导致使用者流程启动。

使用者流程

特定于使用者的流程模型指定最终用户应用程序的流程。它们表明应用程序如何与基础流程进行交互。使用者层应用程序维护与用户对话所需的会话。用户可以为外部用户（客户）、内部用户（员工）或系统用户（安排的批处理作业或 B2B 接口）。使用者层的主要目的是，收集所需的所有信息，以便能启动业务流程或事务。

任何在使用者流程内定义的逻辑都必须特定于应用程序（或通道）。因此，应该保持与业务流程层明确的区别。

特定于使用者的流程使用“即发即弃”(Fire and Forget)（或请求-确认）方式调用长时间运行的流程。它们将不会等待响应，但还可以使用请求-响应交互调用短时间运行的流程。使用者需要知道所调用的业务流程是长时间运行还是短时间运行，因为它们只能从后者得到即时的结果。

业务流程建模符号（Business Process Modeling Notation，BPMN）正快速成为流程模型的事实 标准符号。不过，用于表示特定于使用者的流程的构件并不一定要为 BPMN 模型。（很难在 BPMN 关系图中包括 UI 的可视表示形式。）可以将用例、屏幕流、线框或 UI 原型作为替代构件使用。在这种情况下，规范必须明确所调用的基础业务流程（短时间运行或长时间运行）和服务，以及结果的处理方式。

长时间运行的流程

长时间运行的流程（或工作流流程）由使用者流程调用，或通过短时间运行的流程生成的事件触发（请参见基于事件的 SOA）。它们设计为可跨这两种类型的流程进行重用。

从进行调用的使用者流程的角度而言，长时间运行的流程是非对话式的，它们可能会调用短时间运行的流程或自动化流程活动。它们还会通过向工作人员的工作列表或队列发送任务来“调用”人工任务。

人工活动

从流程建模的角度而言，在这个上下文中，人工任务由长时间运行的流程进行调用。它们的执行通常在分配了活动的人员从工作列表中选择此活动时开始。人工活动自己本身可以表示为流程，完成可能需要多个步骤（屏幕）。人工任务可能会调用短时间运行的流程和自动化活动。

从技术的角度而言，人工活动是在工作人员登录到工作应用程序并选择任务（或搜索流程实例）时开始的。不过，在此框架中，工作应用程序被视为一种调用机制。从流程建模的角度而言，人工活动由其所属的长时间运行的流程进行调用。由于现代 BPM 平台提供人工任务的 UI 方面，包括工作列表或队列 UI，因此这个抽象变得更为有效。工作列表因而可以视为不需要建模的抽象实体。

短时间运行的流程

短时间运行的流程由使用者流程、长时间运行的流程或人工任务调用。它们必须始终为非对话型的，通常对自动化流程活动进行编排。短时间运行的流程能够实时地告知调用方任务完成（还可能包括结果数据）。

自动化活动

自动活动是业务流程内的原子步骤。它们可能代表验证、创建/读取/更新/删除数据操作和对外部系统的调用。

自动化活动与 SOA 参考体系结构中的服务层对应。在流程建模阶段，活动通常被视为服务操作。

流程控制者

本文中的方法包含这样一个概念，即应该只有一个控制给定流程的实体，也就是流程控制者。

业务流程流始终由某个东西控制。每个流程或子流程应该只有一个流程控制者。如果不能确定这一点，或者新建模的流程从一个控制者跳到另一个控制者，则表明分解过程中有什么做得不对。您可能已标识了另一个子流程。

流程控制者的示例如下表中所示。

在流程分解框架中，每个控制者都属于其中的某个层。上表中的前三个示例与手动流程和客户体验流程层对应。屏幕流可以用于使用者层或人工活动层。对于其他两个示例，对应的层（但愿）很明显。

流程控制器概念使流程建模人员不得不认可流程中的流控制机制。它还将：

• 避免需要对这些流程进行实现的 IT 团队稍后遇到难题。
• 促进过渡到基于 SOA 的体系结构，因为此体系结构中的每个层对应于不同的流程控制者。

尽管流程控制者是抽象概念，但也可以用图形方式表示其对应关系，如图 3 中所示。

每次流程中的某个活动完成时，控制都会交给流程控制者。此“角色”具有流程流的内部表示形式，能根据此表示形式确定下一步骤。上面的符号从未实际使用过，因为它会使流程模型变得无法阅读。

基于事件的 SOA

有些场景包括需要由短时间运行的流程调用的长时间运行的流程，这将导致违反分层原则。如果短时间运行的流程表示事务，而长时间运行的流程表示此事务的实际执行，通常就会出现这种情况。例如，在订单管理场景中，“下订单”(Place Order)（短时间运行）事务需要导致执行“履行订单”(Fulfill Order) 和“补充库存”(Replenish Stock) 流程，而后面两个流程都是长时间运行的流程。

分层原则的主要目的是让较低层不知道其所服务的较高层的情况。这通常意味着较高层可以调用较低层，但是不能反过来调用。这还意味着，较高层将侦听较低层发出的事件，并据此进行操作。

例如，短时间运行的流程“下订单”可能会生成事件“新订单送达”(New Order Arrived)。长时间运行的流程层中的事件侦听器可能会收到此事件，并启动“履行订单”和“补充库存”流程，而“下订单”流程不知道这些流程的存在。

关联到用户建模

使用分解技术和模式设计的业务流程模型非常适合标识和指定用例（及其间的“include”和“extend”链接）及服务。请继续关注本系列，获得关于此主题的更多信息。

结束语

与大部分已确立的流程建模技术不同，本文中介绍的技术并不使用流程层次结构。“层次结构”意味着是树形结构，每个流程属于较高级别的流程（最高级别的流程除外）。在此类层次结构中，子流程通常为嵌入的（与独立流程相对），这会妨碍实现重用。

本文中描述的技术使用了流程堆栈的概念，较高层依赖于较低层提供的服务。服务可能会有基础流程实现。这些服务及其流程化身是独立的，因此可以在不同的较高层流程之间重用。

类似地，“细节级别”的概念经常用于帮助确定子流程。与此不同，本文中的技术考虑职责层。较高的职责层并不一定考虑较高级别的细节。例如，您可以认为使用者流程的细节级别与长时间或短时间运行的流程相同。不过，这些层中的流程 具有不同的职责类型，一个始终调用另一个，但不能进行反向调用。

使服务标识由使用者驱动

通过流程分解技术，使用者流程的模型将标识您在业务流程层中需要的候选服务，而长时间运行和短时间运行的流程的模型标识在服务层中需要的候选服务。因此，服务由被需要的位置和被使用的位置标识。本系列的后续文章将更为详细地讨论服务标识和规范。

使用现有系统分析

现有系统的分析应该提供自底向上视图。在可能的情况下，通过选择将流程中的自动化活动步骤与组织的现有应用程序可以提供的服务进行对应，从而使流程模型与分析保持一致。

致谢

思想不能纯粹靠闭门造车。我非常感谢曾经一起讨论过问题的所有 IBM 同事。尤其要感谢以下同事：Mano Cheema、Sunny Shah、Mike Evans、Bruce Anderson、Joe Hardman、Simon Plackett、Kim Clark、Richard Solly、Pete Cripps、Ian Turton、Tony Carthy、Ali Arsanjani 和 Doug McDavid 提供的信息。

参考资料

• “基于服务的建模和架构”讨论了面向服务的建模和体系结构的要点。
• “使用参考体系结构设计 SOA 解决方案”说明了如何使用 IBM SOA 参考体系结构组织您自己的 SOA 设计、开发和部署，以获得更好的成效和投资回报。
• David G. Messerschmitt 的 Understanding Networked Applications: A First Course 对分层原则进行了很好的介绍。
• Wikipedia 对网际协议组中分层的使用进行了很好的介绍。
• IBM developerWorks 有多个与 SOA 和 BPM 相关的专区，提供了大量培训、概念、模式、产品和服务信息。例如：
  • BPM 专区
  • SOA and Web Services 专区
• 您可以通过使用 IBM SOA 沙箱开始动手培养 SOA 实践能力。
• 了解关于 developerWorks 技术事件和网络广播 的最新消息。

• 下载 IBM 产品评估版，获得来自 IBM® DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。

• 参加 IT 体系结构论坛，交流技巧和技术，分享关于 IT 体系结构这一广泛主题的其他相关信息。