BPEL规则引擎介绍.doc

业务规则引擎由于所开发系统的业务逻辑的复杂和多变，让我们吃尽了苦头，寻找解决方案的一个思路是将业务逻辑控制分离出来，降低这部分修改的难度, 方法一:采用script来描述业务逻辑了, 将复杂的业务算法 业务规则统一放入脚本程序中, 使得易于维护 修改,发布, 但最终脚本语言 还是得由 程序开发人员来编写方法二:使用业务规则引擎, 将复杂的业务规则,业务处理逻辑交给 使用业务系统的业务人员, 开发人员不需要关心业务逻辑,业务算法, 业务人员通过规则编写器编写好一个个的业务规则,然后将业务规则部署到业务规则引擎中, 而开发人员编写的应用程序,负责将业务规则需要的处理数据,传递给规则引擎, 规则引擎调用相关的业务规则,处理完将结果返回给应用程序,目前规则引擎的使用 已经非常广泛,很多公司都有使用这种技术, 在规则引擎中被使用最多的就是ilog公司的产品 占了全世界30% 以上我们的系统中的派彩算法 (根据荷官牌局, 客户牌局得到的牌局结果, 投注位置 投注位置对应的赔率) 等这些信息,来计算的, 幸运的是 ,牌局结果的计算, 投注位置的配率 等等 这些信息,都是系统开始开发前就确认了,很少会变动的,所以 派彩这个算法,能够在我们的系统写死, 且基本不用修改, 试想一下, 假如牌局结果的计算, 投注位置的赔率, 等等这些信息 客户要经常更改,变化,或许我们的应用程序 就要三天两头 去修改, 测试 再发布, 这个工作量是非常大的,肯定是一个不可行的办法, 这时我们就会想到使用配置文件啊 脚本语言啊 等等办法来解决这个问题, 但 这些办法中我觉得最好的一个办法就是使用规则引擎, 对于每个游戏牌局结果的计算, 赔率的设定,到最后派彩信息的生成, 这些算法逻辑, 都可以使用一个个的业务规则来设定好,且这个规则是由 可以由客户来轻松设置,而不是由我们开发人员来设置, 客户设置好这些业务规则,部署后, 这时我们的应用程序 只需要将荷官的牌局 客户的牌局,投注的信息传递给这些业务规则, 派彩信息就可以自动生成,并返回给我们的应用程序, 且 对于整个业务规则的变化过程, 对我们的应用程序而言 是没有任何修改动作, 不需要做任何发布工作或测试工作, 甚至开发人员根本不需要参与,开发新游戏时,从需求设计等方面都不需要考虑派彩这个业务规则逻辑,或许我们的客户能够自己通过配置就可以产生出一个新游戏. 这跟使用配置文件,或脚本语言相比,其优越性,不言而预, 使用配置文件或脚本都需要开发人员参与,修改脚本或配置文件, 并需要进行发布,测试工作,业务规则管理技术的出现彻底改变了传统的以过程形式处理业务逻辑的方式。而是将业务规则的实现从具体的程序代码中抽取出来，以结构化的业务规则数据来表示企业的业务行为，使得业务规则与企业的数据信息一样被高效地组织管理和应用。 业务与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服务定义等。 假定我们有一个简单的宠物商店购物车应用程序，在这个应用程序中，顾客能够在购物车中放入各种宠物和相关物品对象。这个应用程序的业务对象集合就可以有ShoppingCart(购物车)、Customer(用户)、Item (条目)和ItemType(条目类型)这几个类。 表述业务规则的语法就是业务规则语言。由于规则语言的使用者主要有两类:业务人员和技术人员，所以规则语言一般也分为两类：面向程序技术的规则语言，它技术性很强，可读性较弱，比较适合IT 技术人员使用，一般每个规则引擎开发商都有自己的一套面向程序技术的规则语言语法，不过OASIS组织定义了不同应用情况下的规则语言规范，包括 SRML（Simple Rule Markup Language），BMRL(Business Markup Rule Language)和RuleML（Rule Markup Language）等；面向业务的规则语言，它是业务人员使用的语言，必须具备非技术性和可定制性，通常它需要经过翻译之后才能被规则引擎解析。 BRMS必须提供这种翻译机制，而开发人员要实现从面向业务规则语言到面向程序规则语言的映射。 面向业务的规则语言无论从语法上还是语句结构上都可能千变万化，不同行业可能有自己的行话。一个好的BRMS应该提供一个完善的规则语言框架，能够迅速地为业务人员定制不同的行话，否则业务人员还是无法真正成为业务规则的主人。业务规则编辑器图例:商业流程引擎Bpel概念面向 Web 服务的业务流程执行语言(BPEL 或 BPEL4WS)是一种使用 Web 服务定义和执行业务流程的语言。BPEL 使您可以通过组合、编排和协调 Web 服务自上而下地实现面向服务的体系结构 (SOA)。BPEL 提供了一种相对简单易懂的方法，可将多个 Web 服务组合到一个新的复合服务(称作业务流程)中。Bpel商业应用在企业内部，BPEL 用于标准化企业应用程序集成以及将此集成扩展到先前孤立的系统。在企业之间，BPEL 使与业务合作伙伴的集成变得更容易、更高效。BPEL 激发企业进一步定义它们的业务流程，从而导致业务流程的优化、重新设计以及选择最合适的流程，进而实现了组织的进一步优化。BPEL 中描述的业务流程定义并不影响现有系统，因此对升级产生了促进作用。在已经或将要通过 Web 服务公开功能的环境中，BPEL 是一项重要的技术。随着 Web 服务的不断普及，BPEL 的重要性也随之提高。业务流程 与业务规则比较 业务规则: 用来处理业务检查 业务规则,业务算法,常用于替换一些应用程序中的一些业务算法 业务规则检查等 业务流程: 是指一种商业流程, 例如为员工订机票的商业流程: 先在本企业内部调用webservice判断员工可以坐什么档次的飞机, 然后调用不通航空公司的webservice,获取各航空公司的机票价格, 最后再决定买哪一个航空公司的机票Bpel业务流程元素BPEL 流程指定参与的 Web 服务的确切调用顺序 - 顺序地或并行地。使用 BPEL，您可以表述条件行为。例如，某个 Web 服务的调用可以取决于上次调用的值。还可以构造循环、声明变量、复制和赋予值、定义故障处理程序等。通过组合所有这些构造，您可以以算法的形式定义复杂业务流程。实际上，由于业务流程本质上属于活动图，因此使用统一建模语言 (UML) 活动图表示它们可能很有用。通常情况下，BPEL 业务流程接收请求。为了满足请求，该流程调用相关的 Web 服务，然后响应原始调用方。由于 BPEL 流程与其他 Web 服务通信，因此它在很大程度上依赖于复合型 Web 服务调用的 Web 服务 的 WSDL 描述。就好像我们写程序时,每个程序整个过程中 需要做不通的操作 调用不通的函数,一个 BPEL 流程由多个步骤组成，每个步骤称作“活动”。BPEL 支持基元活动和结构活动。基元活动表示基本构造，用于如下所示的常见任务:使用 调用其他 Web 服务 使用 （接收请求）等待客户端通过发送消息调用业务流程 使用 生成同步操作的响应 使用 操作数据变量 使用 指示故障和异常 使用 等待一段时间 使用 终止整个流程。然后，我们可以组合这些基元活动以及其他基元活动，以定义准确指定业务流程步骤的复杂算法。为组合基元活动，BPEL 支持几个结构活动。其中最重要的是:顺序 ()，它允许定义一组将按顺序调用的活动。 流 ()，用于定义一组将并行调用的活动 Case-switch 构造 ()，用于实现分支 While ()，用于定义循环 使用 能够选择多个替换路径之一。 每个 BPEL 业务还将使用 定义合作伙伴链接，使用 声明变量。如何编写一个业务流程一个简单的例子:机器A上 提供了一个webservice : 这个webservice的端口类型中提供了一个方法: String Merge(string , string) ,方法merge的功能是将输入的两个字符串拼装后将拼装后的字符串返回机器B上 提供了一个webservice: 这个webService的端口类型中提供了一个方法:String Reverse(int) 方法Reverse 的功能是输入一个整数 得到一个比自己大一倍的整数,并将这个整数转换为字符串返回机器C上 提供了一个webservice: 这个webservice得端口类型中提供了一个方法:String getString(string) getString得功能是输入一个字符串s 得到另一个字符串“getString + s“现在我们的这个商业流程是: 一开始接收1个字符串,str1和一个整数 n1, 然后分别通过str1, n1作为参数 ,同时去调用机器c上的webservce,得到另外1个字符 str2 , 和调用机器B上的webservce,得到 字符str3 ,最后我们再已 str2 和,str3 做为一个参数调用机器A上的webservce 得到一个字符串str4在编写好这个商业流程部署后 我们生成了一个新的组合型webservcie, 假如这个webservcice的名字是multiwebservice ; 那么我们就可以直接调用这个webservcie例如我们输入一个 hi 和 50 调用完multiwebservice后 我们将得到结果 getString + hi 100 ,这样一个字符串, 准备工作:需要先安装jdk tomcat, active bpel 引擎,安装好后 要启动ActiveBPEL引擎,只需要启动Tomcat就可以了。 当tomcat启动后，有两个WEB页可以显示服务器的信息 WEB 服务列表http:/localhost:8080/active-bpel/services ActiveBPEL 引擎管理http:/localhost:8080/BpelAdmin/ 在此页面可以修改引擎的配置参数下面介绍上述例子中的bpel流程的编写步骤:第 1 步:列出相关 Web 服务的清单就好比在编写程序时,你事先得准备你的代码中需要用的的头文件,需要调用的函数一样, 在您开始编写 BPEL 流程定义之前，必须先熟悉从业务流程中调用的 Web 服务。这些服务称作合作伙伴 Web 服务, 通常情况下，BPEL 业务流程接收请求。为了满足请求，该流程调用相关的 Web 服务，然后响应原始调用方。由于 BPEL 流程与其他 Web 服务通信，因此它在很大程度上依赖于复合型 Web 服务调用的 Web 服务 的 WSDL 描述。 所以我们必须得先 列出 bpel流程需要调用到得所有webservice的wsdl文件, Wsdl 文件可以通过在浏览器中输入webservice部署的地址 后面跟加一个 ?wsdl ,就可以得到对应webservice的wsdl文件, 在我们的例子中有3个web服务, 一个reverse 一个merge 一个getString,他们对应的wsdl文件可以参考附件, 为了方便 我将这3个web服务都放在了50 上,他们的wsdl也位与同一个文件中, 不过这3个服务可以放在不同的机器上,wsdl 也可以位于不同的文件中第 2 步:为 BPEL 流程定义 WSDL当您用 BPEL 定义业务流程时，您实际上定义了一个由现有服务组成的新 Web 服务。该新 BPEL 复合 Web 服务的接口使用一组端口类型来提供类似任何其他 Web 服务的操作。要调用用 BPEL 描述的业务流程，则必须调用生成的复合 Web 服务。既然bpel业务流程也是一个webservice, 只不过它是一个特殊的,组合了别的webservice功能的复合的webservice, 那么它也要有自己的wsdl,不然别人不知道如何来调用它, 所以我们必须为它定义wsdl, 我们要定义流程的 入口参数,以及返回参数 ,参数类型等等第 3 步:定义合作伙伴链接类型第三步是定义合作伙伴链接类型。合作伙伴链接类型表示 BPEL 流程与相关方(包括 BPEL 流程调用的 Web 服务以及调用 BPEL 流程的客户端)之间的交互。本示例包含4个不同的合作伙伴:调用业务流程客户端、机器A上的web服务, 机器B上的web服务 机器C上的web服务。对于本示例，我们定义了4个合作伙伴链接类型(每个类型位于 Web 服务的相应 WSDL 中):每个合作伙伴链接可以拥有一个或两个角色，我们必须为每个角色指定它使用的 portType。对于同步操作，由于操作只是单向调用，因此每个合作伙伴链接类型仅有一个角色。对于异步回调操作，我们必须指定两个角色。第一个角色描述客户端操作调用。第二个角色描述回调操作调用。定义合作伙伴链接类型,当然可以手工编写,不过利用业务流程编辑器的向导来编写当然更方便第 4 步:创建业务流程现在，您就可以开始编写 BPEL 流程了。通常，BPEL 流程等待客户端传入的消息，以启动业务流程的执行。在本示例中，客户端通过发送输入消息中传入参数str1 n 启动此 BPEL 流程。然后，此 BPEL 流程同时调用getString, reverse ,并用getString reverse返回的直调用merge,最后将结果返回, 业务流程的编写 当然可以象 编写代码一样,来手工编写, 不过这是一个太好的办法, 就好像你使用delphi 来编辑窗体的时候,你直接可以使用delphi的控件 方便的绘制一个完美的界面, 而不用每一步都通过编写代码来绘制一个界面, active bpel desiger 就是一个提供编写bpel 业务流程的 编辑器工具 业务人员可以方便的通过它来轻轻松松编写自己想要的业务流程, 现在就通过手工演示 如何在active bpel desiger中编辑好例子中的流程第 5 步: 模拟测试手工演示第 6 步: 部署 手工演示部署完后就可以调用我们的业务流程了,就跟调用一个普通的webservice 一样 豪无区别业务流程的执行环境 流程引擎引擎配置的处理是通过一个对象提供的缺省值并读取aeEngineConfig.xml文件.引擎连接一个队列管理器和一个流程状态管理器,对象负责执行履行那些服务给引擎.引擎是高度可配置的, aeEngineConfig.xml文件不仅描述