CN104966239A - 一种基于规则引擎的智能核保平台 - Google Patents

Abstract

本发明公开了一种基于规则引擎的智能核保平台，其基于SOA架构体系，该平台设有BI智能商务模块、ESB企业服务总线、规则引擎模块、数据库以及规则库；数据库用于组织、存储和管理业务数据；规则库用于组织、存储和管理规则数据；BI智能商务模块，用于对业务数据进行收集、管理和挖掘；ESB企业服务总线，用于提供开放的接口，联接BI智能商务模块、规则引擎模块和数据库；规则引擎模块用于解析、调用、执行以及生成规则包，规则引擎模块包括规则生成器，规则生成器输入来自BI智能商务模块、数据库和规则库的数据，生成核保规则包并输出至规则库中。本发明方便核保人员快捷核保，并随时生成新的实用核保规则，可应用在寿险行业领域。

Description

一种基于规则引擎的智能核保平台

技术领域

本发明涉及保险核保领域的核保平台，特别是一种基于规则引擎的智能核保平台。

背景技术

目前，保险企业面临的信息***性增长已经远远超出现有的处理和响应能力。据统计，80％的新增数据信息来自电子邮件、文档、图像、视频及音频等非结构化内容，保险企业对于90％的非结构化内容无法进行有效管理，60％的管理人员在制定业务决策时无法获得关键信息，50％的企业内容无法为企业带来业务价值。对于大部分保险企业来说，不同的信息***采用的平台和技术(例如：信息通信协议，信息交换格式，应用部署平台，等等)差异很大，这些应用***彼此相互独立和分离，无法或者很难进行通信，不可避免会出现所谓的“信息孤岛”现象，不论是企业之间还是企业内部，资源都不能有效地优化和共享，如何将分散、独立的信息孤岛有效连接起来，已成为企业迫切需要解决的问题；此外，多数保险公司核保规则的制定都由保险公司的业务部门根据经验及业务事件进行制订，缺少核保知识的参考及分析，在市场变化越来越快的情况下，从制订核保需求到实现核保需求的***化，IT周期已落后与业务需求的要求；且目前核保***架构中，其规则逻辑直接嵌入在程序代码里，或者与业务应用声明编写在同一个文件中，而实际应用的业务逻辑不断变化，需要实时更新及编辑信息路由文件，这样在***频繁改动过程中造成的核心***框架的冗繁复杂，使得核保平台处理效率低下。

发明内容

本发明为解决公知技术中存在的技术问题而提供一种基于规则引擎的智能核保平台。

本发明为解决公知技术中存在的技术问题所采取的技术方案是：一种基于规则引擎的智能核保平台，该平台基于SOA架构体系，该平台设有BI智能商务模块、ESB企业服务总线、规则引擎模块、数据库以及规则库；所述数据库用于组织、存储和管理业务数据；所述规则库用于组织、存储和管理规则数据；所述BI智能商务模块，用于对业务数据进行收集、管理和挖掘；所述ESB企业服务总线，用于提供开放的接口，联接所述BI智能商务模块、所述规则引擎模块和所述数据库；所述规则引擎模块用于解析、调用、执行以及生成规则包，所述规则引擎模块包括规则生成器，所述规则生成器输入来自所述BI智能商务模块、所述数据库和所述规则库的数据，生成核保规则包并输出至所述规则库中。

所述规则引擎模块还包括规则生命周期子模块、规则查询子模块、用户操作锁定子模块、规则历史轨迹子模块以及预警子模块；所述规则生命周期子模块用于控制规则的验证与部署；所述规则查询子模块用来查询、更新与部署规则；所述用户操作锁定子模块用于管理多用户同时操作；所述规则历史轨迹子模块用来跟踪和管理规则的变化；所述预警子模块提供用户定义机制，用户针对某一量值的大小或两个量值之间的关系，来定义异常状况，并以改变字形颜色或***警示图案的方式来加以提示，支持字体颜色、背景色、特殊符号、个性化图形方式进行预警。

所述规则引擎模块采用RETE模式匹配算法。

该平台还包括Web service模块，所述Web service模块与所述ESB企业服务总线联接，所述Web service模块对外提供一个能够通过Web进行调用的API。

所述Web service模块设有与平台和编程语言无关的远程过程调用协议。

所述ESB企业服务总线采用事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，传输多种数据，并提供多种标准接口。

所述BI智能商务模块包括即席分析子模块、模板分析子模块和数据挖掘子模块；所述即席分析子模块允许用户任意选择指标、维度和过滤条件，生成多维分析表、查询结果以及统计图形；所述模板分析子模块提供可视化设计工具，定义各种分析报表、查询模板以及统计图模板；所述数据挖掘子模块采用数学分析方法对数据仓库中的数据进行分析，提供数据特性进行决策。

所述数学分析方法包括聚类分析、预测分析以及回归分析；所述聚类分析包括层次聚类算法、KMeans聚类算法、快速聚类算法；所述预测分析包括趋势预测模型、ARIMA预测模型、季节预测模型以及神经网络模型；所述回归分析包括线性回归、非线性回归以及Logistic回归。

本发明具有的优点和积极效果是：本发明使用BI技术与智能核保规则引擎相结合，使保险公司核保人员能够从大量的数据中发现有价值的信息，从而根据这些信息制定相应的核保规则，具有处理数据量大、数据可靠性要求高和***实时性较强等特点，可实现即席分析、模板分析、数据挖掘等功能，从而方便核保人员快捷核保，并随时生成新的实用的核保规则等，可广泛应用在寿险行业领域，其采用SOA架构方式，为整个***提供跨平台、开放的接口，成为寿险核心业务***和企业服务总线(ESB)的重要组成部分。

附图说明

图1是本发明的***结构示意图；

图2是本发明的工作流程图；

图3是本发明的SOA架构图；

图4是本发明的ESB企业服务总线结构示意图；

图5是本发明的规则引擎工作原理图；

图6是本发明的J2EE架构图。

具体实施方式

为能进一步了解本发明的发明内容、特点及功效，兹例举以下实施例，并配合附图详细说明如下：

请参阅图1至图6，一种基于规则引擎的智能核保平台，该平台基于SOA架构体系，该平台设有BI智能商务模块、ESB企业服务总线、规则引擎模块、数据库以及规则库；所述数据库用于组织、存储和管理业务数据,可包括存储保险业务事件的业务事件数据库、存储保险相关参数的参数数据库、存储保险相关历史数据的历史应用数据库；所述规则库用于组织、存储和管理规则数据；所述BI智能商务模块，用于对业务数据进行收集、管理和挖掘；所述ESB企业服务总线，用于提供开放的接口，联接所述BI智能商务模块、所述规则引擎模块和所述数据库；所述规则引擎模块用于解析、调用、执行以及生成规则包，所述规则引擎模块包括规则生成器，所述规则生成器输入来自所述BI智能商务模块、所述数据库和所述规则库的数据，生成核保规则包并输出至所述规则库中。在所述BI智能商务模块、所述数据库和所述规则库中，存放了了大量的核保数据、核保规则和保险知识,所述BI智能商务模块，对所述数据库和所述规则库进行即席分析、模板分析、数据挖掘等智能分析，所述规则引擎将平台智能分析后产生的有效数据及数据库中的其他数据输出到规则生成器中，通过规则生成器产生用户所需的核保规则，并且将规则输入核心规则库中。所述规则生成器自动生成关联规则，或者通过人机交互的方式对现有规则进行修改生成新规则，或者通过批量数据导入方式生成规则包，并存入规则库中，对规则库进行自动更新，将人工经验与***自动挖掘出的关联规则相结合，进一步完善规则库中规则。这样所述规则生成器输入来自BI智能商务模块、数据库和规则库的数据，并对这些数据进行分析，人工或自动生成新的保险核保规则并输出至规则库中。所述规则引擎实现的功能如下：

(1)直观的规则编写功能：核保人员通过智能平台分析得到一定的数据后，可以进行简单规则的编写，进一步可以生成决策表和决策树，让人直观的看出该核保规则的含义和用法。

(2)规则管理功能：核保人员可以通过灵活的规则组织分类(rule organization)与智能视窗(smarts views)来浏览规则集，通过规则属性(rule properties)来管理规则信息。可通过规则生命周期(rule life cycle)来控制规则的验证与部署。可通过查询(semantic queries)来找寻，更新与部署规则。可通过锁定(locking)来管理多用户同时操作。可通过历史轨迹(history)和版本控制(versioning)来跟踪和管理规则的变化。

上述SOA(Service-Oriented Architecture)架构体系，是面向服务的体系结构，其是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作***和编程语言。这使得构建在各种这样的***中的服务可以一种统一和通用的方式进行交互。这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合***的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。对松耦合的***的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需(On demand)业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。SOA是一种架构模型，在传统的业务层和技术层之间增加了一个服务层，独立完成特定的服务功能，使业务层和技术层相互独立，便于适应具体业务的变化。它可以根据需求通过网络对松散耦台的粗粒度应用组件进行分布式部署、组合和使用。图3所示为本发明的SOA架构一个具体实施例示意图，在此架构下，智能核保平台的数据库层、后台处理层、前台应用层、Oracle/SQL服务层、逻辑运算、规则引擎、业务逻辑架构等业务层和技术层相互独立，可以按需灵活地搭建。

图4所示为本发明的ESB企业服务总线结构示意图。ESB(Enterprise Service Bus)企业服务总线，是传统中间件技术与XML、Web服务等技术结合的产物。ESB企业服务总线提供了网络中最基本的连接中枢，是构筑企业神经***的必要元素。ESB企业服务总线的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB企业服务总线提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。

规则引擎，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。规则引擎可以通过降低实现复杂业务逻辑的组件的复杂性，降低应用程序的维护和可扩展性成本，其具有如下参数及特征：

(1)分离商业决策者的商业决策逻辑和应用开发者的技术决策；

(2)能有效的提高实现复杂逻辑的代码的可维护性；

(3)在开发期间或部署后修复代码缺陷；

(4)应付特殊状况，即客户一开始没有提到要将业务逻辑考虑在内；

(5)符合组织对敏捷或迭代开发过程的使用；

(6)支持规则的次序和规则冲突检验，支持简单脚本语言的规则实现，支持通用开发语言的嵌入开发；

目前有多个现有标准规则引擎可供开发使用，其中包括商业规则引擎和开放源码规则引擎可供选择。开放源码规则引擎的代表是Drools，商业规则引擎的代表是VisualRules、iLog等。

规则包的对象库中，定义了以下一些数据库对象接口：Database、Table、Select、View、Procedure。考虑到最小化规则引擎，规则包的解析工作可以放在规则编辑时，预先进行处理。规则引擎可以只处理规则包的调用和执行，同时为规则包用到的数据库接口、Excel接口、内存表接口、Xml接口提供缺省的实现。规则包需要调用的Excel接口主要是IExcelBook、IExcelSheet、IExcelTableSheet、IExcelXYSheet等。规则包需要调用的内存表格接口为Sheet等，规则包需要调用的XML接口为Node等。

VisualRules规则引擎采用java语言来实现规则引擎，并且提供了java类接口、Socket、Servlet、SOAP等多种外部调用接口。其实Java类接口是所有这些接口的核心，其他接口其实也是通过Java类接口来加以调用。VisualRules规则引擎会根据规则包名称，取得对应规则包编译后的rsc文件。然后将rsc加载到内存中，生成规则包执行上下文。同时规则引擎将传递的参数传递到规则包执行上下文中，然后开始执行规则包。执行完毕后，再将规则包执行上下文中的数据，传回给调用规则包的应用程序。整个执行原理非常简单，因此最大限度的保证了规则运行平台的稳定以及最佳的性能。

Drools规则引擎具有一个易于访问企业策略、易于调整以及易于管理的开源业务规则引擎，符合业内标准，速度快、效率高。业务分析师或审核人员可以利用它轻松查看业务规则，从而检验已编码的规则是否执行了所需的业务规则。其前身是Codehaus的一个开源项目叫Drools，最近被纳入JBoss门下，更名为JBoss Rules，成为了JBoss应用服务器的规则引擎，Drools被分为两个主要的部分：编译和运行时。编译是将规则描述文件按ANTLR 3语法进行解析，对语法进行正确性的检查，然后产生一种中间结构“descr”，descr用AST来描述规则。目前，Drools支持四种规则描述文件，分别是：drl文件、xls文件、brl文件和dsl文件，其中，常用的描述文件是drl文件和xls文件，而xls文件更易于维护，更直观，更为被业务人员所理解。运行时是将AST传到PackageBuilder，由PackagBuilder来产生RuleBase，它包含了一个或多个Package对象。在Drools中，规则被存放在Production Memory(规则库)中，推理机要匹配的facts(事实)被存在Working Memory(工作内存)中。当时事实被***到工作内存中后，规则引擎会把事实和规则库里的模式进行匹配，对于匹配成功的规则再由Agenda(议程)负责具体执行推理算法中被激发规则的结论部分，同时Agenda(议程)通过冲突决策策略管理这些冲突规则的执行顺序，Drools中规则冲突决策策略有：(1)优先级策略(2)复杂度优先策略(3)简单性优先策略(4)广度策略(5)深度策略(6)装载序号策略(7)随机策略。采用drools开源规则引擎，首先，建立Drools BRMS应用。Drools BRMS是一个管理和编译规则和规则流的Web应用程序，可以部署在大部分的支持J2SE 1.5的Web容器下，如Tomcat6。Drools BRMS架构体系分为三大部分，第一部分是UI层，提供了一个基于Ajax技术的业务规则编辑、管理工具。第二部分是规则文件仓库层，将规则文件统一保持在文件***或关系数据库。最后一个是Drools的核心引擎，用来对用户提交的规则文件进行验证、编译和部署。开发人员通过规则文件的编辑部署，生成了包含rule的package对象，这是引擎可直接操作的内存对象。BRMS通过一个URL提供对这个对象的HTTP访问。第三方可以通过Agent相关API来访问这个URL，程序自动下载这个Package对象就直接可以在规则引擎运行，得到规则执行的结果。然后，将BOM(Business Object Model业务规则引擎所要操作的对象)、规则流文件和规则文件上传到BRMS中。

进一步地，所述规则引擎模块还可包括规则生命周期子模块、规则查询子模块、用户操作锁定子模块、规则历史轨迹子模块以及预警子模块；所述规则生命周期子模块用于控制规则的验证与部署；所述规则查询子模块用来查询、更新与部署规则；所述用户操作锁定子模块用于管理多用户同时操作；所述规则历史轨迹子模块用来跟踪和管理规则的变化；所述预警子模块提供用户定义机制，用户针对某一量值的大小或两个量值之间的关系，来定义异常状况，并以改变字形颜色或***警示图案的方式来加以提示，支持字体颜色、背景色、特殊符号、个性化图形方式进行预警。根据预警，利用钻取和数据挖掘，用户可以快速定位问题和优势，制定相应的核保规则，及时修改不合理的规则。。

本发明中所述规则引擎模块可采用RETE模式匹配算法。RETE算法是一个用来实现产生式规则***(production/inference)的高效模式匹配算法。可以分为两部分：规则编译(rule compilation)和运行时执行(runtime execution)。规则编译是指根据规则集生成推理网络的过程，运行时执行指将数据送入推理网络进行筛选的过程。RETE算法中几个主要元素：事实(Fact)：对象之间及对象属性之间的关系；规则(rule)：是由条件和结论构成的推理语句，一般表示为if…Then，一个规则的if部分称为LHS(left-hand-side)，then部分称为RHS(right hand side)；模式(module)：就是指IF语句的条件，这里IF条件可能是有几个更小的条件组成的大条件，模式就是指的不能在继续分割下去的最小的原子条件。RETE推理网络的生成过程：从规则集{规则1，规则2……..}中拿出一条来，根据一定算法，变成RETE推理网络的节点。不断循环将所有规则都处理完，RETE推理网络就生成了。RETE网络主要分为两个部分，alpha网络和beta网络。alpha网络：过滤working memory，找出符合规则中每一个模式的集合，生成alpha memory(满足该模式的集合)。有两种类型的节点，过滤type的节点和其他条件过滤的节点；Beta网络：有两种类型的节点Beta Memory和Join Node。前者主要存储Join完成后的集合。后者包含两个输入口，分别输入需要匹配的两个集合，由Join节点做合并工作传输给下一个节点。

RETE算法主要改进Match的处理过程，通过构建一个网络进行匹配。请参见图5，其具体过程如下：

1、创建root节点(根节点)，推理网络的入口。

2、拿到规则1，从规则1中取出模式1(模式就是最小的原子条件，所以规则模式的关系是1：n)。

a)检查模式1中的参数类型，如果是新类型，添加一个类型节点。

b)检查模式1对应的Alpha节点是否存在，如果存在记录下节点的位置；如果没有，将模式1作为一个Alpha节点加入到网络中，同时根据Alpha节点建立Alpah内存表。

c)重复b，直到处理完所有模式。

d)组合Beta节点：Beta(2)左输入节点为Alpha(1)，右输入节点为Alpha(2)；Beta(i)左输入节点是Beta(i-1),右输入节点为Alpha(i)，并将两个父节点的内存表内联成为自己的内存表

e)重复d，直到所有Beta节点处理完毕

f)将动作Then部分封装成最后节点做为Beta(n)

3、重复2，直到所有规则处理完毕

该平台还可包括Web service模块，所述Web service模块与所述ESB企业服务总线联接，所述Web service模块对外提供一个能够通过Web进行调用的API。Web service就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。用户能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web service应用程序叫做客户。Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。平台无关性是Web service的重要特征，可以使用任何语言进行Web service服务和客户端的开发。Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型***。要实现互操作性，Web service平台必须提供一套标准的类型***，用于沟通不同平台、编程语言和组件模型中的不同类型***。在传统的分布式***中，基于界面(interface)的平台提供了一些方法来描述界面、方法和参数。同样的，Webservice平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。

进一步地，所述Web service模块可设有与平台和编程语言无关的远程过程调用协议(RPC)。

进一步地，所述ESB企业服务总线可采用事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，传输多种数据，并提供多种标准接口。

进一步地，所述BI智能商务模块可包括即席分析子模块、模板分析子模块、数据挖掘子模块；所述即席分析子模块可允许用户任意选择指标、维度和过滤条件，生成多维分析表、查询结果以及统计图形；所述模板分析子模块可提供可视化设计工具，定义各种分析报表、查询模板以及统计图模板；所述数据挖掘子模块可采用各种数学分析方法对数据仓库中的数据进行分析，提供数据特性进行决策。

上述数学分析方法可包括聚类分析、预测分析、回归分析以及相关分析；所述聚类分析包括层次聚类算法、KMean聚类算法、快速聚类算法；所述预测分析包括趋势预测模型、ARIMA预测模型、季节预测模型以及神经网络模型；所述回归分析包括线性回归、非线性回归以及Logistic。

即席分析子模块(Easy OLAP)，提供灵活方便的操作界面，允许用户任意选择指标、维度和过滤条件等，快速生成多维分析表、查询结果、统计图形等。它可以让使用者只需通过简单的鼠标拖拽操作就实现数据的分析展现。即席分析子模块(Easy OLAP)不但操作简单，而且还支持钻取、切片、旋转等，支持多维操作；内嵌的增幅/增减额、TOPN/TOP％分析、80/20分析以及常用的标准差离散度等数理统计分析都可直接通过菜单选取，同时也允许用户设置过滤条件。

即席分析子模块可实现以下功能：(1)可方便进行猜想式、求证式分析，极大提升报表分析的交互能力。(2)操作灵活简单，向导式操作，无需报表设计操作。(3)能满足突发数据分析的需求。(4)无需写SQL语句，适合业务人员操作。

模板分析子模块可提供模板化的可视化设计工具，定义各种分析报表、查询模板、统计图模板等。即席分析能实现各种临时的分析查询，但其展现形式不够丰富，版面编辑能力弱，模板功能弥补了这些不足。该平台的模板功能提供图形化设计界面，操作简单易用，表现形式丰富多样，充分满足预设的业务需求，更提供图形和富文本等数据表现形式，充分满足各种个性化需求。模板分析子模块可实现以下功能：

(1)简单易用的界面编辑功能：WEB方式的设计器不仅可以减小项目实施的部署工作量，而且便于用户随时随地编辑报表。设计器采用所见即所得方式，操作界面类似EXCEL，支持合并拆分单元格、任意表头、多级斜线、富文本以及无限Undo&Redo等功能。

(2)富文本功能：富文本是指采用丰富多彩的颜色、样式来修饰一段文字或其中的某一部分，使文字看起来更加美观、醒目。本平台***可以轻松支持业务人员生成图文并茂的分析报告。

(3)灵活的钻取功能：模板分析子模块可以通过数据钻取，使用户对数据的了解更深入，更容易发现问题，制定符合需求的核保规则。在报表模板中可以非常简单的定义任意的钻取流程，钻取在报表、统计图和地图中都可以定义，而且针对不同的情况，提供了丰富多样的钻取表现形式。同时钻取时***能够自动收集部分相关的参数，很少需要用户定义参数。而且在实际中，许多报表都包含维度，这样的分析表会自动生成钻取。

数据挖掘子模块，采用一些比较高级的数学统计以及人工智能等领域的分析方法对数据仓库中的数据进行分析，以直观的统计图和其它分析结果来帮助用户了解数据的特性从而进行决策。数据挖掘是从大量数据中提取或挖掘知识，该平台提供了丰富的数据挖掘方法：聚类分析(层次聚类算法、KMean聚类算法、快速聚类算法等)，预测分析(趋势预测模型、ARIMA预测模型、季节预测模型、神经网络模型)、回归分析(线性回归、非线性回归、Logistic回归)、相关分析等。

图2为该基于规则引擎的智能核保平台的一个工作流程实例，其流程如下：

a)输入客户信息到规则引擎中

b)后台进行KMeans聚类算法和预测分析

c)***将返回的结果进行回归分析

d)存入规则库

e)通过WEB Service模块调用WEB API标准接口

f)再通过分布式运算管理机制，生成多维分析表

g)通过规则引擎中的筛选器进行筛选核保规则，可供用户进行查询

该平台通过BI对大量业务数据的收集、管理和挖掘，智能分析出新的保险核保规则，从而对保险产品核保提供有效的支持。这是一种***工具平台，可以使核保师获得更多有用的信息并提高洞察力，做出更加有效的核保规则，并且不断完善现有的规则。

该平台使用BI智能商务模块技术与智能核保规则引擎相结合，其核心工作就是给保险公司核保人员提供简单、易用的软件产品和功能，使其能够从大量的数据中发现有价值的信息，从而根据这些信息制定相应的核保规则等。

为使核心业务***具备高可用性、高可靠性、可伸缩性以及可扩展性，并具备灵活性、易用性的特点。采用J2EE作为***的技术平台，J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE体系结构提供中间层集成框架而又通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持Enterprise JavaBean，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。J2EE为搭建具商务***提供了良好的机制。请参加图6，J2EE使用多层分布式的应用模型，这个多层通常通过三层或四层来实现：客户层：运行在客户计算机上的组件；Web层：运行在J2EE服务器上的组件；业务层，同样是运行在J2EE服务器上的组件；企业信息***层(EIS)或企业数据库，是指运行在EIS服务器上的软件***。以上层次一般也指三层应用，因分布在三个不同位置：客户计算机、J2EE服务器及后台的数据库或过去遗留下来的***。其中应用程序客户端是指运行在客户计算机上的组件；基于Java Servlet和JSP技术的组件叫Web组件，它们运行在服务器上；enterprise(企业)Bean组件叫业务组件(EB)，同样运行在服务器上。J2EE客户端可以是一个Web组件或者是一个应用程序客户端。Web客户端包括两部分，首先是那些动态Web页面(HTML、XML等)，这些组件运行在Web层；另一个是Web浏览器，由客户机上的浏览器从服务器接收并且解析和显示Web页面。J2EE应用程序客户端运行在客户机上，能提供强大而灵活易用的用户界面，如使用Swing或AWT创建的图形化的用户界面(GUI)。应用程序可直接访问运行在业务层的企业Bean，如果需求允许，也可以打开HTTP连接来建立与运行在Web层上的Servlet之间的通讯。JavaBean组件架构在服务器和客户端两层中也可能包括了基于JavaBean的组件架构，通过JavaBean来实现数据的流动，可以是在应用程序客户或Applet与运行在J2EE服务器上的组件之间，或者是在J2EE服务器和后台数据库之间。客户层与J2EE服务器上运行的业务层之间的通讯可以是直接的，也可以通过运行在Web层中的Servlet和JSP来实现，在这种情况下，客户运行在浏览器中。J2EE的Web组件可以是Servlet或JSP页面。在应用程序组装过程中，静态HTML页面和Applet也可以一起打包成Web组件，但这并不是J2EE规范所认可的Web组件。业务组件中的业务代码是指那些由位于业务层的企业Bean(EB)执行的逻辑，它们能够解决或满足特定的商业领域的一些需求。有三种不同类型的企业Bean：会话Bean、实体Bean和消息驱动Bean。会话Bean代表客户一次短暂的会话过过程，当客户执行完成后，会话Bean以及它所包含的数据也随之消失。实体Bean代表的是持久的数据，即存储在数据库表中的一行记录，即使客户终止或者服务器关闭，在J2EE底层的会服务确保实体Bean的数据被保存下来。而实体Bean又分为Bean管理实体Bean和容器管理实体Bean。由于这种Bean对应于数据库中的记录，所以数据库记录的任何改变也被同步到组件池中的相关Bean中，这个过程叫做持久性(persistenced)，这是实体Bean最重要的一个特征。根据持久性操作方式的不同分为：容器管理持久性(Container-Managed Persistence，CMP)和Bean管理持久性(Bean－Managed Persistence，BMP)。容器即container,一个实体，它管理着组件的生命周期、安全、部署和运行时服务。每个类型的容器都只提供与相应类型的组件相关的服务，如EB、Web、JSP、Applet和应用程序客户端。其中，EB容器和Web容器都运行在J2EE服务器中。

尽管上面结合附图对本发明的优选实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，并不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可以做出很多形式，这些均属于本发明的保护范围之内。

Claims (8)

1.一种基于规则引擎的智能核保平台，其特征在于，该平台基于SOA架构体系，该平台设有BI智能商务模块、ESB企业服务总线、规则引擎模块、数据库以及规则库；所述数据库用于组织、存储和管理业务数据；所述规则库用于组织、存储和管理规则数据；所述BI智能商务模块，用于对业务数据进行收集、管理和挖掘；所述ESB企业服务总线，用于提供开放的接口，联接所述BI智能商务模块、所述规则引擎模块和所述数据库；所述规则引擎模块用于解析、调用、执行以及生成规则包，所述规则引擎模块包括规则生成器，所述规则生成器输入来自所述BI智能商务模块、所述数据库和所述规则库的数据，生成核保规则包并输出至所述规则库中。

2.根据权利要求1所述的基于规则引擎的智能核保平台，其特征在于，所述规则引擎模块还包括规则生命周期子模块、规则查询子模块、用户操作锁定子模块、规则历史轨迹子模块以及预警子模块；所述规则生命周期子模块用于控制规则的验证与部署；所述规则查询子模块用来查询、更新与部署规则；所述用户操作锁定子模块用于管理多用户同时操作；所述规则历史轨迹子模块用来跟踪和管理规则的变化；所述预警子模块提供用户定义机制，用户针对某一量值的大小或两个量值之间的关系，来定义异常状况，并以改变字形颜色或***警示图案的方式来加以提示，支持字体颜色、背景色、特殊符号、个性化图形方式进行预警。

3.根据权利要求1所述的基于规则引擎的智能核保平台，其特征在于，所述规则引擎模块采用RETE模式匹配算法。

4.根据权利要求1所述的基于规则引擎的智能核保平台，其特征在于，该平台还包括Web service模块，所述Web service模块与所述ESB企业服务总线联接，所述Webservice模块对外提供一个能够通过Web进行调用的API。

5.根据权利要求4所述的基于规则引擎的智能核保平台，其特征在于，所述Webservice模块设有与平台和编程语言无关的远程过程调用协议。

6.根据权利要求1所述的基于规则引擎的智能核保平台，其特征在于，所述ESB企业服务总线采用事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，传输多种数据，并提供多种标准接口。

7.根据权利要求1所述的基于规则引擎的智能核保平台，其特征在于，所述BI智能商务模块包括即席分析子模块、模板分析子模块和数据挖掘子模块；所述即席分析子模块允许用户任意选择指标、维度和过滤条件，生成多维分析表、查询结果以及统计图形；所述模板分析子模块提供可视化设计工具，定义各种分析报表、查询模板以及统计图模板；所述数据挖掘子模块采用数学分析方法对数据仓库中的数据进行分析，提供数据特性进行决策。

8.根据权利要求7所述的基于规则引擎的智能核保平台，其特征在于，所述数学分析方法包括聚类分析、预测分析以及回归分析；所述聚类分析包括层次聚类算法、KMeans聚类算法、快速聚类算法；所述预测分析包括趋势预测模型、ARIMA预测模型、季节预测模型以及神经网络模型；所述回归分析包括线性回归、非线性回归以及Logistic回归。