5_规则引擎项目开发手册及规范指导－ilog篇

5_规则引擎项目开发手册及规范指导－ilog篇内容摘要：

化等操作。 参考文档 JRules 自带帮助文档已经是很好的教材 ，因为 ilog 的应用还不是很广泛所以互联网上的资料也不是很多 ,但是有些论坛大家有问题可以去逛逛。 Ilog自带帮助文档 （部分中文） ： JRules653/doc/html/ 规则引擎项目开发手册及规范指导－ ILOG 篇 中科软科技股份有限公司 第 4 页 Ilog产品论坛 （英文） ： 规则引擎项目开发手册及规范指导－ ILOG 篇 中科软科技股份有限公司 第 5 页 3 需求整理与整体设计 也许 当您读到该章节的时候会产生疑问，为什么将需求拿过来讲。 因为 对于规则来讲，在了解用户的需求，抽取规则的过程就是在做规则的设计，规则并不是 用户的全部业务，规则只是业务中相对灵活多变的那部分，所以如果规则确定了那么规则的实现方式应该也就确定了，规则中使用的业务元素也就确定了 ，这样只需要简单的设计规划我们的规则工程就可 以启航了。 需求与 bom 设计  “词汇”的整理 在讨论需求的过程中，肯定会涉及到规则中使用的一些业务人员熟悉的 “术语”。 这些术语随着讨论的进行一定要整理出来，确定其含义并且对应有代码名称。 因为在编写规则的过程中虽然是操作的这些术语词汇，但实际上这些术语词汇也是和底层代码一一对应的 ，这些词汇只是披在代码上的一层“外衣”只是为了要业务人员能够看懂而已。 所以这些词汇意思一定要准确一定要让业务人员看懂，如果 将来我们的词汇被业务人员“误解”将是一件很严重的事情。  Bom中的“方法” Ilog不是万能的 不能对所有的情况进 行判断，例如 有这样一条需求 ： 如果一辆车的车牌号包含“京”，“辽”，“苏” 字样的时候执行一个操作，如果车牌号包含“粤”，“湘”，“浙”的时候执行另一个操作。 这样的需求规则引擎自己默认的条件判断是不能完成的，因为 ilog的条件判断是基于 java api所提供的最基本的判断，如两个数字的比较，两个字符串是否相等，一个字符串是否是另一个字符串的字串，日期的比较等等。 而上面的需求对于每个涉及的字样都做判断不现实，因为这些东西是不断变化的并且数量可能很多所以如果这样做 的话，将 会破坏整体的规则规划， 例 如本来这个判断可 以作为决策表中的一列 ， 但是现在要单独拿出来写很多的业务规则 这样做也不利于以后的维护。 这时候我们 可以 在 bom中添加一个返回布尔类型的方法，在 bom到 xom的映射中实现上面的需求，然后添加导航短语就可以在规则中使用了。 所以在分析需求的时候，这样的需求一定要注意 并加以标注。 需求与 xom 设计 有了上面的 bom “词汇”，我们需要知道我们的规则有哪些“原料”。 虽然说我们有了“词汇”，并不是所有的信息都是规则调用程序 提供 的。 我们可以把这些词汇叫做“半成品”他们在实际规则中是由某个或某几个参数经过处理后得到的结果。 这时候我们就需要和规则调用程序的技术人员确定“词汇”中哪些信息是由规则调用程序作为参数传入的，哪些词汇是“合成”的以及是怎么合成的 ，然后整理规则调用程序提供的信息，根据调用方式的不同形成 java bean 对象或者 xml报文。 xom（执行对象模型） ，前面已经说过 xom是信息的载体。 当 xom作为规则集参数参与规则调用的时候就是信息载体比如一些 java bean xom 和 xml报文 xom等。 但是 xom也可以是因为某种需要我们所写的一些 java工具类 ，如连接数据库，记录日志，或者完成一些比较复杂的逻辑判断。 这 些 xom不作为规则集参数而是引入到规则工程中作为 bom规则引擎项目开发手册及规范指导－ ILOG 篇 中科软科技股份有限公司 第 6 页 条目在规则中调用。 好了上面说了这么多，其实就是需要我们 在 整理 需求的时候 ，分析出 我们的规则中需要哪些 工具。 正如前面所说 ilog不是万能的，它只是给了我们一种新的思想，就像给了我们一支画笔，我们用这支“笔”画出美丽的画卷。 需求与整体规则流程设计 规则流是整个规则工程中规则的执行顺序， 规则流的设计主要是对规则工程中的规则进行分块，并设定各个模块的作用。 这对整个规则工程 的运行 来说 决定了 规则的执行效率 ，而 规则流的设计又决定了后期开发的时候规则开发的分工。 有 待补充。 需求与权限设计 我们所编写的规则将来会有来自不同部门的人员来维护， 他们所维护的规则又只能是 属于自己的部门或者公共的规则。 基于上面的情况，我们 需要对用户维护规则的权限做 如下分析。 规则维护人员角色 ： 这里的角色可以简单分为 ：一般规则的维护人员（负责规则的修改，规则创建等工作）；规则审核人员（负责对修改的规则，或者创建的规则进行业务审核来防止错误发生）； 规则测试及部署人员（对于审核通过的规则进行业务测试，如果测试通过则部署到正式环境上去）。 所以 在做需求的时候这部分一定要 做细致的分析 ，分配好人员角 色为以后进行权限实施的时候用户组的创建奠定基础。 规则维护人员 分组 ： 这里的“规则维护人员”主要指的是 “一般规则维护人员” ，他们将归属于各个部门 ， 维护属于自己部门的规则 或者查看公共的规则 等。 例如 下面的分析项 ： 我们所开发的规则将来为几个部门服务。 同一条规则的取值在各个部门是不是不同， 如同一家连锁超市的不同分店消费每满一百元所打的折扣 将会有所不同。 各个部门间的规则是否允许相互查看。 这些分析将会决定着我们将来规则的分包，规则维护用户组的建立。 规则的权限归属 ： 上面着中阐述了规则维护人员的分组 ，如果用户的组已 经确定下来的话下面要做的就是这些用户将对哪些规则做什么样的操作。 例如： 是否可以创建文件夹，规则等等。 对属于自己部门的规则可以做哪些操作，如： 是否可以 ， 删除 规则 ，更改规则的 值，更改规则的属性 等等。 对于不属于自己部门的规则将有哪些权限，如：是否可以查看，是否可以添加规则，是否可以删除规则，可以做哪些更改等等。 如上所说的几点在实际中 并不是都能用的上，例如客户只有一个部门，维护人员也只有一个人。 上面的论述只是说明了在做需求分析的时候对于权限方面应该考虑的事情，规则引擎项目开发手册及规范指导－ ILOG 篇 中科软科技股份有限公司 第 7 页 这些内容将会随着 ilog项目实施经验的积累不断的 丰富。 规则引擎项目开发手册及规范指导－ ILOG 篇 中科软科技股份有限公司 第 8 页 4 调用接口的设计与开发 本章将介绍 ilog规则集 的各种调用技术 （主要是已经做过研究的，对于还没有研究的将在以后补充） ，以及规则接口开发中的注意事项等等。 接口的设计原则 目标： 我们的规则库将会被设计的有一定的通用性。 这里所说的接口是对规则调用程序敞开的一个调用端口， 这个端口可以是直接使用的 ilog提供的调用端口， 也可以是介于 ilog调用与规则调用程序之间的 一个 适配器。 要想规则库有通用性的话，那么规则库的词汇表也应该是固定的。 这时候问题就来了，因为项目可能被多个客户使用，而每个客户对相同字段信息的 编码又不一样这时候就需要我们的接口有一个转换机制。 这样就用到了我们上面提到的“适配器”。 j2se 调用 j2se调用就是，调用程序和 ilog服务都是 java应用程序而和 web容器或 ejb容器没有任何关系，也不在其中部署。 关于这个 调用方式我们现在还没有用到所以没有做深入的研究如果有兴趣，参见ilog帮助文档 ，相关信息导航路径： “ ILOG JRules User Guide Executing Rules Tasks Executing a Ruleset Using Rule Execution Server Creating a POJO Client Project for RuleApps” JAVAEE 调用 Javaee调用是我们经常用到的调用方式， 如下图所示。 同步调用来自远程客户端的决策服务可以通过使用有状态或无状态的 EJB 来完成。 同步调用来自本地客户端的决策服务，可以通过使用有状态或无状态的 EJB 的本地接口，或使用 POJO 来完成。 EJB 适用于远程客户端访问功能和对说明性事务以及安全描述符的支持。 POJO 适用于更简单的打包和部署以及在 EJB 容器外部使用。 规则引擎项目开发手册及规范指导－ ILOG 篇 中科软科技股份有限公司 第 9 页 图 JAVAEE规则调用示意图 对于 JAVAEE 的调用方式 ilog提供了一个 EJB接受来自本地，远程 ，有状态，无状态的会话 ，然后调用执行服务器的执行单元来执行规则，执行完后将结果返回。 如果您对该部分的知识还不够了解可以参见如下内容进行相关的学习：规则引擎项目开发手册及规范指导－ ILOG 篇 中科软科技股份有限公司 第 10 页 在 javaee 中使用规则会话的例子 Samples Rule Execution Server Integration How to Use a Rule Session in J2EE 使用无状态会话调用规则集 ILOG JRules User Guide Executing Rules Tasks Executing a Ruleset Using Rule Execution Server Invoking a Ruleset Using a Stateless Rule Session 使用有状态会话调用规则集 ILOG JRules User Guide Executing Rules Tasks Executing a Ruleset Using Rule Execution Server Invoking a Ruleset Using a Stateful Rule Sessin J2EE 这里的重点不是讲解怎样使用 JAVAEE 的调用方式来调用我们的规则集，正如本章开始所说， 我们应该提供一个适配器来将这种调用进行封装。 当然我们也可以将这种JAVAEE 的调用直接抛给客户的规则调用程序，但是那样的话 我们所定义的规则集参数xom 字段代码一定要和客户提供的参数相一致，否则就失去了通用性。 所以这里的开发需要做如下考虑： 将规则的调用封装成一个 jar包（包含规则调用的相关 api） 来供客户的规则调用程序调用。 我们将规则调用封装后就可以 在一定程度上简化客户的规则调用。 我们可以在我们的 api中异构客户的规则 调用程序提供的规则集参数。 我们可以利用我们的 api 来开发很多新的功能（这将是在实践中慢慢发展的 ，总之有了这样的 api我们就有了做这些事情的可能 ）来满足客户的需求，或者方便客户调用等等。 webservice。