基于BRMS的“旅游一卡通”计费系统的设计
文章出处：http://www.nexussmartsolutions.com 作者：张燕玲 潘正运 王莉 人气： 发表时间：2012年01月23日
随着科技不断进步和信息化时代的到来，旅游行业的管理也在不断地进行信息化的革命。单个独立的应用系统已经不能满足旅游系统综合管理的需求，而对“旅游一卡通”系统的开发将有效地整合卡应用系统的信息资源，使游客在河南旅游时可以通过简单的一张卡实现所有消费。但是由于“旅游一卡通”系统涉及到吃、住、行、游、购、娱6大要素，旅游行业间的竞争也越来越激烈，各个运营商要不断地推出新的服务，有针对性地向用户提供各种新的计费规则，及时回应竞争对手的策略变换。所有这些需求使得“旅游一卡通”系统的业务规则复杂多变，能否对其实行有效的管理就极大地依赖于“旅游一卡通”计费系统的有效支持。
在许多传统的计费系统中，由于业务规则以程序代码的方式“固化”在系统中，缺乏真正的灵活性，使运营商要推出新的服务或推出新的优惠计划时，必须通过IT人员编写代码的方式来修改规则，然后经过繁复测试才能部署实施。这导致业务策略的变动周期非常的漫长。同时，由于业务规则是面向技术人员的程序代码，使业务策略无法被业务人员真正的掌握和管理。而本文提出的一种基于业务规则管理系统的计费系统可以使业务规则与程序代码分离，使得对业务规则能够进行有效地管理和灵活的运用。
1 业务规则管理系统
1.1 业务规则管理系统概述
业务规则管理技术是伴随着面向对象技术、软件构件技术、人工智能、数据库、XML(数据库的表示)等相关技术的发展而出现的，具有规则管理、规则部署、规则分析、规则定制和设计功能。业务规则管理系统是一组工具集，包括：
(1)规则引擎(Rules Engine)：规则引擎是执行业务规则的软件组件，它嵌入在程序中，是业务规则管理系统的核心元素。规则引擎的类型有：简单型，数据中心型和面向事务型。
(2)规则库(Rules Repository)：规则库用于存储规则和规则元数据(Meta Data)以及与规则有关的属性。它提供一组工具用于存储、分类、查询、版本控制、权限控制、测试、提交等，规则的状态和有效性可以跟踪。
(3)规则语言框架(Rules Language Framework)：规则语言一般分为两类:“面向程序技术”的规则语言，使用者是技术人员；“面向业务”的规则语言，使用者是业务人员。规则语言框架是为定制“面向业务”的规则语言提供支持。
(4)规则集成开发环境(Rules IDE)：一般规则集成开发环境只有规则编辑器，而高级的规则集成开发环境可以实现对规则和规则库的管理：如规则的创建、分类、检索、修改、版本控制、权限管理。
BRMS的模块结构如图1所示。
1.2 BRMS的基本原理
BRMS的基本原理是用一个或多个规则引擎替换“固化”在计费程序不同位置的业务规则(逻辑)的程序代码。被替换的业务规则(逻辑)存储在程序之外的规则库中；规则库中的规则可以通过图形化规则管理工具实现定制、修改和部署，如图2所示。
1.3 基于BRMS的系统开发
基于BRMS的系统开发可以划分为3个阶段：
(1)设计阶段：这个阶段与传统的系统开发不同点在于，除了技术架构(包括规则引擎的位置安排)和基础数据结构的设计之外，最主要是完成业务对象模型(BOM)的设计，为业务规则的开发提供必要的“词汇”；定义规则的组织结构；设计业务规则的模板。
(2)开发阶段：这个阶段包括业务规则开发和系统程序的开发。
(3)部署阶段：这个阶段主要是业务规则服务的部署。业务规则服务(Rule Service)分布在系统的不同位置上，每个提供规则服务的模块都嵌入了规则引擎，不同的规则服务可能使用不同的规则集。在这阶段中，部署人员需要通过系统提供的方法或规则管理工具把不同的规则集部署到系统的对应位置上，使规则引擎可以访问到它们需要的规则集。
2“旅游一卡通”计费系统的设计
“旅游一卡通”计费系统是利用BRMS技术对系统进行设计的，这样可以使业务规则在系统外被定制，运营商无须开发人员介入，就可以让他们的业务人员创建和修改规则。
在旅游计费系统中，业务规则时刻扮演着非常重要的角色。它能很好地把繁杂的计费规则，如优惠、折扣规则等提取到系统之外进行管理，同时配合高性能的规则引擎和友好的规则用户界面，使得业务人员能够迅速地根据市场的变化而改变它们的促销策略。
2.1 系统总体结构
本系统在ILOG JRules上进行总体设计，选用J2EE为系统开发部署平台，如图3所示。JRules是由ILOG公司开发的一套业务规则管理系统的通用软件，它可以为系统的开发提供图形化的界面，具有完备的功能；J2EE平台为设计、开发和部署业务规则应用程序提供了一种基于组件的方法。整个系统分为前台Web客户端显示模块和后台处理模块两个部分。Web客户端有两种界面：
(1)针对业务定制人员的Web Rule Builder编译器。业务人员通过在规则编辑器中编写规则，然后将编辑的内容提交到后台计费规则管理模块中，由计费规则管理模块对计费规则库进行更新；另一方面，计费规则管理模块可以通过远程调用接口调用规则服务组件，将更新的规则直接作用于应用程序，以便于前台规则使用人员使用新的规则对客户进行计费处理。
(2)面向规则使用人员的Web App Portal。规则使用人员通过应用程序接口于计费规则会话Bean进行交互，同时激活规则服务组件对规则库进行操作，取出符合需求的计费规则返回给应用程序接口，前台计费业务人员根据相应的计费规则从客户的“旅游一卡通”IC卡中扣除相应的金额。
图3 BRMS旅游计费系统的总体结构
2.2 系统业务对象模型BOM(Business Object Model)的建立
业务规则模型的设计是基于规则系统的非常关键的步骤，它直接关系到整个系统是否能够真正灵活地运转起来。业务模型是由一组类(Class)构成，每个类包含属性(Property)和一些方法(Method)。类的属性、类与类的关系将会出现在业务规则的条件部分(Condition)，类中的属性值与导入到引擎中的许多规则的条件进行匹配，如果某些对象(或对象之间的关系)满足某个规则的条件的定义，那么引擎将触发规则的执行部分。
2.2.1 业务对象的分析
“旅游一卡通”系统是一个复杂的消费系统，它不仅涉及消费者，而且整个旅游行业的所有企业，包括酒店、餐饮、旅行社、景区景点等都是组成这个系统的关键要素。建立完善的旅游计费系统就必须抽象出这些独立业务对象的共性，建立统一的、具有共同特征的业务对象实体。在本系统的设计中，抽象出了以下业务对象：
(1)客户(Customer)对象：这里的Customer对象是特指利用“旅游一卡通”进行消费的游客，是消费的主体。Consume对象在消费过程中可以享受相应的免费资源、折扣和优惠措施。在系统中该对象具有一定的类型属性，根据不同的企业所定义的属性值是不同的。
(2)企业(Enterprise)对象：Enterprise对象是指组成“旅游一卡通”系统的旅游部门，包括酒店、旅行社、景区景 点等。
(3)消费项目(Consume)对象：由于各个行业部门不同所以其中包含的消费项目也是大相径庭的，所以将消费项目(Consume)单独抽象为一个业务对象，使之与Enterprise对象相关联。
(4)折扣方案(Discount)对象：折扣是计费系统中比较复杂的一项业务规则，它主要的特点就是经常变动。对于不同的客户采取的折扣也是不同的。并且单位采取折扣的时间是有限制的，所以该对象具有时效性和有效性。
(5)优惠方案(Privilege)对象：优惠是计费系统的另一个重要组成部分，它同样具有时效性和有效性。
2.2.2 业务对象模型的建立
各个业务对象之间存在着复杂的关联。客户这个业务对象是整个系统的消费主体，其消费行为通过“旅游一卡通”直接与所有系统中的企业对象实体相联系。客户在系统中消费时可能和多个企业对象相联系，所以抽象其业务对象属性CustomerEnterprise[]与消费企业对象进行关联。
企业这个业务对象实体是整个计费系统得关键所在。因为系统中的企业是完全独立的个体，在实施计费策略时是大不相同的，而且对于单个CustomerEnterprise对象内部不同消费项目的计费策略也不完全相同。每个CustomerEnterprise包括若干消费项目Consume，通过属性Consume[]与消费项目实体相关联；企业可能对所有的消费项目，也可能针对某消费项目实施折扣、优惠等方案，所以不单单是企业而且消费项目都与折扣、优惠和免费对象实体相关。它们通过属性FreeItem[]与免费资源对象的关联，通过DiscountPlan[]对象属性与折扣方案对象关联，通过PrivilegePlan[]与优惠方案对象关联。
根据以上分析抽象系统的业务对象模型如图4所示（略）。
2.3 规则引擎的嵌入和使用
业务规则引擎的嵌入和使用步骤。可以按照下面的基本步骤实现规则引擎的嵌入和使用(采用ILOG JRules的API)：
(1)创建一个规则引擎对象(这是ILOG JRules)提供的对象。
// Create an ILOG rule engine
IlrContext myEngine = new IlrContext();
(2)从规则库中取得与计费相关的规则包，并加载到规则引擎中。(注意：这里折扣规则包存储在名字是“Discount-rules”的文件中，优惠规则包存储在“Privilege-rules”如果规则包保存在数据 库中，需要使用其它的API)
//get the IlrRuleset associated with myContext
IlrRuleset myRuleset＝myContext.getRuleset()；
//Add rules to myRuleset
myRuleset.parseFileName(“Consume-rules”)；
myRuleset.parseFileName(“Discount-rules”)；
myRuleset.parseFileName(“Privilege-rules”)；
myRuleset.parseFileName(“FreeItem-rules”)；
(3)使用引擎的API，向规则引擎导入客户对象(Customer)，企业对象(Enterprise)，该客户的消费方案(Plan)，该客户的优惠方案(Privilege)，折扣方案(Discount)和该客户相关的有效免费资源(FreeItem)。引擎将对导入的所有对象的属性值与当前加载的规则包中的优惠规则进行匹配比对，把匹配的规则放在一个规则执行队列中。
myEngine.insert(Customer);//提交客户信息
myEnterprise.insert(Enterprise);//提交企业信息
for (int ii=0;ii<…; ii++
{ //提交与企业相关的消费项目信息
myEngine.insert(Consume[ii]);
}
for (int ii=0;ii<…; ii++
{ //提交该客户相关的免费资源信息
myEngine.insert(freeItem[ii]);
}
for (int ii=0; ii<……; ii++) {//提交该客户相关优惠方案信息
myEngine.insert(Privilege [ii]);
}
for (int ii=0; ii<……; ii++) {//提交该客户相关折扣方案信息
myEngine.insert(Discount[ii]);
}
(4)使用引擎的API，通知引擎执行规则执行队列中的规则实例，即触发规则执行部分的方法。在引擎逐个执行规则的过程中，会出现这样一些可能操作：一些对象的属性值将会被修改(如免费资源的可用量会减少)；有些新的对象被创建，如新的免费资源被生成等。引擎会在每个规则被执行之后会自动作这样的检验：当前状态下，“规则执行队列”中等待执行的规则是否还满足条件，剔除不满足条件的等待执行的规则；同时检查规则包中原来没有在“执行队列”的规则是否符合当前状态的规则，如果有则把它们加入到“执行序表(Agenda)”中。引擎最终会清空“执行队列”。
// execute the rules on the agenda
myEngine.fireAllRules();
使用引擎的API把引擎中的对象取出并导出(如回存数据库等)
// retrieve updates objects from engine
myEngine.getObjects();
// output code…
…
// empty engines for next time use
myEngine.removeObjects(); //从引擎中撤除所有对象，为下一//个优惠处理作准备。
3 结束语
本文对BRMS系统在“旅游一卡通”计费系统中的应用与开发进行了研究。本系统的设计大大简化了对“旅游一卡通”计费系统业务规则的开发与管理，该系统是目前比较符合实际的较为理想的“旅游一卡通”计费系统。它的应用必将极大地提高旅游市场计费业务规则的管理效率，具有广阔的市场前景。
