级别： 中级 Brian Byrne, InfoSphere 架构师, IBM
Greg Imirzian, 技术联盟经理, ILOG
Janet Wall, 高级产品经理, ILOG
2009 年 2 月 16 日 本文是包含 2 部分的系列文章的第二篇。本系列讨论如何使用 IBM® Industry Models 和 ILOG® 业务规则管理系统 (BRMS) 分析、设计和部署业务规则。本系列 中的 IBM Industry Models 和 ILOG 业务规则管理系统，第 1 部分：使用 IBM Industry Models 定义业务规则 介绍了 IBM Industry Models 的部署阶段，在此阶段应该考虑规则的分析和设计，以及如何识别和管理规则。在本文中，讨论如何使用 ILOG BRMS 指定这些规则，支持基于 Industry Model 的 BPM/SOA 解决方案。
分析业务规则语句
本系列 中的 IBM Industry Models 和 ILOG 业务规则管理系统，第 1 部分：使用 IBM Industry Models 定义业务规则 讲解如何根据业务需求识别和指定业务策略和规则语句。现在，通过分析这个阶段的输出，确定可重用的原子性业务规则。可以看到，业务相关人员提出示例业务规则语句 “...必须检查潜在客户的信用并标识他们...” 并在 IBM Rational® RequisitePro® 中捕捉它，实际上它包含多个单独的规则。还可以看到如何把这个规则语句分解为单独的规则，而不损失任何业务信息：
通过进一步分析，还可能获得关于这些规则的含义的更多信息。例如，分析 “客户” 的生命周期模型可以获得以下信息：
图 1. 客户的状态迁移模型
根据这个模型，可以看出 “潜在” 实际上是 “客户” 概念的一个生命周期状态。另外，现在得到了关于 “客户” 概念的有效状态和状态之间的有效迁移的重要信息。同样，通过进一步分析 “标识” 的含义可以产生 “主要标识” 和 “次要标识” 等词汇的定义。这些词可能与模型中的业务概念和概念之间的关系直接相关。
最后，对相关规则的分析常常会影响原子性规则的定义。例如，通过分析相关的上下文可能会发现，客户的标识是很重要的，对于潜在状态和其他所有状态都是如此。因此，可以对此规则进行一般化，把它从 “潜在客户” 领域提升到 “客户” 领域。但是，对于此示例，我们把考虑范围限制在 “潜在客户” 领域。
所有这些分析最终产生两个原子性业务规则：
- 必须检查处于潜在状态的客户的信用
- 客户必须提供主要标识和次要标识
这些原子性业务规则语句也与 Industry Models 中的业务类型相关联。尤其是，需要像 BOM 的规范化模型中那样，使用便于理解的业务类型定义原子性规则语句中的业务类型。
把业务规则语句与原子性业务规则关联起来
定义了规范化的业务规则层之后，需要能够跟踪与这些规则相关的模型元素以及这些规则层之间的关系。在定义原子性业务规则时，应该把它们与产生它们的业务规则语句关联起来，进而与业务策略关联起来。这种可跟踪性依赖于原子性规则的表达方式。由于缺少支持可跟踪性的专门工具，这个示例主要关注 RequisitePro 中规则需求的扩展，从而用跟踪关系向 RSA BOM 模型表达原子性业务规则，提供业务类型的规范化。根据规则的复杂性和组织需要实现的规范化程度不同，这可能需要在 RequisitePro 中建立表示原子性规则的另一个需求类型，或者维护从规则语句演化到原子性规则的单一需求类型。
另外，还可以使用 RequisitePro 在原子性业务规则和调用此规则的服务之间创建可跟踪性关系。例如，RequisitePro 结构 Credit Check Review （“……必须检查潜在客户的信用并标识他们……”）可以与 IDM 结构 analyzeCustomerRelationship 相关联。
进一步使用 RequisitePro 中的跟踪树，可以显示从业务策略到业务规则语句，再到原子性业务规则的关联关系。
结合业务规则管理系统
建立一系列业务规则策略和语句以及相关联的原子性业务规则之后，必须以规则表达式的形式把这些信息转换为与平台相关的格式。规则表达式可以采用各种格式，一项关键的设计决策就是决定哪些规则最适合用哪种形式表达。例如，哪些规则适合发送到外部业务规则管理系统 (BRMS)，哪些可以采用硬编码方式？
什么时候应该使用 BRMS
通常，应该考虑把在需求中经常出现的规则保存在外部。与普通的编码技术相比，使用规则引擎的主要好处是，在需求发生变化时，规则引擎可以高效地控制对业务规则的修改。与产品行为、条款或条件相关的规则常常会随市场的需要变化，应该保存在外部，从而提高灵活性。
另一个因素是规则的复杂性。许多规则管理环境能够管理复合规则、决策表和相互依赖的规则元素。组织策略等非常复杂的规则可能不会经常变化，但是因为很难用普通编码表达它们，所以也适合使用规则管理环境。
第三个因素是各种用户角色需要基于规则的访问，包括非技术性策略分析师。企业级的 BRMS 为业务用户提供一个协作环境，这个环境能够与相关的技术环境同步。
第四个因素是重用。规则常常是嵌套的，常常需要重用一些规则的片段。尽管也可以在编码中实现，但是在规则管理环境中构建这些片段，就能够更好地控制和管理重用，对于动态或复杂的规则尤其如此。
在 BRMS 中使用 Industry Models 工件
Industry Models 中的许多工件提供对于设计和编写业务规则有帮助的信息。BRMS 可以以多种方式使用这些工件：
-
通过引用链接提供可跟踪性：BRMS 工件可以与相关的 Industry Models 需求和规范的链接相关联。例如，在 Industry Models 中的业务规则策略/语句与 BRMS 中相关的具体业务规则实现之间可以建立双向引用链接。
-
直接导入标准工件：在某些情况下，Industry Models 工件采用可以直接导入 BRMS 的格式。例如，Industry Models 中的数据模型可能采用 UML、XML 模式等格式，可以把它们作为基本数据/对象模型直接导入 BRMS。
-
使用定制的工具扩展转换工件：如果由于格式不兼容，不允许把 Industry Models 工件直接导入 BRMS，那么在某些情况下可以使用定制的导入/导出实用程序。
下面几节详细讨论在 ILOG JRules™ 这种 BRMS 中如何使用这些方法。
ILOG JRules 概述
ILOG JRules 支持编写、测试、模拟、部署、执行和管理业务规则。
图 2. ILOG JRules
主要的 JRules 模块包括：
-
ILOG JRules Rule Team Server：这是一个规则管理服务器和存储库，它提供一个基于 Web 的协作环境，支持编写、管理、检验和部署业务规则。
-
ILOG JRules Rule Studio：这是一个基于 Eclipse 的集成开发环境 (IDE)，技术人员可以使用它支???规则应用程序开发和调试。
-
ILOG JRules Rule Scenario Manager：这是一个集成的环境，用于测试、检验对规则的纠正和模拟业务策略中的修改。
-
ILOG JRules Rule Execution Server：这是一个符合 J2SE 和 J2EE 规范的规则执行环境，包括用于同步、异步和通过 Web 服务调用业务规则的组件。
业务规则的表示
在 JRules 中，业务规则用以下三种形式之一表示：
对象模型和规则词汇表
在 JRules 中使用一个词汇表表达业务规则，其中的词汇和短语来自底层的 Business Object Model (BOM)。
图 6. JRules BOM 词汇表
JRules BOM 是从具体的 eXecutable Object Model (XOM) 派生出来的，XOM 包含 Java 类和 XML 模式等技术工件。如果一个 BOM 元素与某个 XOM 元素直接关联，不需要转换，那么在相关联的 BOM 和 XOM 元素之间就不需要显式的映射。在其他情况下，可以指定显式的 BOM-XOM 映射，从而定义如何从一个或多个 XOM 元素派生出 BOM 元素。例如，假设需要一个代表客户年龄的 BOM 元素，但是底层的 XOM 只包含客户的生日。那么，可以给代表客户年龄的 BOM 元素定义相关联的 BOM-XOM 映射，它用生日计算出年龄。
图 7. JRules 词汇表关系
可执行的规则服务
业务规则作为规则组部署在运行时规则执行环境（Rule Execution Server）中。规则组表示一个可执行的服务，服务有输入/输出参数，这构成一个发布的服务接口。可以使用标准的服务执行机制调用这些运行时规则服务，比如基于 SOAP 的 Web 服务、JMS 消息传递或 EJB/POJO 调用。
集成 JRules 和 IBM Industry Models
维护需求的可跟踪性
Industry Models 框架中维护的业务规则工件常常构成在 BRMS 中实现的具体业务规则的需求。因此，在需求工件和实现工件之间维护引用链接是很重要的。需求工件可以包含各级业务逻辑的任意组合：业务策略、业务规则语句和原子性业务规则。
维护这种可跟踪性的一种简便方法是，在需求工件和 BRMS 工件中添加适当的元数据。这些元数据可以是任意形式的文本；但是 URL 或工件名称/ID 等引用数据更有意义。
例如，可以按以下方式使用 RequisitePro 和 JRules 实现元数据：
- 对于 RequisitePro 中的需求工件（策略、语句和原子性规则），可以添加一个定制的属性，其中包含对 JRules 中特定规则或规则组的引用。这个引用可以是名称或描述，也可以是 JRules Rule Team Server 中的 URL，这样就可以在 BRMS 环境中直接导航到适当的工件。
- 对于 JRules 中的业务规则工件，可以添加一个定制的属性，其中包含相关联的 RequisitePro 需求工件的名称。JRules 允许在规则工件中添加任意数量的定制属性，定制属性可以是简单的字符串描述或结构化的数据对象。
从 IBM Industry Models 导入工件
在 JRules 中创建规则词汇表的典型过程如下：
- 导入 XOM（XML 模式和 Java 类的组合）
- 从 XOM 生成默认的 BOM 和词汇表
- 根据需要创建额外的 BOM 元素和相关联的 BOM-XOM 映射，从而扩展 BOM
- 根据需要调整词汇表，提高可读性
在上面的第一步 “导入 XOM” 中，可以直接导入 Industry Models 中的 XML 模式和 Java 类。
例如，假设希望为前面 RequisitePro 示例中的 “Analyze Customer Relationship” 活动实现一个基于规则的决策服务。用 WSDL 指定 Analyze Customer Relationship 活动，这个 WSDL 定义一个服务接口。然后，把这个 WSDL 与为服务定义消息内容的 XML 模式关联起来。可以把这些 XML 模式导入 ILOG JRules，形成创建规则集所用的基本 XOM。
图 8 显示从 IFW 导出的一个 XML 模式片段，它定义 “客户” 的概念。注意，这个导出操作使用 WSDL/XSD 生成器以 XML 模式的形式提取 IFW IDM 模型。
图 8. 导出 IBM Industry Model BOM
这个定义包含 “lifecycleStatus” 属性，其定义如下：
图 9. 导出 XSD 生命周期状态
在把 XOM 导入 JRules 之后，生成 JRules BOM 和相关联的词汇表。如图 10 所示，客户的 lifecycleStatus 属性显示在 Rule Studio BOM Editor 中了：
图 10. 生成的 JRules BOM 结构
尤其要注意如何生成 lifecycleStatus 的 “表示法”：
图 11. 生命周期状态的表示法
表示法是文本和占位符的组合。在这个表示法中，占位符 “{lifecycle status}” 代表一个主题短语（在这里默认值为 “lifecycle status”），占位符 “{this}” 代表包含它的类（在这里是 Customer）。在编写规则时，会自动地填写某些占位符，其他占位符要使用下拉列表或文本定义。
图 12 说明在业务规则中如何显示生成的词汇表元素：
图 12. 在规则中使用的表示法
使用定制的工具扩展自动生成 JRules 工件
JRules 允许通过发布的 Java API 创建业务规则工件。可以以这种方式创建的工件包括：
- 业务规则
- 业务规则模板
- BOM 和词汇表元素
- 业务规则组织结构（包层次结构）
如果 Industry Models 工件提供了生成相应 JRules 工件所需的详细信息，就可以考虑使用定制的转换代码自动生成 JRules 工件。转换代码可以采用 Eclipse 插件的形式，比如用于 RequisitePro 的定制导出插件或用于 Rule Studio 的定制导入插件。
基于 Industry Models 的决策服务接口
现在，可以公开已定义的规则集的 Web 服务 (WSDL) 接口，让业务过程等服务消费者可以调用这个接口。注意，因为我们使用 Industry Model 派生出的 XSD 规范构造规则，所以在规则 Web 服务的数据参数和 IFW 派生的其他基础结构之间有直接的关联。
图 13. 向 BPM/SOA 环境公开规则
结束语
在使用 IBM Industry Models 分析和设计规则时，应该按次序完成一系列步骤，包括定义规则需求、分析原子性规则和定义与目标相关的规则表达式。另外，还有许多模式有助于维护规则体系结构的完整性。以服务形式开发规则可以隔离规则消费者和规则提供者，而把规则绑定到相关的行业模型元素有助于管理规则重用和相互依赖。
另外，ILOG 业务规则管理系统提供指定、管理和执行规则的功能。用 IBM Industry Models 帮助指定 ILOG 规则有助于更好地了解重用业务规则的可能性和执行它们的业务上下文。
规则生命周期的一些部分可以自动化，这可以提高规则定义的一致性，有助于更好地适应未来的业务需求。
参考资料 学习
获得产品和技术
-
使用可直接从 developerWorks 下载的 IBM 试用软件 构建您的下一个开发项目。
讨论
作者简介  | 
| | Brian Byrne 在分布式系统的设计和开发领域具有 10 年以上的经验，并花了 7 年时间推动 Industry Models 体系结构在各种企业中的应用。Brian 当前是 IBM Information Management 组织的架构师。 |
| 
| | Greg Imirzian 是 ILOG 的一名高级技术联盟经理，他与很多行业的 ILOG 合作伙伴一起，确定如何最佳地在面向服务架构环境中应用业务规则和优化技术。Greg 在高级决策支持软件系统的设计和开发领域有超过 20 年的经验。 |
| 
| | Janet K. Wall 是 ILOG 的 BRMS 产品的高级产品经理和市场营销经理，主要从事专业 BRMS 市场的产品战略和需求。Janet 在业务规则和信息管理领域有超过 20 年的经验，曾经在多种平台上设计和实现业务应用程序。 |
对本文的评价
| 
