业务策略并不是静态的，它们经常变更，且其关联的业务流程也会随之变更。正是由于这些变更，故而有必要在实现和修改业务流程时保持灵活性，从而在激烈的竞争中赢得一席之地。业务规则引擎可以实现所需的这种灵活性。

　　本文将准工业标准ILOG Jrules与BEA WebLogic Platform 8.1内的基于XML的规则引擎进行了比较。文章还讨论了在将规则引擎集成到J2EE平台过程中Java Specification Request (JSR) 94所扮演的角色。因为业务规则在重要的真正业务流程中具有很高的复杂性，所以对诸如销售代表这样的非IT人员来说，拥有一个工具环境且能保证其有适当的 可用性是非常重要的。本文使用了一个基于银行的真正业务流程的应用程序作为原型进行讨论。

　　动机

　　更新业务流程的平均周期已经从1980年的84个月缩短到了现在的6个月，而且IT解决方案交付周期也从30个月缩短到了3个月（参见图1）。在银行 业也是这样。其中的核心元素包括银行业的工业化、消费者需求的更改、竞争的日趋激烈以及政府调控的影响。另外，银行的业务环境和操作流程也在不断变化。但 是，当试图使受影响的软件系统适应这些改变时，出现了很大的延迟。从技术的观点来看，有高度适应性和灵活性是很有必要的。但是因为银行拥有高度异构的系统 拓扑，其系统和接口（包含单片主机系统）的数量非常可观，所以要实现这一点很难。

图1. 1980年以来业务流程周期和IT解决方案交付周期的发展

　　面向服务的架构(SOA)能提供调整业务流程和技术实现过程中所需的灵活性。此处对带有封装的功能的服务进行了定义，这些服务通过标准化的接口和协议 （如SOAP、WSDL、UDDI或J2EE连接器架构）访问各种系统（可能包括现存的系统）的功能。通过将服务封送或“编排”进可执行的业务流程 中，SOA可参考业务用户的观点对技术观点进行调整。目前，业务流程建模是基于所谓的“工作流管理系统”完成的。在建模过程中，会将业务流程映射为描述语 言（已标准化或正在标准化）。利用这一点，无需“硬编码”即可对业务流程进行调整，从而在运行时即时满足各种新要求。在《BIT》杂志的“银行业与信息技 术”（2004年第2卷第3期）中，讨论了此架构在银行中与各种工作流符号（如eEPK、UML活动图、BPEL、XPDL以及JPD）结合的一个实现。为了提高业务流程实现的抽象层次和灵活性，业务规则引擎可以部署在SOA框架内。这些规则引擎将业务流程内的决策从用编程语言完成的实际实现隔离开来。

　　业务规则与企业平台

　　在分析例子之前，有必要了解一下“业务规则”这个术语的含义以及此领域已有的标准。

　　业务规则

　　对于银行而言，管理机构、竞争对手、客户和整个市场情况不断带来各种变更，必须将这些变更作为业务规则。业务规则专家组 (BRG) 规定了业务规则的两个定义。第一个定义与业务观点相关，而第二个定义与IT相关：

　　“从业务的角度看，业务规则是一种原则，包含在特定活动或范围内关于指导、操作、实践或过程的行为规范。”

　　“从信息系统的角度看，业务规则是一个定义或限制业务某些方面的声明。业务规则旨在用于断言业务结构，或者控制或影响业务行为。”

　　运行时，规则引擎 必须对这些业务规则进行解释。可以将规则引擎理解为一种高性能的专用解释程序，其中包含if-then命令，可根据预先定义的规则对转换的值和对象进行分 析，然后返回修改后的值和对象，或直接执行操作。因此，大多数规则引擎使用“Rete” 算法，并支持演绎和归纳。

　　为了弥合业务观点和IT观点间的差距，就产生了对业务规则管理系统（BRMS）的需求。在BRMS中，会将公司使用的策略和过程进行结合，以管理业务规则的整个生命周期。因此，受影响的部门和非IT人员必须能够实时地修改IT基础架构，以适应一般条件和策略。

　　企业平台

　　企业平台（EP）可以看作SOA集成开发与运行时环境，这个环境涵盖了全公司范围的IT基础架构。此类平台的功能分布在三个层次：门户层、集成层和应用程序服务器层。门户层实现所有相关的信息和应用程序“单点访问”，保证真正单点实现客户、业务合作伙伴及员工访问。门户和有关资源的访问权由用户角色决定，以方便内容管理和实现个性化。集成层提供所有需要的服务，用于连接应用程序、业务流程和业务合作伙伴，以及在各种应用程序间进行数据集成和数据转换。

　　应用程序服务器层是企业平台的基础。应用程序服务器必须满足与（全局）事务的实现、管理和协调有关的所有要求，并提供高性能、高可用性和可伸缩性。

　　标准

　　广泛使用异构计算机系统，则意味着要采用标准，以达到必要的互操作水平。通常将互操作性理解为通信和协作的能力，可允许一个系统内的应用程序访问另一个系统内的数据或程序。使用标准的另一个目的是定义通用接口，以支持对互操作进行编程。

　　Java Specification Request (JSR) 94描述了软件工程师如何通过API将规则引擎集成到应用程序中，以及规则引擎供应商必须如何实现此类API。

　　不过，JSR 94没有提供描述业务规则的定义。JSR 94的目标是在不确定规则引擎供应商的情况下帮助把规则引擎集成到Java 应用程序中。JSR 94没有为任何类型的业务规则（如，基于XML的、基于统一数据的或基于对象模型的）指定描述语言。

　　规则集的实验性实现

　　现在把我们的注意力转向规则集的一个实验。我们将首先研究实验本身，然后再分析其在WebLogic Portal 8.1和ILOG Jrules中的实现。

　　场景

　　我们的实验解决两个问题。首先是采用“push 概念”的方式进行面向事件的客户处理，即根据其在EP门户内的需求主动处理客户。在面向事件的客户处理的上下文中，会利用基于用户给定的事件的业务规则，向已登录的用户显示个性化的内容。此类规则与以下所示类似：如果用户具有影响信用额度的“change of house”事件，而此事件尚未发生，则将向年满18岁或18岁以上的用户显示一个信用额度启事。该规则转换为ECAA符号（Event, Condition, Action, Alternative Action）如下所示：

ON	Change of house
IF	Customer credit-worthy AND above 18 AND not yet addressed
DO	Show credit advertisement
ELSE	—

　　其次，是在集成层内将规则引擎（各个业务规则）集成到业务流程的建模和运行库中。这是基于在线贷款业务流程实现的，此流程中具有自动信用确定功能和后台办公流程（在此处通过规则引擎进行决策）。我们的目标是在WebLogic Platform 8.1和ILOG JRules中实现所有这些问题。

　　利用BEA WebLogic 8.1 Service Pack 3进行实现

　　门户规则服务属于Weblogic Portal 8.1，用于在门户应用程序中实现个性化。它的实现需要借助不同组件： user segments、campaigns、content selectors以及Java Server Pages (JSP)内的个性化标签。

　　WebLogic Workshop 8.1具有合适的用户界面，利用此界面，可以在很高的抽象层次上更改这些组件。更重要的是，2004年发布的Service Pack 3能提供对附加组件的API访问，可直接访问基础规则引擎。这就是规则控件和“RulesManager” Enterprise JavaBean (EJB)。
WebLogic Portal 8.1规则包含称为规则集的XML文档。规则集的基本设置如下所示：

以下是引用片段： <ruleset>     <rule>         <condition>             Left Hand Side expression: Event (ON) and Condition (IF)         </condition>         <action>             Right Hand Side expression: Action (DO)         </action>     </rule></ruleset>

　　所有的规则都以ruleset元素内的rule元素的形式出现。此处映射左边(LHS)表达式，即Event (ON) and Condition (IF)。单独的元素是condition，在此元素内可以将条件与逻辑运算符链接。如果LHS为true，则将执行RHS（位于action元素内）的 Action (DO)。也可以在工作内存中对转换过的对象进行操作，或在其中创建新对象。不过，可能对象的列表（类型映射）仅限于小部分的类型。可以从WebLogic Platform 8.1的所有主要组件访问规则引擎，特别是集成层和门户层。由于规则引擎的对象类型数据有限，故而不可能实现在线贷款流程。因此必须将ILOG的规则引擎作为插件安装。

　　利用ILOG JRules 4.6进行实现

　　ILOG JRules 4.6是一套完整的BRMS，可以将其视为目前业务规则领域的行业标准。图2演示了如何将BRMS集成到Java 2 Enterprise Edition (J2EE)架构中。

图2. ILOG Jrules应用示例

　　图2摘自ILOG JRules 4.6白皮书。在JRules 4.6中可以使用全部应用程序对象模型，包括所有XML架构。Java和XML对象被组合为一个业务对象模型 (BOM)。利用BOM，可以将对象及其方法转换为自然语言的短语。因此，例如将对象Customer分配给短语“the customer”，将方法getAge分配给“the age of”。则抽象为自然语言的示例规则如下所示：

　　If the age of the customer is greater than 18 And … Then …

　　其中，粗体部分显示的是Rule Builder的既定元素，下划线部分显示的是BOM中的翻译，而斜体部分显示的是Rule Builder内的用户输入。
也可以采用规则集的方式组织这些规则。对象（Java 和 XML）加载到内存中后，就可以根据这些规则集进行运行。然后规则可以操纵或创建任何的对象。规则集和BOM保存在规则库中。因此，规则管理程序和管理员 可以根据其角色对规则进行访问、更新和部署，从而涵盖业务规则的整个生命周期（创建、部署、更新、删除）。

　　比较

　　WebLogic Portal 8.1提供了业务规则功能，但到目前为止，此功能只是用于WebLogic Platform 8.1内的活动管理和用户分段。Service Pack 3 通过提供API增强了规则引擎的功能。不过，其使用仍然仅限于进行个性化。ILOG JRules 4.6具有无限制的规则引擎，是一套完整的BRMS。

　　实现的结果表明WebLogic Portal 8.1的规则功能适用于较为简单的个性化和活动管理任务。创建和更新活动和用户分段已集成到WebLogic Workshop 8.1 IDE中，能在高抽象层次执行这些任务，且只能由具有适当权限的人员执行此类任务。不过，只能在WebLogic Platform 8.1环境中部署规则引擎，不能在任何其他供应商的平台上使用。

　　对于更复杂的个性化规则（通过结合AND和OR语句），可以使用规则服务定义XML格式的规则集。不过，必须在本机XML中创建和编辑规则。XML编 辑器还不足以涵盖相应的抽象层次，而且，相对于Java代码映射而言，具有多于三个条件的规则和包含两个以上规则的规则集都更加复杂化，更加容易混淆。

　　ILOG JRules 4.6本身就是一个灵活的BRMS，涵盖了业务规则的整个生命周期。ILOG JRules 4.6内的规则引擎是J2EE应用程序，可以部署到任何J2EE项目。另外，ILOG能轻松集成到IDE环境中，可以利用Java控件调用规则引擎。对于 较大规模的项目来说，集成和使用ILOG JRules 4.6一类的规则管理系统是可能的，也是值得这样做的。最后，结果表明，对于面向事件的客户处理和银行业务流程工业化二者的实现而言，ILOG JRules 4.6这样的BRMS是绝对必不可少的。

　　结束语

　　如其他行业早期一样，银行正面临将推动该行业进一步发展的结构变更。在这种情况下，银行业关心的主要问题是业务的划分、全球跨行业务往来，技术集成以及持续的数字化进程。为了应对即将来临的变更，业务流程（从技术观点出发）必须不断灵活且迅速地处理好新的挑战。解决此问题的可能方法之一就是使用EP和EAI。为了让相关部门获得更强的业务处理能力，必须进一步将业务逻辑从IT和实现端分离。利用业务规则和BRMS可以做到这一点。ILOG等BRMS可以轻松与BEA WebLogic Platform和WebLogic Workshop IDE实现集成。