WebSphere ILOG JRules BRMS V7.1 安装教程

提供如何在受支持的应用程序服务器上安装 IBM® WebSphere® ILOG JRules 模块的概述。要在 Java EE 平台上使用任意 JRules 模块,需要在您的应用程序服务器上安装一组组件。请仔细阅读这个部分的主题,以及根安装目录 <InstallDir> 中的产品 readme.html 文件,以了解如何及何时运行 JRules 安装程序。

本章中

JRules 产品及其安装

介绍包含的 JRules 产品及其安装顺序。

Java EE 附件及其安装

描述如何准备要安装 Rule Team Server 、Rule Execution Server 和 Decision Validation Services 的应用程序服务器。

目标读者

介绍了文档的目标读者。

安全性

提供了归档部署和安装的基本介绍。

通信协议

描述与 Rule Execution Server 的通信协议。

性能调整指导

提供了一些一般建议以帮助提高性能。性能调整的目的在于降低应用程序服务器处理申请所花费的时间和资源。性能调整让您的应用程序服务器能够用更少的时间完成更多的任务。

JRules 产品及其安装

ILOG JRules 被分成了几个产品。每个产品都有一个分开的安装程序,这个安装程序包括了一个单个的模块或安装一个或两个模块的选项。这些产品为:

IBM WebSphere ILOG JRules IBM WebSphere ILOG JRules 产品,也被叫做 JRules Core,包括安装以下模块的选项:

Rule Studio 针对开发人员、建模人员和架构设计师的基于业务规则的应用程序开发工具。
Rule Execution Server 嵌入 JRules 引擎的受控业务规则执行平台。

IBM WebSphere ILOG Rule Team Server 这个产品包含了以下模块:

Rule Team Server 针对策略管理员的业务规则管理工具。

IBM WebSphere ILOG Decision Validation Services 这个产品包含了以下模块:

Decision Validation Services 针对开发人员、质量保证团队和业务用户的测试和模拟解决方案创建工具,用于验证和审计规则集的正确性及有效性。

IBM WebSphere ILOG Rule Solutions for Office 这个产品包含了以下模块:

Rule Solutions for Office Rule Solutions for Office 为 Microsoft Word 2007 和 Microsoft Excel 2007 提供装入项,使您能够用 Microsoft Office 2007 创建和管理业务规则。

如果您想在同一台电脑上组合安装这些产品,您必须先安装 IBM WebSphere ILOG JRules。要安装 Decision Validation Services,您必须已经安装了 Rule Execution Server。
开发环境的典型安装顺序为:

JRules Core (Rule Studio + Rule Execution Server)
Rule Team Server

Decision Validation Services

要安装一个 Java EE 附件,您必须已经安装了来自 JRules Core 的一个模块,以及您想要在 Java EE 平台使用的模块。然后您可以安装指示安装 Java EE 附件至支持的应用程序服务器。
编写环境的典型安装顺序为:

JRules Core (Rule Studio + Rule Execution Server)
Rule Team Server
Rule Team Server Java EE 附件至支持的应用程序服务器

Rule Solutions for Office

测试环境的典型安装顺序为:

JRules Core (Rule Studio + Rule Execution Server)
Rule Team Server
Decision Validation Services
Rule Execution Server Java EE 附件至支持的应用程序服务器
Rule Team Server Java EE 附件至支持的应用程序服务器

Decision Validation Services Java EE 附件至支持的应用程序服务器

集成、监控和审计环境的典型安装顺序为:

JRules Core (Rule Studio + Rule Execution Server)
Decision Validation Services
Rule Execution Server Java EE 附件至支持的应用程序服务器

Decision Validation Services Java EE 附件至支持的应用程序服务器

除了在 Java EE 平台上安装这些模块外,您还可在 WebSphere Community Edition 上安装 Rule Execution Server、Rule Team Server 和 Decision Validation Services,也可在 Java SE 上安装 Rule Execution Server。有关详细信息,请参阅 在 WebSphere Community Edition 上安装 JRules 模块 和 在 Java SE 上安装 Rule Execution Server。
注释
在执行任何安装任务之前,请检查文件 readme.html(位于根安装目录 <InstallDir> 中)中列出的受支持硬件和软件信息。

Java EE 附件及其安装

在安装一个 Java EE 附件前,请仔细阅读这个章节和根安装目录中的产品 readme.html 文件。
Java EE 附件安装程序为以下模块绑定了部署归档:

Rule Execution Server
Rule Team Server

Decision Validation Services

安装程序检查是否已安装模块,并仅在安装电脑中找到模块的情况下,才会添加部署归档。要了解更多详情,请参阅 Java EE 附件的 install-readme.html文件。
根据您安装的 JRules 产品,然后您可以在受支持的 Java EE 应用程序服务器上安装 Rule Team Server、Rule Execution Server 和 Decision Validation Services。
有关详细信息,请参阅 在 Java EE 应用程序服务器上安装 JRules 模块。

要在一个应用程序上安装一个模块:

下载特定安装软件包。
打开打包的安装文档,并按照该模块在特定应用程序上的安装说明执行操作。
安装文档注释同时以 HTML 和 PDF 格式提供。
这包括:

创建数据源

配置必要安全性

还需要为用户集提供访问信息:登录、密码、主机名、JNDI 名称等等。
如果要在几个服务器实例上安装模块,则必须阅读相关服务器文档中的集群部署部分。

一个 Java EE 附件的安装包括:

在服务器上部署一个归档(或一组归档)。
执行一系列配置步骤:

配置数据库
上载消息文件
上载角色

设置持久性语言环境

添加配置参数

注释
您可以通过不同的方法部署应用程序服务器安装程序中随附的归档文件 (EAR,WAR,或 RAR)。要完全了解不同选项,请参考应用程序服务器文档。

您也可以自定义 Rule Team Server 的行为。关于更多信息,请参阅定制 Rule Team Server。

通信协议

与 Rule Execution Server 的通信支持 HTTP 或 HTTPS 通信协议。与 Rule Execution Server 的通信可以来自 Rule Team Server 或指向 Decision Validation Services。
可以用两种方式定制通信:

以安全方式支持非信任证书。

支持定制协议。

安全方式以安全方式与 Rule Execution Server 通信时,无法使用缺省 JVM 不信任的演示证书来连接。如果尝试以此方式连接,那么您的应用程序服务器会产生 SSL 握手异常。
要允许通信使用非信任证书,请在应用程序服务器的启动脚本中添加以下 Java 系统属性:
-Dilog.rules.res.allowSelfSignedCertificate=true

定制协议可以通过使用以下系统属性来为特定协议定制协议工厂:

custom.protocol.factory – 协议工厂的标准名称。
custom.protocol.scheme – 为其定制协议工厂的协议名称。

custom.protocol.defaultPort – 在 URL 中没有指定端口时,用于该协议的缺省端口。

您必须启动 JVM(其启动与这些系统属性的 HTTP 通信)以及类路径中协议工厂类 org.apache.commons.httpclient.protocol.ProtocolSocketFactory 的实施。
如果满足了以下两个条件,那么将实例化并注册在 custom.protocol.factory 中指定的协议工厂:

实例化了 HTTP 客户机。

URL 中用于通信的协议与属性 custom.protocol.scheme 的值相同。

以下显示如何以系统属性启动应用程序服务器:
-Dcustom.protocol.factory=com.ilog.MyProtocolFactory -Dcustom.protocol.scheme=https -Dcustom.protocol.defaultPort=443

ILOG JRules 规则集应用与客户端的集成

简介

通常情况下,如果企业的业务策略在应用程序中实现的时候,随着业务的发展和策略的不断变化,这种实现方式就会变得越来越复杂、缺少灵活性而造成无法做出快速的反应。而业务规则管理系统 (Business Rule Management System ,BRMS) 的出现,对于应用程序的开发者和业务用户来讲,则提供一种对业务策略的管理更加有效的解决方案。应用业务规则管理系统,开发者和架构师可以在独立于应用逻辑之外去管理业务逻辑,允许业务用户独立于企业的 IT 部门去管理业务策略。与此同时,像 SOA 这样的 IT 架构的出现,使业务逻辑可以在业务规则管理系统中封装成供应用程序和业务流程调用的规则服务。IBM ILOG JRules 就是一个很好的允许业务人员和 IT 开发人员使用的业务规则管理系统,它可以提高业务发展,使业务策略自动化。

在对规则集调用的过程中,根据 XOM 和设计需求,可以采用 POJO、EJB、JMS、Web 服务等调用方式。本文结合场景实例提出了一种基于 Web 服务的调用实现方式,同时,在 ILOG JRules V7.0 的使用指南文档中,也介绍了一种用 JAX-WS 2.1.1 将规则集部署为决策服务的调用方式,如感兴趣,请参见指南 Integrating into an enterprise application部分。本文给出的方案中选用 Axis 创建调用规则集的 Web 服务,调用过程效率高、响应快,编程更加方便、灵活,且能满足 SOA 的架构要求。

本文应用 ILOG JRules 架构的主要部分及特性

ILOG JRules V7.0 通过一组创新模块来创建、管理和部署业务规则,从而实现完善的性能。

ILOG JRules Rule Studio:适用于规则应用程序的集成开发环境 (IDE) 。Rule Studio 直接针对 IDE 的 Eclipse 系列,其中包括 Eclipse IDE。Rule Studio 支持对 ILOG JRules Rule Execution Server 进行规则集调试和部署,还可以通过 Rule Team Server 实现业务规则的编写者之间的协作。

ILOG JRules Execution Server:是一个稳定的与 J2SE 和 J2EE 兼容的可管理的规则执行环境,运行在 Web 服务器或应用程序服务器上。它将规则引擎打包作为一个 Java Connector Architecture(J2C) 资源适配器。Rule Execution Server 包括一个 Web 管理控制台,可以对部署在上面的规则集进行有效的版本控制和管理。Rule Execution Server 与 Rule Studio 和 Rule Team Server 完全集成,可以同时支持开发人员和策略管理者的业务规则部署。

具有下列特性:

易用性好:

在集成了 Eclipse 的环境中工作,通过自动更正和”智能规则”轻松快速地使用与自然语言一致的规则语言编写规则;

使用静态规则分析检测冲突和冗余;

规则流的创建可以进行可视化的组装和拆分,并满足所设计的粒度要求;

可独立于应用逻辑对业务规则应用程序进行快速部署和调试;

管理方便:

通过基于权限的规则访问向业务人员提供控制权的同时,维护应用程序完整性;

通过测试、共同调试和重构进行反复开发;

使用单一界面和规则库管理代码和规则;

同时应对多个发布周期,在准备下一个产品发布的同时维护仍在进行的产品发布;

可控性:

通过受控的执行过程来报告和监控规则;

查看有关所有规则变更和部署地完整历史记录;

业务规则应用场景描述

在保险或金融等行业解决方案中,如员工的薪水计算或员工的升迁降职处理,都会根据员工的

各项指标和企业管理条例来进行相应的计算和处理,这个过程中就要涉及到大量的业务策略或规则。本文将以员工薪水计算功能中的业务规则应用开发与集成场景为举例,不同的规则决定

不同的薪水计算方式,但由于实际需求中,这些规则又是灵活多变的,因此,把薪水计算的规则提取出来并应用 ILOG JRules 使其在不影响应用程序代码性能的前提下进行独立地快速开发、调试、部署和管理,并以一种 Web 服务的调用方式对其与任意客户端进行集成,是一种非常好的解决方案。

执行对象模型 (XOM) 的设计

执行对象模型是一种在规则被执行的过程中要基于的一种对象模型。业务规则通过业务对象模型 (BOM) 中的词汇和术语来编写,之后被 ILOG JRules 编译成 ILOG Rule Language(IRL) 语言,在规则的运行状态中,规则引擎可以访问 XOM 中的属性和方法。

在 JRules 中,执行模型的实现方式主要可分为二种,一种是 Java Classes,即 JAVA XOM;另一种是 XML Schema,即 Dynamic Classes。规则引擎访问 XOM 时依据 XOM 的实现方式而采用不同的访问方式。例如,若采用 JAVA XOM,则要将它打包到应用程序端中并随之一起部署,在运行的时候,应用程序的类加载器会使执行环境可以访问它。在不同的情况下,可以根据实际需求来选择 XOM 的设计和实现方式,但 Java 类的实现方式相比之下,更加易用,因为它不仅含有属性,而且类中定义的方法会给业务规则的设计和编写过程带来很大的方便和灵活性。因此,本文中设计 XOM 选择了 Java 类的实现方式,通过自动解析 Java 类,用它的方法和属性来创建业务对象模型 (Business Object Model)。然后就可以通过业务对象模型中所包含的词汇术语来编写规则。

清单 1 为执行对象模型的部分代码,即设计为一个 Java 类,其中类 Agent 的设计在本例中代表员工信息。该类也会定义为规则集的输入和输出参数,当它作为规则集的输入时,它的基本属性中包括了薪水计算规则用到的一些前提条件;在规则的执行过程中,它的一些属性会保存中间变量值;当计算规则执行结束后,它的一些属性值为代表薪水计算的各项结果并被保存,作为输出参数返回到客户端。此类中的方法的灵活之处在于它可以用来计算一些中间变量值或实现一些较为复杂的计算过程等,以提供给业务规则执行时调用 ( 与 XSD Schema 方式相比作用较明显 )。

清单 1. 设计执行对象模型部分代码示例

 

Public class Agent {

 

// 以下属性为计算的前提条件变量(部分)

privateDate onboardDate; // 入司日期

privateString rank; // 职级

private doubleperformanceAmount; // 业绩额

private booleanworkState; // 是否在职

privateString[][] rankHistory; // 职位和时间历史记录

privateDate computationDate; // 计算薪水的日期

. . . . . .

 

// 以下为薪水计算规则执行过程中所需的中间变量(部分)

public booleanqualified =false; // 是否有授予某项奖金资格

public intonboardYearNum = -1; // 入司年份

public intonboardMonthNum = -1; // 入司月

public intonboardDayNum = -1; // 入司日

. . . . . .

 

// 以下属性为保存计算结果变量

private doublestartupsSubsidy; // 创业津贴

private doublequarterAward; // 个人季度奖金

private double totalAmount; // 薪水总计额度

*设计方法*

// 计算月平均业绩额

public double computeMonthlyAmount(){

. . . . . .

}

Public double getXXX(){ … }

Public double setXXX(){ … }

. . . . . .

}

 

完成规则集开发、部署的其它主要步骤

在本例中完成以上工作之后和对规则集的调用之前,还需要依次完成下列主要步骤:

首先在 Rule Studio 中创建一个规则工程,在设计阶段导入 Java Excution Object Model,即 XOM。

然后通过工具解析导入的 XOM 自动创建业务对象模型 (Business Object Model),至此,我们可以看到用来编写业务规则的词汇和术语。

在接下来的业务规则的编写过程中,就可以定义规则分类包,并应用 ILOG JRules 支持的三种自然语言、决策表或决策树的方式直观地对规则进行灵活快速地编写。

定义规则集的输入和输出参数。

在规则流 (ruleflow) 的设计过程中,一个规则集只能定义一个主规则流 (main flow task 属性为 true),它包含规则集执行的入口和出口,但一个规则集可以支持多个子规则流 (main flow task 属性为 false),每一个子规则流又是由执行起点和终点、一条或多条业务规则、判断分支等共同组成,而一个主规则流又可以根据业务规则需要由多个子规则流组装而成。这样的规则流的设计粒度就可以达到我们所要求的粒度,可以对主规则流进行灵活的拆分和组装,非常灵活、方便快捷。

在完成了上述的工作以后,就可以在 Rule Studio 工具中自动创建将规则集打包的规则应用工程 RuleApp,并把它实时部署到 Rule Execution Server 上,之后就可以通过规则路径去调用 RuleApp 中的 Ruleset,同时,通过 Web 权限管理控制台就可以对其进行有效管理。

至此,在本例中已成功完成了业务规则集的开发和部署,也可以在 Rule Studio 中进行调试。

业务规则应用与客户端的集成实现

基于 Web 服务调用方式的业务规则应用与客户端的集成模型

调用过程如图 1 所示:

图 1. 客户端对 ILOG JRules 规则集调用集成模型

在本文给出的调用模型中,需要先将规则应用部署在运行在 Web 服务器中规则执行环境 Rule Execution Server 中。调用的实现过程中,主要先采用 POJO 会话方式对规则集进行本地调用,再将本地调用规则集的 Java 类利用 Axis 发布成 Web 服务,最后在应用程序客户端创建调用此规则服务的代码,即成功实现了以 Web 服务方式调用规则应用的目的,从而实现与客户端的良好集成,这种调用方式效率很高。由于先采用对规则集的本地调用,因此,需要将具有本地调用规则集功能的 Web 服务工程和规则执行环境 Rule Execution Server 部署在相同的 Web 服务器上。

在可管理的规则执行环境 Rule Execution Server 中,规则引擎由 Execution Unit (XU) 来控制,而 Execution Unit(XU) 是一个资源适配器,它能够管理规则引擎,装载规则集,以及在应用程序和规则引擎之间传递数据。XU 处理规则集执行的低层细节,如池和多线程处理,并能提供对资源的访问和管理热部署。应用服务器或应用程序客户机使用 XU 连接规则引擎。

创建调用规则集应用的 Web 服务工程

下面给出具有本地调用规则集功能的 Web 服务的工程目录结构,如图 2 所示:

图 2. 调用规则集的 WebService 工程文件目录结构图

在本例中,创建本地调用规则集的 Web 服务工程并将其命名为 IncomeService,从服务发布成功后的目录结构图中,可以清楚看到所需要和生成的各个主要文件。下面对一些重要的文件和代码进行给出示例和说明。

创建本地调用规则集的核心类

本例中调用规则集的核心类是一个 Java 类,例中名为:ComputeIncomeBean.java;它

获得来自于客户调用服务时的输入参数,在成功调用并执行薪水计算规则集后,获得保存有计算结果的参数 Agent,并将其作为服务的输出参数返回给客户端。

清单 2. 本地调用规则集的核心类源代码示例

 

public class ComputeIncomeBean {

public Agent computeAgentIncome(Agent agent){

String executionError = null;

String rulesetVersion = Messages.getString(“latest”);

IlrSessionFactory sessionFactory = null;

try {

// get a rulesession

if (sessionFactory == null) {

sessionFactory = new IlrJ2SESessionFactory();

}

// Create a session request object

IlrSessionRequest sessionRequest = sessionFactory.createRequest();

// rulesetPath=”/ComputeSalaryApp/2.0/ComputeSalary”

String rulesetPath = Messages.getString(“rulesetPath”);

if (!rulesetVersion.equalsIgnoreCase(Messages.getString(“latest”))) {

rulesetPath = rulesetPath + “/” + rulesetVersion;

}

sessionRequest.setRulesetPath(IlrPath.parsePath(rulesetPath));

// Enable trace to retrieve info on executed rules

sessionRequest.setTraceEnabled(true);

sessionRequest.getTraceFilter().setInfoAllFilters(true);

// Set the input parameters for the execution of the rules

Map<String,Object> inputParameters = sessionRequest.getInputParameters();

inputParameters.put(“agent”, agent);

IlrStatelessSession session = sessionFactory.createStatelessSession();

// execute and get the response for this request

IlrSessionResponse response = session.execute(sessionRequest);

IlrExecutionTrace sessionTrace = response.getRulesetExecutionTrace();

agent = (Agent) response.getOutputParameters().get(“agent”);

}

return agent;

}

}

 

使用 context.xml 配置数据源

在 META-INF 的目录下,创建一个 context.xml 文件,在该文件中添加配置数据源信息。Reloadable 属性如果为 true,则 tomcat 会自动检测应用程序的 /WEB-INF/lib 和 /WEB-INF/classes 目录的变化,自动装载新的应用程序,可以在不重起 tomcat 的情况下改变应用程序。name 表示指定的 JNDI 名称,必须为 jdbc/resdatasource,type 表示数据源类型,使用标准的 javax.sql.DataSource。

清单 3. context.xml 文件源代码

 

<?xml version=’1.0′ encoding=’utf-8′?>

<Context reloadable=”true” crossContext=”true”>

<Logger className=”org.apache.catalina.logger.FileLogger”

prefix=”IncomeService_log”

suffix=”.txt”

timestamp=”true”/>

<ResourceLink name=”jdbc/resdatasource”

global=”jdbc/resdatasource”

type=”javax.sql.DataSource”/>

</Context>

 

将调用规则集的核心类发布成 Web 服务

利用工具将类 ComputeIncomeBean.java 发布成 Web Services,并自动生成 Web 服务描述文件 ComputeIncomeBean.wsdl 和 Web 服务部署描述文件 deploy.wsdd。发布 Web 服务操作如图 3 所示:

图 3. 利用工具创建 Web 服务

创建或修改服务器端配置文件 server-config.wsdd

该文件记录了 axis 已发布的 Web 服务的描述信息。每当部署一个新的 Web 服务时,新服务的描述信息要加入到 server-config.wsdd 中。将 deploy.wsdd 文件中 <service> 标签中的内容(即发布的服务描述信息)拷贝添加到 erver-config.wsdd 文件中。清单 4 展示了拷贝部分的重要代码。

清单 4. server-config.wsdd 文件新增服务描述信息部分源代码示例

 

<service name=”ComputeIncomeBean” provider=”java:RPC” style=”wrapped” use=”literal”>

<parameter name=”wsdlTargetNamespace” value=”http://services”/>

<parameter name=”wsdlServiceElement” value=”ComputeIncomeBeanService”/>

<parameter name=”schemaQualified” value=”http://services,http://agentbom”/>

<parameter name=”wsdlServicePort” value=”ComputeIncomeBean”/>

<parameter name=”className” value=”services.ComputeIncomeBean”/>

<parameter name=”wsdlPortType” value=”ComputeIncomeBean”/>

<parameter name=”typeMappingVersion” value=”1.2″/>

<operation xmlns:operNS=”http://services”

xmlns:retNS=http://services xmlns:rtns=”http://agentbom” name=”computeAgentIncome”

qname=”operNS:computeAgentIncome” returnQName=”retNS:computeAgentIncomeReturn”

returnType=”rtns:Agent” soapAction=””>

<parameter xmlns:pns=”http://services” xmlns:tns=”http://agentbom”

qname=”pns:agent” type=”tns:Agent”/>

</operation>

<parameter name=”allowedMethods” value=”computeAgentIncome”/>

… …

<typeMapping xmlns:ns=”http://agentbom” qname=”ns:ExtensionProperty”

type=”java:agentbom.ExtensionProperty”

serializer=”org.apache.axis.encoding.ser.BeanSerializerFactory”

deserializer=”org.apache.axis.encoding.ser.BeanDeserializerFactory”

encodingStyle=””/>

… …

</service>

 

导入 Web 服务工程库要用到的重要 JAR 包

同时,要将 XOM 的 Java 类导出,agentbom.jar 文件包放到项目的 lib 库文件中,调用规则引擎的核心代码中要用到此类,并将其作为 Web 服务的参数。同时还要把调用规则引擎时主要用到的 jrules-res-execution.jar 包也放入库中。如图 4 所示

图 4. Web 服务工程库文件中要加入的重要 JAR 包

对本地调用规则集的 Web 服务进行部署

注意,由于服务中对规则集是采用本地调用的方式,因此 Web 服务要与规则应用即 (ComputeSalaryApp) 的运行环境部署在相同的 Web 服务器上。本例中的 Web 服务器采用的是 Tomcat。对 Web 服务工程项目进行导出 WAR 包文件部署在该服务器上如图 5 所示:

图 5. 导出 Web 服务工程 WAR 包到服务器上

部署成功后,可以看到 Web 服务器上部署的应用目录结构如下,如图 6 所示:

图 6. Web 服务成功部署后,服务器上文件结构视图

之后,点击 Start Sample Server 启动 Web 服务器,可以看到在此服务器上成功部署二项内容:

包含部署了业务规则应用 ComputeSalaryApp 的运行环境 (res.war)。

本地调用业务规则的 Web 服务 IncomeService。

创建调用 Web 服务的客户端代码

要想在应用程序客户端能够成功地去调用 Web 服务,还需要在客户端创建调用服务的代码。由于在服务成功发布后,我们已经获得了 Web 服务描述文件 ComputeIncomeBean.wsdl,因此,就可以利用工具通过服务描述文件自动生成调用代码。操作如图 7 和图 8 所示:

图 7. 用工具自动生成调用服务代码步骤一

图 8. 用工具自动生成调用服务代码步骤二

在客户端工程项目中,自动生成的调用服务的代码文件如图 9 所示:

图 9. 调用服务客户端代码文件

需要说明的是,工具根据 Web 服务描述文件自动生成的序列化对象 Agent.java 文件,它就代表着员工的信息,可直接作为我们调用服务的输入和返回参数进行使用,实际情况需对该类进行适当的属性设定和方法的修改,从而使它能更加符合作用为参数的要求。因此,可把上述这段调用业务规则服务的代码嵌入到任何客户端应用程序中。

对业务规则应用进行调用执行测试

最后,编写测试数据对其进行测试,结果如图 10 所示,结预期结果完全一致。

图 10. 调用薪水计算功能规则应用服务后,得到正确的测试结果

结束语

本文结合员工薪水计算业务规则应用场景实例,介绍了业务规则开发,部署和集成的主要实现过程。重点讨论 XOM 的设计和给出一种 Web 服务方式调用规则集的集成方案。通过本方案中测试后正确性结果,说明成功的实现了应用 ILOG Jrules 对业务规则地行独立地开发,调试、部署、管理和集成,以及满足 SOA 架构的松耦合的要求。