BPEL规则引擎介绍.docVIP

业务规则引擎 由于所开发系统的业务逻辑的复杂和多变，让我们吃尽了苦头，寻找解决方案的一个思路是将业务逻辑控制分离出来，降低这部分修改的难度采用script来描述业务逻辑了业务规则管理技术的出现彻底改变了传统的以过程形式处理业务逻辑的方式。而是将业务规则的实现从具体的程序代码中抽取出来，以结构化的业务规则数据来表示企业的业务行为，使得业务规则与企业的数据信息一样被高效地组织管理和应用。 业务与IT是紧密相连的，但业务与IT之间却始终存在着矛盾：软件开发人员善于编写代码，但对业务规则却知之甚少；相反的，业务人员熟知业务规则，却又很难将规则转换成合适的文档或代码。业务规则管理系统（Business Rules Management System，简称BRMS）可以把对逻辑甚至代码的控制权交给业务人员，在业务和IT之间架起了一座桥梁。规则管理系统提供了一个在企业应用程序之外修改和管理业务规则的解决方案。  这是一种嵌入在应用程序中的组件，它的任务是把当前提交给引擎的数据对象与加载在引擎中的业务规则进行测试和比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻辑，触发应用程序中对应的操作。 目前主流的规则引擎组件多是基于Java和C++程序语言环境。在2000年11月，Java Community Process（简称JCP） 组织开始着手起草Java规则引擎的API标准，即JSR 94 规范。参与JSR 94起草的有BEA、IBM、ILOG、甲骨文、Novell、ATG、Unisys、Fujitsu等著名的软件企业。JSR 94 在2003年11月25日正式定稿，支持JSR 94标准的规则引擎也几乎同时推向市场，包括ILOG 的JRules和Blaze的Advisor。 规则引擎的使用方式 由于规则引擎是软件组件，所以只有开发人员才能够通过程序接口的方式来使用和控制它，规则引擎的程序接口至少包含以下几种API：加载和卸载规则集的API；数据操作的API；引擎执行的API。开发人员在程序中使用规则引擎基本遵循以下5个典型的步骤：创建规则引擎对象；向引擎中加载规则集或更换规则集；向引擎提交需要被规则集处理的数据对象集合；命令引擎执行;导出引擎执行结果，从引擎中撤出处理过的数据。使用了规则引擎之后，许多涉及业务逻辑的程序代码基本被这五个典型步骤所取代。 一个开放的业务规则引擎应该可以嵌入在应用程序的任何位置，不同位置的规则引擎可以使用不同的规则集，用于处理不同的数据对象。此外，对使用引擎的数量没有限制。 规则引擎的内部实现 规则引擎的基本机制是：对提交给引擎的数据对象进行检索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发现符合条件的规则，创建这些规则的执行实例。这些实例将在引擎接到执行指令时、依照某种优先序依次执行。一般，规则引擎内部由下面几个部分构成：工作内存，用于存放被引擎引用的数据对象集合；规则执行队列，用于存放被激活的规则执行实例;静态规则区，用于存放所有被加载的业务规则，这些规则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行实例。规则引擎的结构示意图如图3所示。 任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。 当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种动态的规则执行链，形成规则的推理机制。这种规则的链式反应完全是由工作区中的数据驱动的。 规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基·梅隆大学的Charles L. Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。 BOM赋予规则行业特性 业务规则一定是针对某种业务的，不同的业务有自己特有的业务模型——业务对象模型（Business Object Mode，简称BOM）。BOM为业务规则语言提供了绝大多数的词汇，多由业务系统分析员设计，由开发人员具体实现。从面向对象的编程角度来看，BOM就是一个简化的类图，类图中有类名、类的属性、类的方法等。这些要素都将是业务规则语言中的基本词汇。BOM的来源可以是Java对象模型、C++对象模型、XML Schema、Web服务定义等。 假定我们有一个简单的宠物商店购物车应用程序，在这个应用程序中