专利名称：资源管理平台中的规则管理器的制作方法
技术领域：
本发明涉及资源管理技术，更具体地说，涉及资源管理平台中的规则管理器。
背景技术：
随着网络技术的不断发展，资源共享逐渐成为许多企业级应用迫切的需求。虽然目前一些应用系统实现了部分共享的功能，但很多情况下，这种共享只限于存取有限网络内的资源或为有限网络内提供资源，不能满足更普遍、更广泛共享的需求。
通常的应用系统无法做到这种普遍、广泛共享的原因主要有两点一是应用系统用户出于安全保密性的考虑，不愿将所有资源对外开放；二是即使应用系统用户愿意甚至需要将一部分资源对外开放，但却没有一种统一的途径使其资源安全、可靠地开放。
开放资源的一个前提是实现有效的资源转换，在资源转换的过程中，经常需要使用到“求值器”，“求值器”的功能是输入一组参数通过一定的规则处理后输出返回的结果，其功能接近于常用的“函数”。于是，就需要一种能有效维护用于资源转换过程中需要使用的规则的手段。
发明内容
本发明的目的是提供一种能有效维护用于资源转换过程中需要使用的规则的手段。
本发明采用如下的方式实现，提供一种资源管理平台中的规则管理器，该规则管理器以插件的形式运行于资源管理平台的一平台内核上，该平台内核向以插件形式运行的规则管理器提供调用资源并管理所述规则管理器，其中，该规则管理器包括规则管理器插件，提供规则服务；
规则管理器工具插件，将所述规则管理器连接到一数据引擎，以使数据引擎能够使用规则管理器的功能；还向所述规则管理器插件提供预定的资源。
其中，该规则管理器插件提供规则器扩展点，该规则器扩展点是一个被命名的接口，该规则管理器插件还提供规则服务扩展，该规则服务扩展是规则器扩展点和实现该规则器扩展点的扩展者的命名连接；而该规则管理器工具插件提供的求值器构造器扩展和一组预定义规则器扩展，该求值器构造器扩展和一组预定义规则器扩展是命名连接。
作为该规则管理器运行基础的资源管理平台的平台内核包括内核插件，内核插件是规则管理器插件和规则管理器工具插件的原始根，包括基础扩展点，基础扩展点是供规则管理器插件和规则管理器工具插件使用的接口；基础扩展者，基础扩展点的接口实现，基础扩展者是可被规则管理器插件和规则管理器工具插件调用的扩展者；插件系统，内核插件、规则管理器插件和规则管理器工具插件需要向插件系统进行注册，插件系统还保存内核插件、规则管理器插件和规则管理器工具插件之间的关联关系；的规则管理器插件和规则管理器工具用于实现扩展点，扩展点是一个被命名的接口；扩展者，所述扩展点的接口实现；扩展，所述扩展点和实现该扩展点接口的扩展者的命名连接；非内核插件通过实现扩展点、扩展者和扩展来调用可扩展资源管理平台的资源。
该规则管理器插件提供规则服务，规则服务包括活动规则器查询、活动映射器查询以及映射器的注册和注销。
其中，规则器是所述规则管理器插件定义的一个扩展点，用于输入一组参数，进行求值后将结果返回；每个规则器名字由规则器扩展者连接到规则器扩展点的扩展所定义；规则器使用元数据描述规则器接收的输入参数类型、返回值类型以及规则器的功能。
而映射器是一个实体，包含一组“源-目标”的值映射；映射器使用元数据描述映射器的源、目标类型，以及映射器的功能；每个映射器包含一组映射条目，每个条目由一个源和一个目标组成。
规则管理器工具插件中的求值器构造器扩展用于完成指定的表达式求值，求值器构造器创建规则求值器和映射求值器，分别用于求解规则表达式和映射表达式。
规则管理器工具插件中的预定义规则器扩展实现字符串连接、取字符串长度、数值比较、条件选择。
采用本发明的技术方案，提供了一种能有效维护用于资源转换过程中需要使用的规则的手段，为建立有效的资源管理提供了基础。
图1示出了可作为本发明的规则管理器的运行基础的可扩展资源管理平台的结构图；图2示出了根据本发明的规则管理器的结构图。
具体实施例方式
本发明提供一种资源管理平台中的规则管理器，该规则管理器以插件的形式运行于资源管理平台的一平台内核上，平台内核向以插件形式运行的规则管理器提供调用资源并管理规则管理器。
首先介绍一下可以用于实现本发明的资源管理平台，该资源管理平台也可以视为是本发明的规则管理器的运行基础。参考图1所示，该资源管理平台100包括平台内核102，平台内核102包括，内核插件120，内核插件是非内核插件140的原始根，包括基础扩展点122，基础扩展点是供非内核插件140使用的接口；基础扩展者124，基础扩展点的接口实现，基础扩展者是可被非内核插件140或者平台外部应用调用的扩展者；插件系统126，内核插件120和非内核插件140需要向插件系统126进行注册，插件系统126还保存内核插件120与非内核插件140、以及非内核插件140与非内核插件140之间的关联关系；非内核插件140，非内核插件与特定的功能相关，非内核插件用于实现扩展点104，扩展点104是一个被命名的接口；扩展者106，扩展点104的接口实现；扩展108，扩展点104和实现该扩展点接口的扩展者106的命名连接；非内核插件140通过实现扩展点104、扩展者106和扩展108来调用可扩展资源管理平台100的资源。
本发明的规则管理器就是运行于上述的资源管理平台100之上，参考图2所示，该规则管理器200包括规则管理器插件202，提供规则服务。根据本发明的一实施例，规则管理器插件202提供规则器扩展点，该规则器扩展点是一个被命名的接口，该规则管理器插件202还提供规则服务扩展，该规则服务扩展是规则器扩展点和实现该规则器扩展点的扩展者的命名连接。
规则管理器工具插件204，将规则管理器200连接到一数据引擎，以使数据引擎能够使用规则管理器200的功能；还向规则管理器插件202提供预定的资源。同样根据本发明的一实施例，该规则管理器工具插件204提供的求值器构造器扩展和一组预定义规则器扩展，该求值器构造器扩展和一组预定义规则器扩展是命名连接。
于是，本发明的规则管理器运行于上述图1所示的资源管理平台，形成如下的结构该资源管理平台的平台内核包括内核插件，内核插件是规则管理器插件和规则管理器工具插件的原始根，包括基础扩展点，基础扩展点是供规则管理器插件和规则管理器工具插件使用的接口；基础扩展者，基础扩展点的接口实现，基础扩展者是可被规则管理器插件和规则管理器工具插件调用的扩展者；插件系统，内核插件、规则管理器插件和规则管理器工具插件需要向插件系统进行注册，插件系统还保存内核插件、规则管理器插件和规则管理器工具插件之间的关联关系；的规则管理器插件和规则管理器工具运行与上述的平台内核之上，用于实现扩展点，扩展点是一个被命名的接口；扩展者，扩展点的接口实现；扩展，扩展点和实现该扩展点接口的扩展者的命名连接；非内核插件通过实现扩展点、扩展者和扩展来调用可扩展资源管理平台的资源。
继续参考图2，该规则管理器插件202提供规则服务，该规则服务包括活动规则器查询、活动映射器查询以及映射器的注册和注销。
其中，所述的规则器是规则管理器插件定义的一个扩展点，用于输入一组参数，进行求值后将结果返回。每个规则器名字由规则器扩展者连接到规则器扩展点的扩展所定义。且规则器使用元数据描述规则器接收的输入参数类型、返回值类型以及规则器的功能。
而所述的映射器是一个实体，包含一组“源-目标”的值映射。映射器使用元数据描述映射器的源、目标类型，以及映射器的功能。每个映射器包含一组映射条目，每个条目由一个源和一个目标组成。
规则管理器工具插件204提供求值器构造器扩展和一组预定义规则器扩展。其中求值器构造器扩展用于完成指定的表达式求值，求值器构造器创建规则求值器和映射求值器，分别用于求解规则表达式和映射表达式。而预定义规则器扩展实现字符串连接、取字符串长度、数值比较、条件选择。
下面介绍本发明的具体实现。
资源管理平台的实现的基本架构在本发明中，平台内核(Core)是整个可扩展资源管理平台的核心部件和基础。本发明的可扩展资源管理平台采用插件(Plugin)方式实现，所有插件彼此独立，平台内核负责维护所有插件间的关联。内核提供内核插件(Core Plugin)作为所有插件的根。平台内核是一个“轻量级”部件，它本身不实现任何应用的功能需求，只负责完成最基础的插件服务和提供最基础的一组扩展点。在平台内核之上，插入各个功能模块，各个功能模块之上再插入它们特定的插件，最终完成应用特定的功能。
本发明的可扩展资源管理平台采用插件机制，可以很方便地扩展平台功能，而不需改动已有的代码。插件系统是依赖扩展点(Extension Point)、扩展者(Extender)和扩展(Extension)实现的。需要说明的是，本发明的可扩展资源管理平台中，除了平台内核中的内核插件是基础插件，其余的插件都是扩展应用使用的插件，都可以视为非内核插件。在下面的叙述中，“插件”将用于指代非内核插件，而内核插件将专门指名。并且，对于术语“插件”和“非内核插件”，表示同样的概念。
扩展点(Extension Point)就是一个命名的接口。名字唯一标识了该扩展点，而接口说明了该扩展点期望的功能规范。两个不同的扩展点可以具有同样的接口，但不能有同样的名字。如果一个插件期望其功能能够被其他插件扩展，则将此功能接口命名，定义为一个扩展点，而插件本身不需要实现此接口。例如，数据引擎(Data Engine)插件需要读取某个数据源的数据，但是不同的数据源(例如JDBC数据源和XML文档数据源)具有不同的存取方式。数据引擎不期望依赖某种特定的实现读取特定的数据源，因此定义了适配器(Adapter)扩展点。数据引擎本身只操作适配器接口，并不负责适配器的实现。数据引擎将此扩展点注册给内核之后，内核负责将其与其他插件注册的适配器实现关联，从而使数据引擎完全透明地访问适配器实现。
扩展者(Extender)就是一个扩展点接口的实现。扩展者只关心实现，而无须关心谁会使用这个实现。如果两个扩展点定义了同样的接口，那么扩展者本身并不能确定它会被哪一个扩展点使用。一个扩展者可以实现多个扩展点接口。扩展者的实例由扩展者工厂(Extender Home)创建。
扩展(Extension)就是一个扩展点和一个扩展其接口的扩展者的命名连接。一个扩展包含以下信息一个唯一的名字，被扩展的扩展点的名字，以及实现此扩展点接口的扩展者工厂。如果一个插件期望扩展其他插件的扩展点，则必须实现相应的扩展者，提供相应的扩展者工厂，并向内核注册相应的扩展。内核负责将扩展者与扩展点连接，并在定义扩展点的插件需要的时候，利用扩展者工厂创建扩展者实例，提供给此插件使用。通常将扩展的名字也叫做扩展所连接的扩展者的名字。
平台内核的实现在本发明的平台内核中，提供了一个基础的插件，内核插件。内核插件(Core Plugin)是平台最底层的基础插件，是所有插件插入的原始根。内核插件定义了平台的最底层基础扩展点服务(Service)。内核插件不同于普通的独立插件，它是平台内核的一部分。
服务就是平台对外的功能接口，是应用相关的功能集合。一个平台内核本身是一个“轻量级”部件，它只维护插件关联，而并不实现任何特定的功能需求。如果某个插件需要对外开放某些特定的功能，则其需要将此组功能定义为一个服务，并依赖内核插件导出。例如，规则管理器(RuleManager)需要对外提供一组维护规则的操作接口，则它需要将这组操作定义为一个实现了服务扩展点接口的扩展者——规则服务(Rule Service)，并将其通过一个扩展与内核插件的服务扩展点相连接，以后当用户需要使用规则服务的时候，就可以使用此扩展的名字向内核借用(borrow)服务。
每个服务都是一个扩展者，它扩展了内核插件的服务扩展点；将服务和内核服务扩展点连结起来的扩展的名字也被定义为服务的名字。服务作为扩展者不同于其他普通扩展者的区别在于，服务直接由内核对外导出，作为平台功能的统一入口，由其他应用使用；而普通扩展者则不被外部应用所知，只由其对应扩展点的提供插件使用。服务可以对外被平台外部的应用调用，也可以对内被其他插件使用。
日志服务(Log Service)是内核插件提供的基础服务。系统中的所有插件都可以使用此服务完成日志记录。记录器(Logger)是内核插件定义的用于实现日志服务的扩展点。内核插件的日志服务会使用连接到此扩展点上的记录器完成日志的记录。当日志服务被调用时，内核插件会轮流调用所有已经连接的记录器完成日志的记录。如果没有任何一个记录器接收该记录，则内核插件会将日志记录到标准输出(stdout)或标准错误(stderr)设备上。不同的日志发起者(Log Originator)可能会具有不同的日志消息格式，只有特定的针对此发起者的记录器能识别和记录其消息。
平台内核中的另一个重要的的部件是插件系统，插件系统负责所有插件，包括内核插件和非内核插件的注册；并维护所有插件，包括内核插件和非内核插件之间的关联关系。
所有的插件，包括内核插件和非内核插件都必须向内核注册。静态插件在内核启动时由内核注册，动态插件在内核启动后由应用程序注册。插件由名字唯一标识。不同版本的同名插件只有最高版本有效。如果某一插件的低版本已经注册，又试图注册更高的版本，那么高版本必须完全兼容低版本定义的所有扩展点和扩展。
每个插件拥有一个初始化顺序(Initialization Order)，决定了其注册顺序。内核插件永远是第一个初始化的，它的初始化顺序为0。其他插件则必须按照依赖关系定义初始化顺序。例如数据引擎插件只依赖内核插件，其初始化顺序为1；而数据引擎工具插件依赖数据引擎插件，其初始化顺序为2。初始化顺序只对平台启动时加载的静态插件有效。对于平台启动后注册的动态插件，初始化顺序即为其注册的顺序。
提供扩展点的插件称为宿主插件(Host Plugin)，提供扩展的插件称为从属插件(Dependent Plugin)。一个插件可以同时是宿主插件和从属插件。因为从属插件依赖于相关的宿主插件，因此从属插件必须在宿主插件注册之后注册。
平台内核中的插件系统还负责维护插件与插件间(包括内核插件与非内核插件以及非内核插件与非内核插件间)的扩展关联。一个提供扩展点的插件需要使用扩展功能时，首先向内核借用(borrow)连接到此扩展点上的扩展者，然后利用扩展者完成需要的功能，最后将扩展者归还(revert)。提供扩展点的插件操作扩展者时仅按照扩展点定义的接口操作，而不必关心扩展者的实现或是谁提供了扩展者，从而实现插件功能的透明扩展。
平台内核依赖内核插件对外提供服务。内核本身不关心服务的实现。外部应用或其他插件需要使用服务时，首先按照服务扩展的名字向内核借用服务，使用完成之后将服务归还。
规则管理器(Rule Manager)规则管理器负责维护用于资源转换过程中需要使用的“求值器(Evaluator)”。求值器分为两类规则器(Ruler)和映射器(Mapper)。
规则管理器由规则管理器插件和规则管理器工具插件构成。
规则器(Ruler)是规则管理器插件定义的一个扩展点接口。它的功能是输入一组参数，求值后，将结果返回。规则器类似于“函数(Function)”的功能。
每个规则器的实现本身是一个扩展者，不具有名字。但是规则器扩展者连接到规则器扩展点的扩展具有名字，此扩展的名字就被定义为规则器的名字。规则器的名字类似于“函数名(Function Name)”。
规则器元数据(Ruler Metadata)描述了规则器接收的输入参数类型、返回值类型以及规则器的功能。例如，一个完成连接字符串操作的规则器，要求输入参数个数为2，参数类型均为String，返回值也为String。元数据信息用于给外部可视化应用动态定义转换绑定(Binding)使用。元数据类似于“函数声明和文档(Function Declaration and Documents)”。
每个规则器都有一个具体的实现。实现将被其他插件调用，完成功能。调用实现时，由调用者负责提供参数的值(实参)。实现类似于“函数实现(Function Implementation)”。
映射器(Mapper)是一个实体(并非扩展点)，它包含一组“源——目标”的值映射。所有的映射器都可以用规则器实现。但是由于规则器本身是一个代码实现，而映射器只是一组值，因此用规则器实现映射功能不如映射器灵活。
类似于规则器，每个映射器都必须有一个唯一标识的名字。
映射器元数据(Mapper Metadata)描述了映射器的源、目标类型，以及映射器的功能。例如，一个将布尔值映射为整数值的映射器，其源类型为BOOL，目标类型为INTEGER，功能是将True映射为1，False映射为0。类似于规则器元数据，映射器元数据信息也用于给外部可视化应用动态定义转换绑定(Binding)使用。
每个映射器包含一组映射条目(Entry)。每个条目由一个源(Source)，和一个目标组成(Target)。例如上述的布尔值到整数值映射器，它将包含两个条目第一个条目的源是True，目标是1；第二个条目的源是False，目标是0。所有条目的源不能重复(但目标可以重复)，而且每个条目的源和目标都必须符合元数据中定义的源、目标类型(或NULL)。
规则管理器插件(Rule Manager)是规则管理器的核心插件。它对外提供规则服务，并负责维护规则器和映射器。
规则服务(Rule Service)是规则管理器对外开放的服务接口，它扩展了内核的服务扩展点。规则服务主要包括活动规则器查询，规则器本身是由外部插件实现的，该功能用于查询已经注册到规则管理器规则器扩展点的所有活动规则器(Active Ruler)。活动规则器不同于规则器，它只包含了对应规则器的描述信息，并不包括规则器的实现。
活动映射器查询，该功能用于查询已经注册到规则管理器的活动映射器(Active Mapper)。活动映射器不同于映射器，它只包含了对应映射器的描述信息，并不包括映射器的映射条目。
映射器注册/注销，由于映射器是一个实体，它不包含代码实现，因此可以直接向规则管理器注册或注销(Add/Remove)。对于不同于映射器，规则器由于是代码实现，因此规则器必须由某个外部插件提供，并利用内核插件注册的功能注册到规则管理器。
规则管理器定义了规则器扩展点，可以由其他插件实现。如果需要为规则管理器加入新的可供使用的规则器，只需要将规则器实现的插件注册给内核即可。规则管理器会动态地向内核查询可用的规则器扩展者。利用规则服务的“映射器注册/注销”和规则管理器插件的“规则器扩展点”，规则管理器实现了完全动态的、可扩展的规则管理机制。
规则管理器工具插件(Rule Manager Utility)是规则管理器的辅助插件，它依赖于规则管理器插件。规则管理器工具插件一方面负责将规则管理器与数据引擎相连，以使数据引擎能够使用规则管理器的功能；另一方面负责向规则管理器插件的规则器扩展点提供部分缺省的“预定义规则器”以方便应用的开发。
求值器构造器(Evaluator Maker)是数据引擎定义的一个扩展点，用于完成指定的表达式(Expression)求值。求值器构造器负责创建两类求值器规则求值器(Rule Evaluator)和映射求值器(Mapping Evaluator)，分别用于求解规则表达式(Rule Expression)和映射表达式(MappingExpression)。
规则管理器工具插件向内核注册了一个求值器构造器的扩展，从而将规则管理器与数据引擎有机地结合起来。
规则管理器工具插件向内核注册了一组预定义规则器扩展，这组预定义规则器包含了一些比较通用的规则器，例如字符串连接、取字符串长度、数值比较、条件选择等。
应用可以根据实际情况选择使用预定义规则器或自己实现新的规则器插件。
采用本发明的技术方案，提供了一种能有效维护用于资源转换过程中需要使用的规则的手段，为建立有效的资源管理提供了基础。
权利要求
1.一种资源管理平台中的规则管理器，其特征在于，该规则管理器以插件的形式运行于资源管理平台的一平台内核上，所述平台内核向所述以插件形式运行的规则管理器提供调用资源并管理所述规则管理器，其中，所述规则管理器包括规则管理器插件，提供规则服务；规则管理器工具插件，将所述规则管理器连接到一数据引擎，以使数据引擎能够使用规则管理器的功能；还向所述规则管理器插件提供预定的资源。
2.如权利要求1所述的规则管理器，其特征在于，所述规则管理器插件提供规则器扩展点，该规则器扩展点是一个被命名的接口，该规则管理器插件还提供规则服务扩展，该规则服务扩展是所述规则器扩展点和实现该规则器扩展点的扩展者的命名连接；而该规则管理器工具插件提供的求值器构造器扩展和一组预定义规则器扩展，该求值器构造器扩展和一组预定义规则器扩展是命名连接。
3.如权利要求2所述的规则管理器，其特征在于，所述平台内核包括内核插件，所述内核插件是所述规则管理器插件和规则管理器工具插件的原始根，包括基础扩展点，基础扩展点是供规则管理器插件和规则管理器工具插件使用的接口；基础扩展者，基础扩展点的接口实现，基础扩展者是可被规则管理器插件和规则管理器工具插件调用的扩展者；插件系统，内核插件、规则管理器插件和规则管理器工具插件需要向插件系统进行注册，插件系统还保存内核插件、规则管理器插件和规则管理器工具插件之间的关联关系；所述的规则管理器插件和规则管理器工具用于实现扩展点，扩展点是一个被命名的接口；扩展者，所述扩展点的接口实现；扩展，所述扩展点和实现该扩展点接口的扩展者的命名连接；所述非内核插件通过实现扩展点、扩展者和扩展来调用可扩展资源管理平台的资源。
4.如权利要求3所述的规则管理器，其特征在于，所述规则管理器插件提供规则服务，所述规则服务包括活动规则器查询、活动映射器查询以及映射器的注册和注销。
5.如权利要求4所述的规则管理器，其特征在于，所述规则器是所述规则管理器插件定义的一个扩展点，用于输入一组参数，进行求值后将结果返回；其中，每个规则器名字由规则器扩展者连接到规则器扩展点的扩展所定义；所述规则器使用元数据描述规则器接收的输入参数类型、返回值类型以及规则器的功能。
6.如权利要求4所述的规则管理器，其特征在于，所述映射器是一个实体，包含一组“源—目标”的值映射；所述映射器使用元数据描述映射器的源、目标类型，以及映射器的功能；每个映射器包含一组映射条目，每个条目由一个源和一个目标组成。
7.如权利要求3所述的规则管理器，其特征在于，所述求值器构造器扩展用于完成指定的表达式求值，所述求值器构造器创建规则求值器和映射求值器，分别用于求解规则表达式和映射表达式。
8.如权利要求3所述的规则管理器，其特征在于，所述预定义规则器扩展实现字符串连接、取字符串长度、数值比较、条件选择。
全文摘要
本发明揭示一种资源管理平台中的规则管理器，该规则管理器以插件的形式运行于资源管理平台的一平台内核上，平台内核向以插件形式运行的规则管理器提供调用资源并管理所述规则管理器，其中，规则管理器包括规则管理器插件，提供规则服务；规则管理器工具插件，将规则管理器连接到一数据引擎，以使数据引擎能够使用规则管理器的功能；还向所述规则管理器插件提供预定的资源。采用本发明的技术方案，提供了一种能有效维护用于资源转换过程中需要使用的规则的手段，为建立有效的资源管理提供了基础。
文档编号G06F9/44GK101075189SQ20071004200
公开日2007年11月21日 申请日期2007年6月14日 优先权日2007年6月14日
发明者高念高, 孙圭宁, 秦克明 申请人:上海众恒信息产业有限公司