本文描述一种面向组件的业务流程建模方法，该方法支持捕获流程变化，确保模型可重用。文中描述了 WebSphere® Business Modeler 中有助于您实现此目标的建模模式和实践。

简介

今天的业务动态正迫使企业不断提高业务流程对变化的响应能力。这使业务流程模型的模块化和灵活性变得至关重要，不仅对于不断提高的建模敏捷性，而且对于更高的健壮性和流程执行的灵活性也是如此。传统的业务流程建模方法通常会产生难以更改和维护的大型模型。由于它们的规模，这些模型不是很灵活。它们也不支持动态流程选择 —— 也就是说，流程模型的各个部分无法在执行期间轻松替换。

一个需要动态流程选择的出色场景示例是，根据遇到的错误类型调用不同的异常处理流程。解决此问题的传统方式使用多选决策。图 1 所示的普通流程顺序示例演示了这一方法。如果顺序无效，则根据决策结果从 3 条路径中选择一条。

这种方法的一个明显的局限性是，必须为每个新的错误处理流程创建一个新的决策分支。因此，流程需要更改，所有相关的文档操作、部署和测试都必须重复执行。这还意味着最终会得到一个非常大的流程。

业务流程即组件

解决上述问题的一种更加模块化的替代方法是，使用业务服务接口 “代替” 多个兼容流程中的一个（兼容表示它们具有相同的接口）。然后即可在执行时动态选择单一流程。参见图 2。

初看起来，这似乎只是在建模风格上做了细微更改，但其意义深远。首先，流程接口通过其输入和输出明确定义（参见图 3）。但是最重要的是，流程依赖关系也通过接口（Business Modeler 中的业务服务）明确地予以公开。这实际上表明，通过这种方式建模的流程是一个组件，因为它体现了最基本的组件属性：组件声明它提供和依赖的服务。

内聚性 是通常与软件组件相关联的另一个属性，也是人们非常希望在业务流程建模环境中实现的一个属性。尽管组件内聚性背后的理念可能很简单（将相关功能结合在一起），但它确实需要出色的分析技能才能实现。流程依赖关系的数量和复杂性可用于度量流程的内聚性，依赖关系的数量越少以及依赖关系复杂性越低，流程的内聚性就越高。

如果我们同意只要业务流程 (1) 具有内聚性且 (2) 公开了服务和依赖关系，它们就是组件，那么使用 “面向组件的业务流程建模” 来描述创建这类流程模型的活动就在恰当不过了。这个业务流程即组件的概念不是技术或实现领域专用的，业务的组件视图对于更高的业务敏捷性也必不可少。因此，如果您的目标是使业务与技术更加一致，以及轻松响应不断变化的业务需求，那么在一个领域中使用组件必然暗示着在另一个领域中使用组件视图。

毫无疑问，组件可以包含其他组件，但是它们包含其他组件的方式可能有所不同。为了实现更高的灵活性，我们提议不要将业务流程组件静态地绑定到其组成组件上。相反，依赖关系应该在运行时根据执行业务规则的结果来注入。这里使用的术语注入 类似于更加技术性的 “依赖关系注入” 概念（用在流行的 Spring 框架和服务组件架构（Service Component Architecture，SCA）中，服务组件架构已经为使用此方法构建的解决方案提供更高的重用潜力、健壮性和灵活性）。参见 参考资料，获取 Spring 和 SCA 的更多细节。

使用 WebSphere Business Modeler 进行面向组件的流程建模

术语服务 和接口 可交替使用，因为在 Business Modeler 中，服务通常表示一些外部服务实现的接口。Business Modeler 将在 Business Modeler 中定义的服务（有时称为全局服务）与作为 Web 服务定义语言（Web Services Definition Language，WSDL）服务导入 Business Modeler 的服务区分开来。在面向组件的方法中，两种服务类型都可用作接口，前一种服务用于自顶向下方法中，后一种服务用于自底向上方法中（请参见 面向组件的流程建模与 SOA）。Web 服务定义可以从文件系统、WebSphere Services Registry and Repository 或者Rational® Asset Manager 导入。

使用面向组件的流程建模方法，组件在 Business Modeler 中表示为没有联系的全局流程。因此必须：

1. 定义 “胶合条件” 来将它们结合在一个业务流程中
2. 定义一种建模模式来实现此流程的端到端视图

业务规则充当 “胶合条件”

管理流程和服务的动态组成的最灵活方式是使用业务规则。在典型实现中，业务规则用于检测流过特定节点或流程流中的特定点（称为变化点）的数据，以及决定流程流中的下一个路径。在我们的示例中，一条简单规则可能是 “如果验证输出是错误代码 ‘999’，那么必须由管理程序授权对顺序的相应修正”。“必须由管理程序授权” 意味着实现此功能（在本例中即授权修正顺序）的流程是动态调用的。WebSphere Business Services Fabric（以下称为 Business Services Fabric）非常适合于定义、管理和执行此类规则。在 Business Modeler 中，您可以将一个服务接口指定为动态组装器（Dynamic Assembler）（参见图 4），以指示它是一个 Business Services Fabric 变化点。然后，您可以在 Business Services Fabric 内部为该组件定义规则和策略。参见 参考资料，了解变化点的详细信息。

尽管 Business Modeler 支持定义业务规则来控制决策结果，但管理动态端点选择的业务规则必须在其他地方定义，比如在 Business Services Fabric 中。出于此原因，我们提议在 Business Modeler 中以注释的形式归档用于动态流程的规则（如图 5 所示）。

建议的端到端表示流程

因为高级业务流程（包含其他流程组件的流程）具有动态变化的流程流，所以它具有多个端到端视图。但是，这类视图可以通过一种抽象方式来描述。我们提议使用如图 5 所示的表示模式来实现流程变化的可视化。

在此图中，Validate Order、handleException 和 Fulfil Order 组成了（普通的）端到端流程，而 Amend Order、Amend Order with Authorization 和 Cancel Orders 是 handleException 的可能实现。每个实现旁边的注释记录了在执行时触发对相应实现的选择的条件（业务规则）。

使用面向组件的流程建模时需要考虑的一些其他建模因素如下：

• 异步流程。在使用面向组件的流程建模对异步流程进行建模的方式上没有什么特殊之处。任何流程组件都可以发出 “触发并忘记” 请求，而且任何（具有适当的接口来接收响应的）组件都可以充当 “监听器”。但是，这里有一点细微区别。尽管在评估业务规则时会调用 “标准” 的流程组件，但异步流程组件由一个事件或消息的到达来触发。因此，将给定组件指定为监听器（一条注释可能就足够了）并相应地实现该组件，这一点很重要。
• 共享上下文。有时必须跨流程组件调用来保持业务对象状态。例如，如果没有将完整的 Order 对象作为输入参数传递给所有流程组件，则可能必须将该对象存储在某处，以便端到端顺序流程中的每个组件能够访问它。“某处” 可能是一个数据库，或者可能是某种形式的 “流程上下文”（除非由底层软件适当管理，应该避免后者，因为它存在隐含的可伸缩性问题）。在流程组件调用之间保持流程状态的方式不应该由业务流程建模来负责。但是，流程使用不是来自其输入的数据（或从该数据生成输出）的事实应该在流程模型中注明。在 Business Modeler 中，一个流程及其（连接的）子流程可以通过全局存储库共享数据，但这使用流程组件不可能实现（它们没有连接到父流程）。我们建议的解决方案是蕴含着这样一个观点：上下文交互是流程在 “上下文服务” 上拥有的依赖关系。因此，它们使用服务接口来表示，并且不应该采用与任何其他依赖关系不同的方式来对待它们。
• 流程模拟剖析。因为针对动态流程组装的业务规则和策略无法在 Business Modeler 中直接定义，所以其模拟引擎无法模拟包含其他已解耦流程的流程。可以单独模拟每个流程，但是如果目的在于通过逐次模拟来改进流程，很显然对各个部分的优化不一定能够实现对整个流程的优化。如果要实现优化目的，必须将接口替换为各自的子流程形式的流程实现。
• 业务流程监控剖析。在 Business Modeler 中，您可以定义特定于特定流程的业务度量和关键绩效指标（KPI）。可以从每个 Business Modeler 生成一个 WebSphere Business Monitor 模型。由于一个较大的（父）流程中包含许多已解耦的流程模型，所以不再可能为父流程及其所有流程组件生成单一监控模型。这不是一件坏事。我们现在除了拥有已解耦的业务流程，最终还得到了相应的 “已解耦” 监控模型，并且作为一种副产品，我们还实现一种更加模块化的监控方法。

细心的读者现在可能会想到，如果目的在于独立监控每个流程组件，这种方法将会生效。如果我们希望监控端到端流程（例如，如果我们希望建立涵盖一个顺序的整个生存期的指标），则不会生效。解决方案是使用一种已经建议为最佳实践的监控模型创建方法。该方法将监控模型分为两种独立的监控级别：高级监控模型 和低级监控模型。低级监控模型从正在运行的流程接收事件，并将（合适的）事件传播给高级监控模型。此方法的最初意图是在运行流程与高级监控工件（比如 KPI 和业务度量）之间进行一定程度的隔离。使用已解耦的组件流程，您可以使用相同的方法，但是在本例中，我们使用许多低级监控模型来将事件传播给监管整个流程的单一高级监控模型（参见图 6）。

Business Modeler 可以生成高级和低级监控模型，但是不支持生成为一个高级模型服务的多个监控模型。这必须在 Monitor Model Editor 中完成。

面向组件的流程建模与 SOA

在大部分业务环境中，流程模型不仅创建用于描述新功能，还用于定义这些功能如何连接到现有系统。在越来越多的案例中，现有遗留系统的接口实现为遵从面向服务架构（Services Oriented Architecture，SOA）设计原则的 Web 服务。这些服务可以以业务服务 的形式导入 Business Modeler。在 Business Modeler 中，业务服务可以由一个或多个业务流程引用。

此方法需要两种分析类型：自顶向下分析用于理解有哪些新业务功能以及这些功能如何彼此交互，自底向上分析用于理解已存在哪些功能以及这些功能如何在新解决方案中重用。对此分析流程的连续迭代会实现期望的资产重用目标，以及业务流程与技术之间更好的一致性。

在面向组件的业务流程建模中，业务服务不再仅仅是外部系统或服务的接口，它们还是新的或现有流程组件的接口。因此，面向组件的方法能够（但不是必须）实现更严格的流程建模方式和原则，确保流程完全实现重用潜力。然后，这类可重用流程组件必须经过自顶向下或自底向上的 SOA 分析流程分析。

结束语

文本提出了一种面向组件的业务流程建模方法，解决了业务流程模型中的模型规模、重用、模块化和灵活性问题。这种方法将一个流程组件定义为一个内聚性的业务流程，以接口的形式公开其输入和输出，并将其所有依赖关系声明为接口。它还支持将这类流程组件动态组装到一个较大型流程或流程组件中。

参考资料

• Spring 框架简介（developerWorks，2005 年）：本文将 Spring 介绍为一种 IOC（控制反转（Inversion of Control），也称为依赖关系注入）容器。
• 系列文章： 使用 WebSphere Business Services Fabric v6.1 构建组合业务服务：本系列文章向您介绍了 WBSF 的概念，以及如何构建组合业务服务。
• 系列文章： 使用 WebSphere Business Services Fabric 开发自适应组合业务服务：本系列文章将讨论使用 IBM WebSphere Business Services Fabric Version 6.0 创建组合业务服务的端到端流程。
• 查看 演示：使用 WebSphere Business Modeler 进行业务建模系列 ，本系列演示面向业务建模工具 WebSphere Business Modeler（WBM）的初次使用者。
• 查看 developerWorks 上关于 WebSphere Business Modeler 的技术文章，了解更多 WebSphere Business Modeler 的功能及使用方法。
• SCA（Service Component Architecture）编程模型入门：本文将介绍 SCA 编程模型中的基本概念,并以一个简单的例子来说明它的一些基本用法,期待能够抛砖引玉,并为读者以后深入了解 SCA 打下基础。
• SCA 规范介绍：服务组件体系结构（Service Component Architecture，SCA）是一组规范，描述了用于使用面向服务的体系结构来构建应用程序和系统的模型。在这里，您可以找到和它相关的一些官方文档和开发手册。
• SCA 专题为您汇总了 developerWorks 上关于 SCA 的所有技术文章。
• Introducing SCA。这是 David Chappel 编写的一篇优秀的 SCA 介绍文章。
• 随时关注 developerWorks 的技术活动 和 网络广播。
• 浏览 技术书店，查找关于这些主题和其他技术主题的图书。

• 马上下载 WebSphere Business Modeler Advanced V6.2 试用版。
• 下载 IBM 产品评估版 ，并开始使用来自 DB2、Lotus、Rational、Tivoli 和 WebSphere® 的应用程序开发工具和中间件产品。

• 参与 developerWorks blogs 并加入 developerWorks 社区。