使用规则引擎可以通过降低实现复杂业务逻辑的组件的复杂性,降低应用程序的维护和可扩展性成本。这篇文章展示如何使用VisualRules规则引擎让 Java™ 应用程序更适应变化。VisualRules有一个本地规则表达式语言和一个规则编辑器插件,使 VisualRules的应用更加简单快捷
要求施加在当今软件产品上的大多数复杂性是行为和功能方面的,从而导致组件实现具有复杂的业务逻辑。实现 J2EE 或 J2SE 应用程序中业务逻辑最常见的方法是编写 Java 代码来实现需求文档的规则和逻辑。在大多数情况下,该代码的错综复杂性使得维护和更新应用程序的业务逻辑成为一项令人畏惧的任务,甚至对于经验丰富的开发人员来说也是如此。任何更改,不管多么简单,仍然会产生重编译和重部署成本。
规则引擎试图解决(或者至少降低)应用程序业务逻辑的开发和维护中固有的问题和困难。可以将规则引擎看作实现复杂业务逻辑的框架。大多数规则引擎允许您使用声明性编程来表达对于某些给定信息或知识有效的结果。您可以专注于已知为真的事实及其结果,也就是应用程序的业务逻辑。
有多个规则引擎可供使用,其中包括商业和开放源码选择。商业规则引擎通常允许使用专用的类似英语的语言来表达规则。其他规则引擎允许使用脚本语言(比如 Groovy 或 Python)编写规则。本文为您介绍 VisualRules规则引擎,并使用示例程序帮助您理解如何使用 VisualRules作为 Java 应用程序中业务逻辑层的一部分。
VisualRules版本及特点描述
VisualRules是用 Java 语言编写的商业规则引擎。VisualRules允许使用声明方式表达业务逻辑。可以使用独有的本地语言编写规则,从而便于学习和理解。并且,还可以将 Java 代码直接嵌入到规则文件中,这令 VisualRules的学习更加吸引人。VisualRules还具有其他优点:
- 非常健全的技术支持
- 易用
- 快速的执行速度
- 规则编译为Java代码,跨平台
- 超过10年的专注研发投入
- 商业化的售后服务,使产生问题得到更好的处理
在编写本文之际,VisualRules规则引擎的最新版本是 4.0.7。这是一个更好的版本,它加入更多的功能和更简单的使用。例如,用于远程规则的部署和管理。
本文展示如何使用VisualRules作为示例 Java 应用程序中业务逻辑层的一部分。
设置虚拟场景
下列假设为应用程序解决的虚构问题设置了场景:
- 名为 XYZ 的公司构建两种类型的计算机机器:Type1 和 Type2。机器类型按其架构定义。
- XYZ 计算机可以提供多种功能。当前定义了四种功能:DDNS Server、DNS Server、Gateway 和 Router。
- 在发运每台机器之前,XYZ 在其上执行多个测试。
- 在每台机器上执行的测试取决于每台机器的类型和功能。目前,定义了五种测试:Test1、Test2、Test3、Test4 和 Test5。
- 当将测试分配给一台计算机时,也将测试到期日期分配给该机器。分配给计算机的测试不能晚于该到期日期执行。到期日期值取决于分配给机器的测试。
- XYZ 使用可以确定机器类型和功能的内部开发的软件应用程序,自动化了执行测试时的大部分过程。然后,基于这些属性,应用程序确定要执行的测试及其到期日期。
- 目前,为计算机分配测试和测试到期日期的逻辑是该应用程序的已编译代码的一部分。包含该逻辑的组件用 Java 语言编写。
- 分配测试和到期日期的逻辑一个月更改多次。当开发人员需要使用 Java 代码实现该逻辑时,必须经历一个冗长乏味的过程。
因为在对为计算机分配测试和到期日期的逻辑进行更改时,公司会发生高额成本,所以XYZ 主管已经要求软件工程师寻找一种灵活的方法,用最少的代价将对业务规则的更改 “推” 至生产环境。于是VisualRules走上舞台了。工程师决定,如果它们使用规则引擎来表达确定哪些测试应该执行的规则,则可以节省更多时间和精力。他们将只需要更改规则文件的内容,然后在生产环境中替换该文件。对于他们来说,这比更改已编译代码并在将已编译代码部署到生产环境中时进行由组织强制的冗长过程要简单省时得多。
目前,在为机器分配测试和到期日期时必须遵循以下业务规则:
- 如果计算机是 Type1,则只能在其上执行 Test1、Test2 和 Test5。
- 如果计算机是 Type2 且其中一个功能为 DNS Server,则应执行 Test4 和 Test5。
- 如果计算机是 Type2 且其中一个功能为 DDNS Server,则应执行 Test2 和 Test3。
- 如果计算机是 Type2 且其中一个功能为 Gateway,则应执行 Test3 和 Test4。
- 如果计算机是 Type2 且其中一个功能为 Router,则应执行 Test1 和 Test3。
- 如果 Test1 是要在计算机上执行的测试之一,则测试到期日期距离机器的创建日期 3 天。该规则优先于测试到期日期的所有下列规则。
- 如果 Test2 是要在计算机上执行的测试之一,则测试到期日期距离机器的创建日期 7 天。该规则优先于测试到期日期的所有下列规则。
- 如果 Test3 是要在计算机上执行的测试之一,则测试到期日期距离机器的创建日期 10 天。该规则优先于测试到期日期的所有下列规则。
- 如果 Test4 是要在计算机上执行的测试之一,则测试到期日期距离机器的创建日期 12 天。该规则优先于测试到期日期的所有下列规则。
- 如果 Test5 是要在计算机上执行的测试之一,则测试到期日期距离机器的创建日期 14 天。
捕获为机器分配测试和测试到期日期的上述业务规则的当前 Java 代码如清单 1 所示:
使用Java代码实现业务逻辑
使用 if-else 语句实现业务规则逻辑
Machine machine = ...
// Assign tests
Collections.sort(machine.getFunctions());
int index;
if (machine.getType().equals("Type1")) {
Test test1 = ...
Test test2 = ...
Test test5 = ...
machine.getTests().add(test1);
machine.getTests().add(test2);
machine.getTests().add(test5);
} else if (machine.getType().equals("Type2")){
index = Collections.binarySearch(machine.getFunctions(), "Router");
if (index >= 0) {
Test test1 = ...
Test test3 = ...
machine.getTests().add(test1);
machine.getTests().add(test3);
}
index = Collections.binarySearch(machine.getFunctions(), "Gateway");
if (index >= 0) {
Test test4 = ...
Test test3 = ...
machine.getTests().add(test4);
machine.getTests().add(test3);
}
...
}
// Assign tests due date
Collections.sort(machine.getTests(), new TestComparator());
...
Test test1 = ...
index = Collections.binarySearch(machine.getTests(), test1);
if (index >= 0) {
// Set due date to 3 days after Machine was created
Timestamp creationTs = machine.getCreationTs();
machine.setTestsDueTime(...);
return;
}
index = Collections.binarySearch(machine.getTests(), test2);
if (index >= 0) {
// Set due date to 7 days after Machine was created
Timestamp creationTs = machine.getCreationTs();
machine.setTestsDueTime(...);
return;
}
...
上述所示代码不是太复杂,但也并不简单。如果要对其进行更改,需要十分小心。一堆互相缠绕的 if-else 语句正试图捕获已经为应用程序标识的业务逻辑。如果您对业务规则不甚了解,就无法一眼看出代码的意图。
使用VisualRules规则配置的方式表示上述定义的业务规则。它包含以下内容:
- VisualRules规则配置器。
- JDk1.6
- Tomcat5
- VisualRules核心引擎
2.创建规则工程
打开规则配置器,点文件菜单,选择新建规则工程,工程名为:机器功能测试,存放路径可自由选择
规则工程创建完成后,我们再为当前场景创建一个规则包,在规则工程上面点右键,选择:新建规则包,并命名为test。
在规则包创建完成后,我们再把规则对象添加到该规则包的对象库中
对象添加完成后,我们就可以来配置业务规则了
如上图所示:我们按照测试项目的优先级来配置规则,一共有5个测试项目
在规则配置完成以后,按照业务逻辑可以在规则中进行单元测试,例如:我们设定计算机为:type2,测试功能为:DDNS Server,机器创建日期为:2013-05-14,那么在规则执行完成后,我们可以得到如下的测试结果
从测试的结果可以看出:
针对type2这台机器我们需要进行2个测试
1:在2013-05-07对它进行test2测试
2:在2013-05-04对它进行test3测试
如上面我们看到的规则配置,VisualRules规则文件可以包含一个或多个规则集或者规则。每个规则集或者规则中又可以包含一条或多条规则。
使用规则引擎可以显著降低实现 Java 应用程序中业务规则逻辑的组件的复杂性。使用规则引擎以声明方法表达规则的应用程序比其他应用程序更容易维护和扩展。正如您所看到的,VisualRules是一种功能强大的灵活的规则引擎产品。使用VisualRules的特性和能力,您可以灵活的配置应用程序的复杂业务逻辑。VisualRules采用中文化的规则配置方式使得学习和使用VisualRules规则引擎产品对业务人员来说变得相当容易。
相关推荐
使用规则引擎可以通过降低实现复杂业务逻辑的组件的复杂性,降低应用程序的维护和可扩展性成本。这篇更新的文章展示如何使用开源的 Drools 规则引擎让 Java™ 应用程序更适应变化。Drools 项目引入了一个新的本地...
规则引擎在业务逻辑层中应用的研究,经典资料,欢迎研究规则引擎的朋友一起讨论
这是一篇关于规则引擎在业务逻辑层中应用的硕士学位论文,比较详细的描述了如何在业务逻辑层中使用规则引擎。
Drool规则引擎在实现业务逻辑中的应用.pdf
使用WEBLOGICPORTAL规则引擎中实现动态业务逻辑.docx
规则引擎是一种嵌套在应用程序中的组件,它实现了将业务规则从应用程序代码中分离出来。规则引擎使用特定的语法编写业务规则,规则引擎可以接受数据输入、解释业务规划、...什么是规则:所有业务逻辑都可以看做是规则。
一个业务需求(一般程序或一个接口)可以抽象成为: 按一定业务逻辑规则处理数据,然后返回数据。一个人可以用成百上千个属性组成,由这些属性衍生出新的属性(例如,好人/坏人) 返回一个业务结果(0..多个属性值)一般接口: ...
在每个公司的系统中,总有一些拥有复杂业务逻辑的系统,这些系统承载着核心业务逻辑,几乎每个需求都和这些核心业务有关,这些核心业务业务逻辑冗长,涉及内部逻辑运算,缓存操作,持久化操作,外部资源调取,内部...
ILOG全球最大的业务规则管理厂商 ILOG是国际规则引擎规范――JSR 94的主要制定者 ...将业务逻辑以业务规则的形式提取到应用程序外 将实施业务策略的责任从开发人员转移到业务分析人员和策略管理人员
利用规则引擎分离业务逻辑规则实现了企业业务逻辑规则的灵活可配置;采用实时预警信息实现了错误信息可追踪;通过分角色多视图定制KPI的方式保护了企业关键业务信息。整个平台具有实时性、可扩展性、可靠性和安全性...
规则引擎技术为管理多变的业务逻辑提供了一种解决方案。规则引擎既可以管理应用层的业务逻辑又可以使表示层的页面流程可订制。这就给软件架构师设计大型信息系统提供了一项新的选择。
【客户规则池】在客户规则池功能中,CKRule提供了各种各样的接口或控件,供业务系统使用,但CKRule对用户是透明的,用户始终是在使用业务系统中。 【口语式编辑器】口语式编辑器可以在CKRule内部及客户规则池中被...
规则引擎将您的业务逻辑与应用程序逻辑分开,从而无需更改代码甚至重新部署应用程序即可更改这些规则。 jsRules使用简单易懂的JSON实现,可以通过网页,移动应用程序甚至手动操作轻松地对其进行编辑...将这些规则...
规则引擎是一种嵌入在 程序中的组件,它的任务是把当前提交给引擎的 数据对象与加载在引擎中的业务规则进行测试和比对,激活那些符合当前数据状态下的业务规则,根据业务规则中声明的执行逻辑,触发应用程序中 ...
3 为何要使用规则引擎? 6 3.1 声明式编程 6 3.2逻辑与数据分离 6 3.3 速度及可测量性 6 3.4 知识集中化 6 3.5 工具集成 6 3.6 解释机制 6 3.7易懂的规则 7 4 何时应当使用规则引擎? 7 5 如何使用规则引擎? 7 6 ...
轻量,快速,稳定,可编排的组件式规则引擎/流程引擎。 拥有全新设计的DSL规则表达式。 组件复用,同步/异步编排,动态编排,支持超多语言脚本,复杂嵌套规则,热部署,平滑刷新规则等等功能,让你加快开发效率!
Java规则引擎是一种嵌入在Java程序中的组件,它的任务是把当前提交给引擎的Java数据对象与加载在引擎中的业务规则进行测试和比对,激活那些符合当前数据状态下的业务规则,根据业务规则中声明的执行逻辑,触发应用...
一个常见的讨论涉及将业务逻辑(即规则)封装在对象或服务中。 服务对于由业务流程精心安排的决策和合规性是有意义的。 如果需求,法规,策略或规则跨越模型中的许多类并且在流程中包含许多任务,则强烈建议使用...