基于构件技术规则引擎研究.docVIP

基于构件技术规则引擎研究 　　摘要：随着构件技术的成熟，针对构件技术在业务层面的不足，本文研究了规则引擎的架构以及推理机制，通过规则引擎和面向构件技术的结合提出了基于规则引擎的软件构件模型实现方式。在实际的企业服务开发工程中,使用文中所提出的基于规则引擎的构件模型将提高开发效率同时提高软件复用性和可维护性。 　　关键词：规则引擎 构件 业务规则 　　 　　0 引言 　　面向构件技术是把传统工业标准化、模块化和分工协同的思想应用于软件开发领域，同时继承和发扬了很多相关软件技术的成果，在改善人与计算机的沟通，提高软件的复用程度，以及如何提高开发效率快速反映变化等方面取得了突出的发展。 　　对于复杂企业级项目开发，在业务应用层面，我们需要面向业务性的构件具有灵活性，同时还要解决“业务逻辑相关”构件的可复用性，可维护性以及可扩展性。 　　而目前大多数的平台厂商专注于在构件架构的技术上，目的是使开发人员能够开发出粒度非常高的可复用的构件。但是“多变”的业务逻辑使得我们只能提供低粒度的构件和接口，开发出的业务构件数量庞大，但很难复用和维护。所以我们必须将“多变”的业务逻辑与程序代码分离，让它们能在运行时可以动态地管理和修改从而提供软件系统的柔性和适应性。从而实现管理和复用业务逻辑，并且业务逻辑的变更也不会影响引起构件本身的变更。规则引擎正是应用于上述动态环境中的一种解决方法。由此，我们在深入理解规则引擎技术的基础上，同时将规则引擎引入面向构件技术。 　　1 规则引擎 　　一个业务规则包含一组条件和在此条件下执行的操作，它们表示业务规则应用程序的一段业务逻辑。业务规则的理论基础是:设置一个或多个条件，当满足这些条件时会触发一个或多个操作。 　　规则引擎的推理步骤如下： 　　①将初始数据（fact）输入至工作内存(Working Memory)。②使用Pattern Matcher将规则库(Rules repository)中的规则（rule）和数据（fact）比较。③如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。④解决冲突，将激活的规则按顺序放入Agenda。⑤执行Agenda中的规则。重复步骤2至5，直到执行完毕Agenda中的所有规则。 　　任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。 　　当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种“动态”的规则执行链，形成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数据驱动的。 　　2 基于构件技术的规则引擎 　　2.1 面向构件技术 面向构件作为将软件系统分解与隔离的一种方法，是一个非常通用的概念。它解决了企业应用的结构问题。通过面向构件技术，一个系统是按照个性化的需求，从一个比较完善、比较成熟的组件库组装而成，大大提高了系统的成功率、稳定性、适应性和逐步发展性。通过面向构件对业务的封装和积累能够保护现有投资，有助于高效的表达业务，提高软件的复用程度，进而表现其内在的组织敏捷性。 　　2.2 构件技术中引入规则引擎 使用面向构件技术我们需要：应用系统的核心业务逻辑提炼成的构件具有高可复用率；制作构件时应使其尽量覆盖涉及的主题，并考虑潜在的用户需求及将来的变化；应尽量将复杂的功能封装为构件。 　　但是由于业务逻辑的复杂性以及多变性，现在大多数的构件平台仅能提供较低粒度的构件，使得开发人员需要花大量尽力来定制开发业务逻辑层面的构件，而且很难复用和维护。 　　因此要使构件能够面向业务层面就要通过规则引擎把“可变化”的业务逻辑与程序代码分离开来。 　　2.3 实施方案 在构件技术的基础上，规则引擎的实现方式是分布型的。也就是说，规则调用和规则的执行是分布式的。 　　首先，规则执行以服务的形式存在。规则服务的实现如下： 　　①以规则作为参数，创建规则引擎；②为规则引擎添加数据；③执行规则，获得返回。 　　其次，构件中只嵌入调用规则服务的代码，没有直接嵌入规则引擎。规则服务的调用如下： 　　①准备规则集需要的数据；②指定被使用的规则集名称；③调用规则服务、执行规则并获得返回；④处理返回结果。 　　最后，规则是在业务模型之上定义的，利用可视化规则开发工具，Web规则编辑器定义规则，从而简化规则的编写过程。可视化规则开发工具定义好的规则最终形成规则库存储在构件之外，可以存储在数据库或文件系统中。 　　其中，将规则存储在构件之外的另一个好处就是能够实现规则的复用。