用于实现 Web 服务的 SOA 编程模型，第 9 部分: 将规则与 SOA 集成

本文将讨论业务规则如何作为一种组件类型与 IBM 面向服务的体系结构（Service-Oriented Architecture，SOA）集成，从而带来业务灵活性的好处以及可补充其他组件类型的功能的备选执行模型。您将了解三种普通规则类别——序列规则、事件相关规则和推理规则。

引言

SOA 包含各种组件实现类型，如传统 Java™ 对象（plain old Java™ object，POJO），业务流程执行语言（Business Process Execution Language，BPEL）流程、业务状态机和很多其他类型。本系列的第 1 部分，介绍了 SOA 概念，第 6 部分将组件作为 SOA 的主要部分进行了描述。

开发人员可使用任意的不同软件或组件类型实现服务组件。有些服务可从使用业务规则组件类型进行实现而受益，因为规则提供了有用的解决方案特征。本文的一个目的就是对各种类别的业务规则进行简要总结，并说明单个与 IBM SOA 集成的方法如何适应不同类型的规则。

所有组件类型（包括规则）都可放入到单个解决方案组合模型 SOA 中。SOA 的一个主要好处在于，业务集成者可以使用一个组件替换另一个组件，而不会对业务解决方案的其余部分造成影响。本文的第二个目的是，讨论当业务规则根据 SOA 进行实现时如何使这个好处变为现实。

在 SOA 中，服务可以通过仅使用请求消息或同时使用请求消息和响应消息来相互进行同步或异步交互。本文还将描述不同类别的规则与各种服务交互样式进行交互的方式。

业务规则

业务规则分为三个大类：

1. 顺序规则提供顺序执行的声明性规则。此规则类别通过允许非编程人员对规则进行维护从而支持业务灵活性。

   这个类别包括 if-then 语句和决策表。

   
   
   图 1. If-then 规则
   soa-progmodel9/fig1.gif" width="546" twffan="done"/>
   
   

   和其名称一样，每个 if-then 规则包含一个 Boolean 表达式，用于确定是否执行在 then 子句中指定的一个或多个操作。这些操作可以计算规则结果、赋值或调用其他服务。在图 1 中，if-then 规则将重量在 1 到 5 磅之间且体积小于 9 立方英寸的包裹的运输和处理费用指定为 5。

   
   
   图 2. 决策表
   
   
   

   决策表可提供正交条件 的精简可视化表示。它们等效于多个 if-then 规则，用于测试相同条件具有多个值的情况。图 2 显示了为包裹的各种重量与体积组合分配运输和处理费用的决策表。所有体积超过 9 的包裹和所有重量大于 5 的包裹的运输和处理费用都为 7 美元。对于体积小于 9 的包裹，当体积小于 1 时费用为 2 美元，而重量小于 5 时费用为 5 美元。

   序列规则的主要好处在于其在业务分析人员或其他非编程人员管理规则方面的潜力。这得益于序列规则易于理解的形式和各种简化规则管理工作的工具。

   第二个好处在于可以将规则作为 SOA 中的独立服务组件实现。将规则从其他服务分离出来，可以在不影响其他服务的前提下更新规则。大部分规则实现都允许动态更新规则，支持在无需进行其他组件类型通常所需的开发和部署周期的情况下进行更改。这些好处为业务规则实现带来了极大的灵活性，允许在 IT 相关约束更少的前提下对规则进行改进。

   IBM WebSphere® Process Server 和 IBM WebSphere Integration Developer 支持 if-then 规则和决策表，因此可为采用 SOA 环境的客户提供这些好处。

2. 事件相关规则可识别先后发生的多个事件间的关系。这些规则通常将对某个时间段内的消息按照类型和条件进行筛选，然后根据各种预定义模式检测各种状况。事件相关规则用于识别一系列消息或事件中的 IT 或业务事件状况。例如，produce an alert if "check customer rating" service generates more than 10 SOAP faults within 1 minute。

   IBM Tivoli® Enterprise Console 可使用事件相关规则来识别给定时间段内从多个源生成的事件中的事件模式。通过这些规则，该软件可以方便地识别在 IT 或业务监视中值得注意的状况，从而将在其他情况下需要通过很多手动工作或进行编程来完成的任务简化为创建相当简单的规则语句。

3. 推理规则实现演绎法、归纳法、Prolog 样式的统一或其他人工智能（artificial intelligence，AI）样式的规则。可从推理获益的用例是那些设计到很多相互依赖的规则的用例，这些规则的执行顺序必须依赖于数据而不是预先确定的。资源选择、优化、问题诊断和规划问题通常都需要进行一定的推理。这些问题涉及到在很多潜在解决方案中进行搜索，以找到那些满足规则的解决方案。

规则集

大部分规则系统都将规则分组为规则集，规则集在工具中预定义或在运行时进行动态组合。规则集包含规则列表，其中的规则联合对一组输入进行计算，并产生一个或多个结果。决策树提供了序列 if-then 规则集的另一种表示形式。

图 3 显示了包含两个 if-then 的规则集。接口部分记录规则集的输入和输出。第一个规则指定重量小于 1 磅且体积小于 9 立方英寸的包裹的费用为 2 美元。第二个规则指定重量在 1 到 5 磅之间且体积小于 9 的包裹的费用为 5 美元。

每个规则集实现接口的单个操作，可实现该操作的用途（按操作或方法名称确定）和签名（参数和结果）。因此，每个规则集可承担 SOA 中单个操作的角色。

这个方法有诸多优势：

• 客户机服务不知道其所使用的服务是如何实现的——是否采用规则或其他实现技术——也不知道规则所属的规则类别、何时存在选择。这意味着客户机可以在不同安装或不同时间链接到其他服务组件，从而提供了一定程度的配置灵活性。
• 常见的类型安全好处都是通过服务协约实现的。
• 编程模型简单——不需要使用特殊 API 调用规则。
• 流程编排引擎可以像调用其他服务一样调用规则。引擎并不需要知道特定的操作是使用规则实现的。
• 重用现有容器功能，如访问控制和事务管理。例如，在解决方案设计中，可能务必使 getDiscount 计算和客户机应用程序的其他部分一起参与相同的事务。由于可以像其他服务类型一样调用规则，因此容器功能可以应用到规则。

业务规则组

如图 4 中所示，服务可以提供多个操作，而规则集实现单个操作。业务规则组对联合实现服务的所有操作的多个规则集进行包装。从服务连接的角度来看，业务规则组是“连接”到应用程序中的组件。因此，业务规则组将多个规则集打包为服务，以将提供的可能由其他服务引用的接口导出。

例如，业务规则组可能通过包含与每个操作对应的规则集来实现一个客户关系管理（Customer Relationship Management，CRM）接口（包含 calculate discount 和 calculate shipping 操作）。如果服务客户机连接到使用图 5 中的规则集的业务规则组，则当客户机调用 calculate shipping 操作时将执行相应的规则。

每个业务规则组均支持在提供的接口中定义的操作，从而实现了类型安全。通常，工具会将业务规则组生成为外壳代码，该代码用于实现操作签名、捕获输入参数并以特定于引擎的方式将其传递规则引擎。外壳代码用于解决应用程序特定的操作签名和很多规则引擎的独立于应用程序的接口之间的错误匹配。图 5 显示了提供客户机和规则引擎之间的桥梁的外壳代码，该代码允许客户机将规则作为服务调用，并允许规则引擎参与 SOA。

从规则调用其他服务

业务规则通常需要调用其他服务，可以将其作为测试条件的一部分（如 "'if moon.getStatus() == "Full" …'）或调用操作（如发送电子邮件）。我们将此建模为两个部分：

1. 每个业务规则组根据 SOA 定义零个或更多服务引用。服务引用指定所需的服务规范。
2. 在图 4 中，规则属于规则集，而规则集属于规则组。规则可以调用从间接“拥有”规则的业务规则组引用的任意服务。

此方法支持一种特定的开发生命周期，在此生命周期中，规则组和其他服务间的关系的定义早于使用这些服务的实际规则集和规则。应用程序可以在实现时或部署时定义和连接，而规则可以在正在运行的系统中进行管理。

例如，一些业务规则组可以引用服务 A、B 和 C。有时候，该规则组内的规则可能会实际调用服务 A，而在其他时候，这些规则也会调用服务 B。但这些规则无法调用服务 Z，因为相应的业务规则组没有引用该服务。

调用样式

服务主要采用两种方式进行交互；这两种方法都适用于规则：

1. 请求-响应样式——由客户机服务进行同步调用。客户机调用可能产生同步结果的服务。
2. 事件处理样式——异步消息处理，如 IBM WebSphere Enterprise Service Bus 中的情况。客户机以“Fire-and-Forget”的方式向服务发送一条消息。服务将通过两个异步消息向客户机传递回响应（如果有响应）。

我们将首先讨论请求-响应样式，因为事件处理样式以请求-响应样式为基础。

请求-响应样式

在请求-响应调用样式中，客户机服务调用恰巧通过规则实现的操作。规则的上下文是从客户机传递的参数，还包括规则可访问的任何静态数据或服务以及规则内维护的任何状态。对于任何操作，相应规则将执行一些计算工作，并可能向客户机返回结果。规则还可能通过调用其他服务进行一些操作或其他工作。

对于 SOA，所有操作签名都是特定于用法的。因此，计算折扣的操作的输入、结果和名称将与验证驾驶员是否适合保险的操作完全不同。每个应用程序的设计者指定传递给规则的输入值，以及任何希望规则提供的结果，不需要使用特殊 API 来调用规则。

事件处理样式

在事件处理样式中，规则集同步处理消息流，如图 6 中所示。规则集将逐个检查每条消息，并可能采取某些操作（通过调用其他服务）或生成出站消息。典型的应用包括响应各种业务状况、审计业务事件以发现不规则情况和监视 IT 事件以发现问题等。规则技术简化了此类应用，更便于用户定义消息处理，而无需具备此类编程专业知识。

事件处理样式以前面描述的请求-响应样式为基础。业务规则组接受此类传入消息并调用规则集。通常，规则集会将传入消息作为参数接收，且不返回结果（由于使用的异步处理环境）。规则集通过调用另一个服务产生输出（如果有），此服务可能与任何其他消息源关联，也可能不与任何其他消息源关联。因此，从规则技术角度来说，事件处理样式和请求-响应样式的区别是环境方面的，而不是本质区别。两种样式的规则执行模型并没有变化；仅在用于调用规则集的接口的签名以及规则与客户机应用程序的交互中存在差异。

无状态规则和有状态规则的对比

和其他服务实现类型一样，业务规则可能为无状态的或有状态的，即可以选择跨多个调用维护内部数据记录。规则可通过保存状态来将其上下文扩展到整个调用历史，支持依据传递到当前调用的参数之外的其他因素进行决策和计算。有状态规则的例子包括大部分事件相关规则和一些推理规则的使用。

业务规则内维护的状态数据和客户机服务间的关系是特定于应用程序的，不能在体系结构中进行处理。通常，规则将使用一个或多个调用参数来处理相应的内部状态。

任何规则内维护的状态都应加以保持，以支持集群配置和大部分业务配置通常要求的高可用性。对于很多规则系统而言，支持规则提供的灵活性以及可伸缩性和可恢复性可能是一项很大的挑战。

典型使用模式

前面的讨论中给出了两个基本规则调用样式（同步请求-响应样式和异步事件处理样式）并对无状态处理和有状态处理进行了区分。调用样式和有状态及无状态执行有四种可能的组合，任何规则类型（如前面所述）都可以采用其中的任意组合进行使用。下表说明了最典型的使用模式：

上表说明了就每种规则类型的功能而言最合理的组合。其他用法当然也是可能的。例如，将序列规则或推理规则替换为无状态事件处理，可提供与最简单的事件相关规则等效的功能，但会失去将规则平稳地过渡到真正的多事件相关的功能。又如，您可以将推理规则应用到有状态事件处理，以对消息序列进行有关推断。应用程序要求和工具功能将决定每种情况下的最佳选择。

结束语

本文简要总结了三种普通规则类别，并说明它们如何与 SOA 集成——不用受以下两方面的限制：

• 规则是无状态的，还是有状态的。
• 调用样式是同步请求响应还是基于异步消息。

此处描述的集成方法将规则作为第一类服务组件类型对待，是与传统传统 Java 代码、业务流程和状态机属于同一种类型的技术。对于服务客户机的开发人员，这意味着可以像其他服务一样调用规则，而没有特殊的API 注意事项。对于总体解决方案开发人员，这就意味着可以将规则和其他实现类型混合使用，为总体解决方案中的每个组件应用最为恰当的技术。