CN101276269A - 可扩展资源管理平台 - Google Patents

Abstract

本发明揭示一种可扩展资源管理平台，包括：平台内核，平台内核包括内核插件和插件系统，内核插件是非内核插件的原始根，提供基础扩展点和基础扩展者；插件系统进行插件的注册，插件系统还保存内核插件与非内核插件、以及非内核插件与非内核插件之间的关联关系；该可扩展资源管理平台的非内核插件与特定的功能相关，非内核插件用于实现扩展点、扩展者和扩展，非内核插件通过实现扩展点、扩展者和扩展来调用可扩展资源管理平台的资源。非内核插件实现的功能包括规则管理器、数据引擎、主题分发器和资源管理器。本发明的可扩展资源管理平台负责对各种不同种类的资源进行整合和维护，维持数据的一致性；资源使用方则以一种完全透明的方式访问资源。有效解决了资源共享的各种问题。

Description

可扩展资源管理平台

技术领域

本发明涉及资源管理技术，更具体地说，涉及一种可扩展资源管理平台及资源管理方法。

背景技术

随着网络技术的不断发展，资源共享逐渐成为许多企业级应用迫切的需求。虽然目前一些应用系统实现了部分共享的功能，但很多情况下，这种共享只限于存取有限网络内的资源或为有限网络提供资源，不能满足更普遍、更广泛共享的需求。

通常的应用系统无法做到这种普遍、广泛共享的原因主要有两点：一是应用系统用户出于安全保密性的考虑，不愿将所有资源对外开放；二是即使应用系统用户愿意甚至需要将一部分资源对外开放，但却没有一种统一的途径使其资源安全、可靠地开放。

发明内容

本发明的目的是提供一种统一并且可扩展的资源管理平台(UniversalResource Management Platform)，针对上述问题，对资源进行统一管理。统一可扩展资源管理平台是一个“资源服务提供者”(Resource ServiceProvider)，它的目标是为各种“资源服务客户”(Resource ServiceClient)--资源提供者(Resource Provider)和资源使用者(ResourceConsumer)--提供资源采集(Provide)、资源整合(Integrate)、资源传送(Transport)、资源订阅/接收/获取(Subscribe/Receive/Consume)等各种资源服务。

资源提供方向平台注册要开放的资源，通过平台代理开放，从而可以有效保证提供方本地资源的安全性；平台负责对各种不同种类的资源进行整合和维护，维持数据的一致性；资源使用方则以一种完全透明的方式访问资源。

根据本发明的一方面，提供一种可扩展资源管理平台，其特征在于，包括：

平台内核，平台内核包括：

内核插件，内核插件是非内核插件的原始根，包括：

基础扩展点，基础扩展点是供非内核插件使用的接口；

基础扩展者，基础扩展点的接口实现，基础扩展者是可被非内核插件或者平台外部应用调用的扩展者；

插件系统，内核插件和非内核插件需要向插件系统进行注册，插件系统还保存内核插件与非内核插件、以及非内核插件与非内核插件之间的关联关系；

非内核插件，非内核插件与特定的功能相关，非内核插件用于实现：

扩展点，扩展点是一个被命名的接口；

扩展者，扩展点的接口实现；

扩展，扩展点和实现该扩展点接口的扩展者的命名连接；

非内核插件通过实现扩展点、扩展者和扩展来调用可扩展资源管理平台的资源。

其中，内核插件提供的基础扩展点为服务扩展点，而基础扩展者为服务；根据一例，内核插件提供的基础扩展点以及基础扩展者包括：日志服务点，提供日志服务，可扩展资源管理平台中的所有非内核插件使用日志服务点提供的日志服务进行日志记录；该日志服务点连接到记录器，内核插件的日志服务使用记录器完成日志记录。

本发明的内核插件和非内核插件中的每一个具有一初始化顺序，内核插件和非内核插件在插件系统注册时根据其初始化顺序决定注册顺序；其中，初始化顺序由插件之间的依赖关系确定。

提供扩展点的非内核插件需要使用扩展时，向平台内核借用连接到此扩展点上的扩展者，利用扩展者完成需要的功能，使用完毕后将扩展者归还平台内核。

本发明的可扩展资源管理平台还提供：程序级接口，供平台内核与非内核插件使用；以及应用级接口，供可扩展资源管理平台外部的应用使用。

根据一例，非内核插件包括规则管理器插件和规则管理器工具插件，实现规则管理器的功能，用于管理资源的转换；规则管理器插件提供的扩展点包括规则器扩展点，规则管理器插件提供的扩展包括规则服务；其中，规则器用于实现映射器，规则服务管理所述规则器和映射器；规则管理器插件提供的扩展包括求值器构造器和一组预定义规则器。

根据第二例，非内核插件包括数据引擎插件、数据引擎工具插件和任务处理器插件，实现数据引擎的功能，用于完成资源转换任务的解释和执行；数据引擎插件提供的扩展点包括适配器扩展点，求值器构造器扩展点以及通知器扩展点，数据引擎插件提供的扩展包括数据服务，数据服务用于活动适配器查询、活动任务管理；数据引擎工具插件提供的扩展包括传输器、任务记录器以及一组缺省的适配器；任务处理器插件用于集中处理任务，包括从任务队列取得任务，依赖适配器、求值器构造器和日志服务执行任务，最后利用通知器发布任务成功通知。

根据第三例，非内核插件包括主题分发器插件、主题分发器工具插件和主题处理器插件，实现主题分发器功能，用于完成主题的分发；主题分发器插件提供的扩展点包括调用器扩展点；主体分发器插件提供的扩展包括主题服务，主题服务用于活动调用器查询、活动主题管理、活动监听器查询以及监听器管理；主题分发器工具插件提供的扩展包括发布器、主题记录器以及一组缺省的调用器；主题处理器插件用于后台处理主题分发，所述主题处理器从主题队列取得待分发主题，轮询与之相关的已启动监听器，并利用调用器完成主题的分发。

根据第四例，非内核插件包括资源管理器插件和资源管理器工具插件，用于维护表和转换器；资源管理器插件提供的扩展点包括传输器扩展点和发布器扩展点；资源管理器插件提供的扩展包括资源服务；资源服务用于表管理和转换器管理；资源管理器工具插件提供的扩展包括通知器。

采用本发明的技术方案，通过建立统一的可扩展资源管理平台，资源提供方向平台注册要开放的资源，通过平台代理开放，从而可以有效保证提供方本地资源的安全性；平台负责对各种不同种类的资源进行整合和维护，维持数据的一致性；资源使用方则以一种完全透明的方式访问资源。有效解决了资源共享的各种问题。

附图说明

图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的资源。

基于上述的可扩展资源管理平台，本发明还提供一种资源管理方法200，参考图2所示，该方法包括：

202.提供一内核插件，作为非内核插件的原始根，在内核插件中提供基础扩展点，作为供非内核插件使用的接口，以及基础扩展者，作为基础扩展点的接口实现，并可被非内核插件或者平台外部应用调用；

204.提供一插件系统；

206.内核插件和非内核插件向插件系统进行注册；

208.插件系统保存内核插件与非内核插件、以及非内核插件与非内核插件之间的关联关系；

210.非内核插件提供扩展点，扩展点是一个被命名的接口；

212.非内核插件提供扩展者，扩展点的接口实现；

214.将扩展点和实现该扩展点接口的扩展者进行命名连接，提供扩展。

可扩展资源管理平台基本架构

在本发明中，平台内核(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)。

规则管理器工具插件向内核注册了一个求值器构造器的扩展，从而将规则管理器与数据引擎有机地结合起来。

规则管理器工具插件向内核注册了一组预定义规则器扩展，这组预定义规则器包含了一些比较通用的规则器，例如：字符串连接、取字符串长度、数值比较、条件选择等。

应用可以根据实际情况选择使用预定义规则器或自己实现新的规则器插件。

数据引擎(Data Engine)

数据引擎(Data Engine)是可扩展资源管理平台最重要的插件，它负责完成资源转换的操作。每个资源转换的操作称为一个传输任务(Task)，数据引擎的功能就是解释并执行任务。

每个任务都定义了传输的源(Source)和目标(Target)，它们都用定位器(Locator)来描述。数据引擎并不直接操作定位器，而是使用对应的适配器(Adapter)来存取某个定位器指定的资源。

数据引擎利用求值器构造器(Evaluator Maker)创建的求值器完成转换过程中必须的表达式(Expression)求值。数据引擎在传输任务执行完毕后，会使用通知器(Notifier)发布任务完毕的通知。数据引擎使用内核插件提供的日志服务(Log Service)记录传输任务的执行过程。数据引擎由数据引擎插件、数据引擎工具插件和任务处理器组成。

任务(Task)是一次资源转换的操作。数据引擎负责解释并执行任务。每个任务都具有一个唯一的名字，并且具有可选的标题(Title)和描述(Description)。任务规定了转换的输出模式(Output Mode)、转换的可靠度级别(Reliability Level)、转换的簇大小(Cluster Size)、转换的源和目标定位器以及一组目标字段(Field)对应源字段表达式(Expression)的绑定(Binding)。

适配器(Adapter)是数据引擎用于操作定位器(Locator)的扩展者。每个定位器描述了一个资源的位置，而适配器则用于操作这些定位器指定的资源。由于资源的多样性，数据引擎本身并不实现操作这些资源的方法，而是由外部插件提供的适配器完成对资源的操作。

每种资源都有各自的存取方法，具有相同存取方法的资源被叫做具有相同的存取协议(Protocol)。协议由适配器的实现提供。例如，所有利用JDBC Driver Manager方式存取的数据源都可以被某个适配器操作，那么这个适配器就可以为此种操作方式定义一个协议。所有遵循此种操作规则的数据源都可以使用具有此协议的定位器来描述。

数据引擎处理某个数据源时，将按照定位器规定的协议查找相应的适配器，然后利用此适配器完成对此资源的存取。

每个适配器可以选择支持三种类型的操作：查询(Query)、添加(Append)和替换(Replace)。例如，一个JDBC适配器可能所有的操作都支持，而一个XML适配器可能将不支持替换操作。

支持查询操作的适配器才能被用作源，支持添加或替换操作的适配器才能被用作目标。同时支持添加或替换操作的适配器将支持所有输出模式(Output Mode)的任务。

每个适配器都可以选择是否支持事务(Transaction)。支持事务的适配器可以用于完成较高可靠度级别(Reliability Level)的任务，而不支持事务的适配器只能用于完成较低可靠度级别的任务。

求值器构造器(Evaluator Maker)用于构造求解表达式(Expression)的求值器(Evaluator)。资源转换的过程中，目标字段往往不是简单地同源字段一一对应，而是源字段经过一定的运算的结果。这样的运算规则称为一个表达式(Expression)，而目标字段与某个表达式的对应关系称为绑定(Binding)。

数据引擎执行任务的过程中，需要动态地根据源字段的值，求出目标字段对应的表达式的值，然后送入目标字段。表达式的求值是由数据引擎调用求值器完成的，而求值器构造器的任务就是创建求值器。求值器构造器负责创建两类求值器：规则求值器和映射求值器。

规则求值器(Rule Evaluator)负责求解规则表达式(Rule Expression)的值。规则表达式描述了一个规则(Rule)。一个规则是由规则器(Ruler)的名称和提供给规则器的实参(Parameters)构成的。正如0所述，如果将规则器比作函数，那么一个规则就描述了一次函数的调用。规则求值器负责完成对规则器的调用，并返回结果。

映射求值器(Mapping Evaluator)负责求解映射表达式(MappingExpression)的值。映射表达式描述了一个映射(Mapping)。一个映射是由映射器(Mapper)的名称和提供给映射器的待映射源(Source)构成的。映射求值器的功能完全类似规则求值器。

数据引擎插件(Data Engine)是数据引擎的核心插件。它对外提供数据服务(Data Service)，并负责维护适配器、求值器构造器、通知器以及活动任务。

数据服务(Data Service)是数据引擎对外开放的服务接口，它扩展了内核的服务扩展点。数据服务主要包括：

活动适配器(Active Adapter)是指已经连接到数据引擎适配器扩展点的适配器。活动适配器不同于适配器，它只提供了适配器描述信息(名称、协议、说明等)，而并不提供存取定位器的功能。通过查询活动适配器，外部应用就可以知道目前引擎可以支持的定位器协议、任务可靠度级别以及输出模式，从而定义适当的资源转换。

所有提交给引擎执行的任务，引擎都会为其建立相应的活动记录，这称为活动任务(Active Task)。活动任务包含了任务名、任务执行状态、任务执行进度、任务起止时间等信息。引擎通过活动任务来管理对应的任务。

活动任务管理包括活动任务查询、活动任务撤销和活动任务删除等功能。活动任务不同于任务，撤销一个活动任务只是将对应任务的状态标记为待撤销，实际任务的撤销需要等待任务处理器(Task Processor)的撤销检查(Cancelling Check)。同样地，活动任务的删除也只是将此活动记录删除，而并不意味着实际任务的撤销。如果一个任务关联的活动任务被删除，那么就无法再查询此任务的状态或是撤销此任务。

一个帮助理解任务与活动任务的比喻就是：将任务比作一个运行的线程，而活动任务就是这个线程的控制数据。线程根据自己的状态更新控制数据，并检测控制数据中的撤销位以决定是否撤消。将控制数据的撤销位置位并不会直接导致线程的退出--线程的退出最终是依赖线程自己检测撤销位并自行结束；将控制数据删除也并不会影响线程本身的执行。

如前所述，数据引擎插件本身并不实现任何适配器，而只是定义了适配器扩展点，适配器由其他插件实现。如果需要为数据引擎插件添加新的适配器，只需要将扩展此扩展点的适配器插件注册给内核即可。

数据引擎本身不负责实现表达式的求值，而只是定义了求值器构造器扩展点。此扩展点上只允许有一个扩展连接。如果有多个扩展连接了此扩展点，则只有第一个会被引擎使用。平台缺省的求值器构造器由规则管理器工具插件提供。如果需要为数据引擎指定新的求值器构造器，则需要首先禁用规则管理器工具插件的求值器构造器扩展，然后将提供新的扩展的插件注册给内核。

数据引擎使用通知器发布传输任务完成的通知。通知器仅当一个任务成功执行并且数据传输量不为0时被调用。通知器不是必须的。如果有多个通知器扩展连接到此扩展点，则它们会被依次调用。

数据引擎工具插件(Data Engine Utility)是数据引擎的辅助插件，它依赖于数据引擎插件。数据引擎工具插件完成以下三个功能：一、将数据引擎与资源管理器(Resource Manager)相连，为其提供缺省的传输器(Transferrer)；二、向内核注册缺省的任务记录器(Task Logger)，以完成任务的日志记录功能；三、为数据引擎插件提供一组缺省的适配器。

传输器(Transferrer)是资源管理器定义的用于执行传输任务的扩展点接口。传输器负责完成资源管理器定义的一次转换任务。数据引擎工具插件向内核注册了一个传输器的扩展，从而将数据引擎与资源管理器有机地结合起来。

数据引擎工具插件提供的传输器支持立即任务和后台任务。立即任务直接由数据引擎工具插件配合Instant Adapter完成，而后台任务则交由任务处理器(Task Processor)完成。由于立即任务不会交付任务处理器处理，因此立即任务将没有任务日志和活动任务。

任务记录器(Task Logger)是内核记录器(Logger)扩展点接口的一个实现。它只记录数据引擎的日志，而不处理来自其他发起者(Originator)的日志。缺省的任务记录器将任务日志记录在指定目录的文件，每个任务对应一个日志文件。可以配置任务记录器使得其只保留含有警告或错误信息的日志文件，而不保留成功完成的任务日志。

活动任务(Active Task)只能描述当前任务的状态，而任务日志则会记录完整的任务执行过程。

可以禁用缺省任务记录器。也可以向内核注册新的记录器扩展以完成任务日志的记录。

数据引擎工具插件提供并注册了一组常用的适配器扩展，以方便应用的开发。这包括：一、Instant适配器，用于内部处理立即任务，不对外使用；二、Driver适配器，用于以JDBC DriverManager的方式存取数据源；三、DataSource适配器，用于以JDBC DataSource的方式存取数据源；四、MQ适配器，用于存取以消息队列为传输载体并符合一定规范的消息型数据源；五、XML适配器，用于存取以XML文档形式存在并符合一定规范的文档型数据源。

任务处理器(Task Processor)是数据引擎用于执行任务的构件。任务处理器本身并不是一个插件。

任务队列(Task Queue)是引擎用于任务排队的队列。当数据引擎工具插件的传输器接收到资源管理器的任务后，如果是立即任务(InstantTask)，则传输器立即执行任务并将结果返回；如果是后台任务(Background Task)，则传输器会在创建了对应的活动任务(Active Task)之后，将此任务放入任务队列排队。一个正在排队的任务可以被撤销。

任务处理器负责从任务队列中取出下一个任务并在后台执行。任务处理器对任务的执行依赖适配器、求值器构造器以及内核的日志服务完成。任务处理器执行任务的过程中，会按照任务进度更新对应的活动任务，并在每执行到指定的簇大小(Cluster Size)时检测活动任务的撤销标记以中止任务。如果对应的活动任务已经删除，则任务处理器不会更新活动任务，并且不会进行撤销检查。任务处理器可以启动多个实例并发执行。

任务处理器负责在任务执行完毕后通知已经注册的通知器。通知器只有当任务成功完成并且数据传输量不为0的情况下被调用。立即任务的完成通知也是由任务处理器在后台完成的。

主题分发器(Topic Dispatcher)

主题分发器(Topic Dispatcher)是一个针对发布/订阅(Publish andSubscribe)模型的特殊消息分发器。主题分发器管理所有待发布(Publish)的主题(Topic)，并依赖调用器(Invoker)将其可靠地分发给相应的监听器(Listener)。主题分发器由主题分发器插件、主题分发器工具插件和主题处理器构成。

主题(Topic)是一个公开发布的消息。主题分发器负责分发主题到相应的监听器(Listener)。每个主题都具有一个唯一的名字。主题还必须具有一个题目(Subject)，题目是确定主题订阅者(监听器)的订阅凭据。主题的内容(Content)主题分发器并不关心，主题分发器只负责将主题的内容分发到相应的监听器，内容的含义由监听器解释。

监听器(Listener)是一个对某类主题感兴趣的订阅者。监听器是主题分发器维护的实体之一。主题分发器在接收到某个监听器感兴趣的主题时，负责通过调用器(Invoker)将该主题分发给此监听器。每个监听器都必须有一个可以唯一识别的名称。

每一个监听器都必须说明它所感兴趣的题目(Subject)。每个主题(Topic)都拥有一个题目(Subject)，只有与监听器相同题目的主题才会被分发到该监听器。不同的主题可以拥有相同的题目，不同的监听器也可以监听相同的题目。例如，监听器L1和监听器L2同时监听题目S1，那么当两个题目也同为S1的主题T1和T2发布时，L1和L2分别都会接收到T1和T2。

每一个监听器都必须提供一个回调(Callback)，主题分发器就是通过调用回调将主题分发给此监听器的。“回调”是一个广义的概念，它并不仅仅指“回调函数”。回调的具体含义由调用器(Invoker)解释。例如，一个回调可能是一个HTTP URL，而执行此回调的调用器的功能是将主题以HTTP表单的形式提交到此URL。不同的监听器可以使用相同的回调。

调用器(Invoker)是主题分发器定义的用于解释和调用监听器回调(Listener Callback)的扩展点接口。主题分发器虽然负责维护监听器，但并不实现对监听器回调的调用，而是将调用交给其他插件实现的调用器处理。

每个调用器都只支持符合某种特定规则的回调，这种规则称为调用协议(Protocol)。例如，表单调用器将参数以HTTP表单的形式提交给一个HTTP URL类型的回调；Web服务调用器则负责调用一个Web服务形式的回调；而MQ调用器则是将主题分发到MQ类型的回调所指定的消息队列中。

每个调用器只能识别和调用与其协议相同的回调；反之，每个回调也必须遵循与其协议相同的调用器规定的调用规则。

主题分发器向某个监听器分发主题时，将按照此监听器提供的回调规定的协议查找相应的调用器，然后利用此调用器完成此主题到此监听器的分发。

当主题分发器需要调用一个调用器分发某个主题时，会传给该调用器以下参数：一、调用器要调用的回调(待分发主题所关联的监听器回调)；二、待分发主题所关联的监听器名称；三、待分发主题的题目；四、待分发主题的内容(Content)。

调用器可以选择将全部参数或部分参数传递给回调。对于使用相同回调的多个监听器的情况，可能必须要求调用器将监听器名称和主题题目传递给回调，否则可能导致回调无法区别触发回调的题目和监听器。

主题分发器不关心调用器与回调沟通的细节，但是必须关心调用器的返回值。如果一个调用器返回True，则意味着该主题已经被该调用器所调用的回调接受(Accept)，主体分发器将认为该主题已成功分发，从而停止该主题的分发；反之，如果调用器返回False，则意味着该主题被此回调拒绝(Reject)，主体分发器将继续尝试将此主题分发给其他监听器。

如果一个调用器因为各种原因不能顺利调用回调(例如回调协议错误，或者无法联系回调)，那么此调用器应抛出调用器异常(InvokerException)；如果一个调用器成功调用了回调，但是回调出现处理错误(例如回调发现了无效的主题内容)，则此调用器应抛出回调异常(CallbackException)。对于调用器异常，主题分发器会停止对此监听器的分发，直至监听器再次被显式启动(Start)；而对于回调异常，主体分发器仍会将其他主题继续分发给此监听器。

主题分发器插件(Topic Dispatcher)是主题分发器的核心插件。它对外提供主题服务(Topic Service)，并负责维护调用器。

主题服务(Topic Service)是主题分发器对外开放的服务接口，它扩展了内核的服务扩展点。主题服务主要包括：

活动主题管理，活动主题(Active Topic)是指已经发布到主题分发器、但尚未分发(即尚未被任何监听器接受)的主题(Topic)。活动主题管理包括活动主题查询和删除。删除一个活动主题将导致此主题被永久删除，停止分发。

活动调用器查询，活动调用器(Active Invoker)是指已经连接到主题分发器调用器扩展点的调用器。活动调用器不同于调用器，它只提供了调用器的描述信息(名称、协议、说明等)，而并不提供调用回调的功能。通过查询活动调用器，外部应用就可以知道目前主题分发器可以支持的回调协议，从而定义适当的监听器。

监听器注册/注销，由于监听器是一个实体，它不包含代码实现，因此可以直接向主题分发器注册或注销(Add/Remove)。

监听器启动/停止，主题分发器并不会向所有的监听器分发消息，而是只有当一个监听器启动之后才向其分发消息。通常监听器的回调都是由外部应用实现的，而外部应用并不是总处于活动状态，因此需要通过启动/停止(Start/Stop)操作向主题分发器通知其是否活动。例如，一个外部应用向主题分发器注册了一个使用Web服务回调的监听器，那么当此应用启动时(即用于回调的Web服务可用时)，该应用应当通知主题分发器启动相应的监听器；而在此应用退出时，通知主题分发器停止相应的监听器。

主题分发器在调用回调的过程中，如果出现调用器异常，也会认为此回调不可用，并停止其对应的监听器。主题分发器负责将监听器停止后发布的与其关联的主题储存，并且在监听器再次启动时将这些主题分发给此监听器。监听器不会因为停止而丢失其监听的主题。

活动监听器(Active Listener)是指已经注册给主题分发器的监听器。活动监听器除了提供它所对应的监听器信息(名称，题目，回调)外，还提供了监听器是否已启动的标志。应用可以通过查询活动监听器取得监听器的状态。

如前所述，主题分发器插件本身并不实现任何调用器，而只是定义了调用器扩展点，调用器由其他插件实现。如果需要为主题分发器插件添加新的调用器，只需要将扩展此扩展点的调用器插件注册给内核即可。

主题分发器工具插件(Topic Dispatcher Utility)是主题分发器的辅助插件，它依赖于主题分发器插件。主题分发器工具插件完成以下三个功能：一、将主题分发器与资源管理器(Resource Manager)相连，以使资源管理器能够使用主题分发器的功能发布订阅通知；二、向内核注册缺省的主题记录器(Topic Logger)，以完成主题分发日志的记录功能；三、为主题分发器插件的调用器扩展点提供一组缺省的调用器。

发布器(Publisher)是资源管理器定义的用于发布主题的扩展点接口。发布器负责将一个主题公开发布，并供感兴趣的订阅者查询。主体分发器工具插件向内核注册了一个发布器的扩展，从而将主题分发器与资源管理器有机地结合起来。

主题记录器(Topic Logger)是内核记录器(Logger)扩展点接口的一个实现。它只记录主题分发器的日志，而不处理来自其他发起者(Originator)的日志。

缺省的主题记录器将主题的分发日志记录在指定目录的文件，每个主题对应一个日志文件。可以配置主题记录器使得其只保留尚未分发的主题日志，而不保留已成功分发的主题日志。

主题日志会记录完整的主题分发过程。如果一个主题被反复分发，后来的分发过程会添加到原来的分发过程之后。可以禁用缺省主题记录器。也可以向内核注册新的记录器扩展以完成主题分发日志的记录。

主题分发器工具插件提供并注册了一组常用的调用器扩展，以方便应用的开发。这包括：一、Web服务调用器，用于以Web服务形式存在的回调；二、表单调用器，用于接受HTTP表单提交的回调；三、MQ调用器，用于将主题发布到某个回调指定的消息队列中。

主题处理器(Topic Processor)是主题分发器用于分发主题的构件。主题处理器本身不是一个插件。

主题队列(Topic Queue)是主题分发器用于主题排队的队列。当主题分发器工具插件的发布器接收到资源管理器的主题后，首先会创建对应的活动主题，然后将此主题放入主题队列排队等待处理。

另外，当一个监听器启动时，主题分发器也会查找是否有与此监听器相关的活动主题，并将这些主题也放入主题队列等待处理。这保证了一个监听器在停止后不会丢失监听的主题。一个正在排队的主题可以被删除。

主题处理器负责从主题队列中取出下一个待处理的主题，然后轮询与之相关的已启动监听器，将主题通过调用器分发给监听器。

分发过程中，如果出现调用器异常，则停止对应的监听器；如果主题一旦被某个监听器接受(Accept)，则停止分发此主题，并将此主题对应的活动主题删除。

主题处理器支持启动多个实例并发执行。当主题处理器并发执行处理主题时，有可能导致监听器回调也被异步并发调用。因此如果启用了主题处理器的并发执行机制，那么监听器回调也必须相应地支持异步并发调用。

资源管理器(Resource Manager)

资源管理器(Resource Manager)是统一可扩展资源管理平台的总控部分。资源管理器维护两类实体：表(Table)和转换器(Transformer)。“表”是资源管理器存放资源的容器，而“转换器”则定义了资源从一种形式变为另一种形式、从一个位置迁移到另一位置的变化过程。

资源管理器使用传输器(Transferrer)完成转换任务(Task)，使用发布器(Publisher)完成主题(Topic)发布。资源管理器由资源管理器插件和资源管理器工具插件构成。

表(Table)是资源管理器存放资源的容器。表只用于存放资源管理器管理的资源，而不存放应用的原始资源。表的集合构成了资源管理器的资源仓库。

资源管理器不能直接使用外部定义的数据表，所有供资源管理器使用的表必须通过注册/注销(Add/Remove)由资源管理器来维护。

转换器(Transformer)是资源管理器维护的静态转换(Transformation)实体。转换器分为整合器(Integrator)、提供者(Provider)、消费者(Consumer)、接收者(Receiver)、订阅者(Subscriber)和运送器(Transporter)等类型。

转换(Transformation)描述了资源从一种形式变为另一种形式、从一个位置迁移到另一位置的变化过程。每个转换器都是一个命名的转换。不同的转换器可能拥有相同的转换。一个转换描述了以下信息：

每个转换都具有一个输出模式(Output Mode)。输出模式指定了该转换向目标(Target)输出数据的方式。目前定义的输出模式有三种：一、仅添加(Append Only)，该模式指定输出数据只会向目标添加；二、仅替换(Replace Only)，该模式指定输出数据只会替换目标中原有的数据；三、添加失败则替换(Replace If Append Failed)，该模式指定首先尝试将输出数据添加到目标，如果添加失败，则进行替换。

并不是所有的目标都支持全部的输出模式。例如，XML文档型的目标可能只支持添加操作；而DBMS型的目标则可能所有的输出模式都支持。

每个转换都具有一个可靠度级别(Reliability Level)。可靠度级别定义了转换进行过程中的错误处理策略。越高的可靠度级别就意味着越小的错误容忍度，同时也意味着越高的数据完整性。

目前定义的可靠度级别有三个等级，从低到高依次为：一、忽略错误(Ignore Error)，这意味着转换过程中所有的错误数据都被忽略，只有成功的数据被传送到目标；二、记录错误(Log Error)，这意味着转换过程中只有成功的数据被传送到目标，但所有的错误都会被记录；三、事务(Transactional)，这意味着整个转换过程将被看作是一个事务，任何错误都将导致所有的数据回滚。可靠度级别依赖具体的传输器适配器实现。例如，存取XML文档型的适配器可能不支持事务。

转换是以簇(Cluster)为单位进行的，一个簇包含若干条记录。簇大小(Cluster Size)就指定了该转换中每个簇的记录数。传输器执行转换任务的过程中，将按照簇为单位更新活动任务和进行撤销检查。如果指定太小的簇尺寸将可能导致严重的性能问题。如果一个转换并不关心活动任务和撤销检查，那么可以将簇大小指定为0。簇大小为0意味着所有的记录被看作为一个簇，这将获得最高的执行效率。

源(Source)和目标(Target)指定了转换的源和目标。源和目标是用位置(Location)来描述的。位置(Location)是一个带有描述信息的定位器(Locator)。定位器只能被与其具有相同协议(Protocol)的传输器适配器(Adapter)所解释和存取。位置的定义必须符合相关适配器协议的规范。

每个转换都包含一组绑定(Binding)。每个绑定指定了一个位于转换目标中的字段(Field)的表达式(Expression)。一个绑定是对一个目标字段的赋值描述。转换执行过程中，传输器负责动态地求解表达式的值，并将结果赋给目标字段。

表达式分为四种类型：常量表达式(Constant Expression)、字段表达式(Field Expression)、规则表达式(Rule Expression)和映射表达式(Mapping Expression)。

常量表达式表示了一个常量(Constant)，例如一个字符串常量或一个整数常量。常量表达式求值的结果就是该常量。

字段表达式表示了位于转换源(Source)中的一个字段(Field)。针对不同的数据行，字段表达式求值的结果也不同一一即当前行中该字段的值。字段表达式相当于变量。

规则表达式描述了一个规则(Rule)。一个规则是对某个规则器(Ruler)的一次调用。一个规则指定了要调用的规则器的名称以及传递给该规则器的实参(Parameters)。每个实参本身也是一个表达式。对规则的求值要求递归地求解所有的表达式。规则表达式相当于一个函数调用。

映射表达式描述了一个映射(Mapping)。一个映射是使用某个映射器(Mapper)的一次映射。一个映射指定了要使用的映射器名称以及待映射的源(Source)。待映射的源本身也是一个表达式。对映射表达式的求值要求递归地求解待映射源的表达式。

与一个目标字段绑定的表达式可以是上述任何类型的表达式。

每个转换器除了包含转换定义的信息外，还具有一个类型描述。根据转换器的不同功能，转换器分为以下类型：

整合器(Integrator)，用于平台内部的资源整合。整合器负责完成平台内部资源的转换。整合器的源和目标永远都是平台资源仓库，在转换信息中定义的源和目标将被忽略。

提供者(Provider)，是资源仓库中资源的原始来源。提供者负责向资源仓库提供原始资源。提供者的转换目标永远都是平台资源仓库，在转换信息中定义的目标将被忽略。

消费者(Consumer)，是平台资源的使用者。消费者将从平台请求资源。消费者的转换源永远都是平台资源仓库，在转换信息中定义的源将被忽略。

接收者(Receiver)，是一种特殊的消费者。普通的消费者必须主动向平台请求资源，而接收者不同，平台会在与接收者相关联的数据发生变化时，自动将变化的数据按照转换指定的规则传送给接收者。与消费者类似，接收者的转换源永远都是平台资源仓库，在转换信息中定义的源将被忽略。

订阅者(Subscriber)，是另外一种特殊的消费者。当与某个订阅者相关联的数据发生变化时，平台将利用发布器(Publisher)发布一则主题(Topic)，该主题的内容是一个定阅通知(Subscription)。订阅者在接收到订阅通知后，可以凭此订阅通知向平台请求变化了的数据。

由于平台会直接向接收者发送数据，所以要求接收者必须随时处于活动状态。一个不活动的接收者将会丢失在此期间发生的变化数据。而订阅者则不同，由于发布器可以确保将主题可靠地发送到订阅者，因此订阅者并不会因为处于不活动状态而丢失订阅通知。订阅者可以在任意时候凭订阅通知取得相应的变化数据。与消费者类似，订阅者的转换源永远都是平台资源仓库，在转换信息中定义的源将被忽略。

运送器(Transporter)，用来直接在两个原始资源间传送数据。运送器不使用任何平台资源。运送器的源和目标都必须明确指定。

资源管理器保证转换器的级联触发(Cascade Trigger)。例如，提供者P负责向表T1中提供数据，整合器I负责将表T1中的数据整合到表T2，接收者R接收表T1中的数据，订阅者S订阅了表T2中的数据。那么，当P向T1中提供了一条新的数据后，R会马上接收到这条新的数据，并且I将会被启动。在I将数据整合到T2后，一条针对S的订阅通知就会发布。

级联触发过程中如果某一级的某一转换器出现错误，不会影响与其同级的其他转换器的触发，但是与之关联的下一级转换器将不会被触发。

资源管理器插件(Resource Manager)是资源管理器的核心插件。它对外提供资源服务(Resource Service)，并负责维护表(Table)和转换器(Transformer)。

资源服务(Resource Service)是资源管理器对外开放的服务接口，它扩展了内核的服务扩展点。资源服务主要包括：

表注册/注销(Add/Remove)用于向资源管理器注册或注销资源表。只有在资源管理器注册了的表才能被转换器使用。不能注销一个依然被转换器使用的表。只有所有与某个表相关的转换器全部注销之后才能注销此表。

表查询用于查询资源管理器上已经注册了的表信息。

转换器注册/注销(Add/Remove)用于向资源管理器注册或注销一个转换器。一个转换器关联的表必须在转换器注册之前已经注册到资源管理器。不能注册一个与不存在的表相关联的转换器。

转换器查询用于查询资源管理器上已经注册了的转换器信息。

转换器操作包括：转换(Transform)、转换订阅(TransformSubscription)、提供(Provide)、消费(Consume)和消费订阅(ConsumeSubscription)。

转换(Transform)是指使用指定的转换器完成一次转换操作。例如，某个消费者可以使用转换功能完成一次数据请求。转换操作可以操作任意类型的转换器。转换操作可以提供一个可选的查询子句(Query Clause)，查询子句将直接传递给传输器(Transferrer)解释。并不是所有的传输器适配器(Adapter)都支持查询子句，查询子句的具体含义由适配器解释。例如，如果某个转换器的源是一个支持SQL语法的数据库，那么查询子句可能是SELECT语句的查询子句；而对于一个MQ类型的转换器源，则查询子句可能被用作消息选择器(Message Selector)；对于一个XML文档型的转换器源，可能不支持查询子句。转换操作是异步的，将启动传输器在后台完成转换任务。转换操作返回传输器的后台任务名，应用可以根据任务名向传输器查询活动任务状态。

转换订阅(Transform Subscription)是指为指定的订阅者完成订阅数据的传送。通常，订阅者在收到订阅通知(Subscription)后，使用此功能获取变化数据。转换订阅操作只能操作订阅者。类似转换操作，转换订阅操作也是异步的，并且返回相应的传输器后台任务名。

提供(Provide)是指由指定的提供者提供数据。提供操作是同步的，不启动后台任务。要提供的数据直接以特定的XML格式作为参数传递给此操作，并且在数据处理完毕后返回。提供操作只能用于操作提供者。提供操作是一种方便的、实时的、少量数据的提供方法。对于大数据量，不应使用提供操作，而应使用转换(Transform)操作完成数据提供。由于提供操作时，数据直接以参数形式提供，因此相应提供者的转换信息中定义的源会被忽略。

消费(Consume)是指为指定的消费者(接收者，订阅者)请求数据。消费操作是同步的，不启动后台任务。请求的数据将直接以特定的XML格式作为返回值返回给调用者。消费操作只能用于消费者、接收者或订阅者。类似提供操作，消费操作也不能用于大量数据的请求，并且，相应消费者(接收者，订阅者)的转换信息中定义的目标会被忽略。类似转换操作，消费操作也可以提供一个可选的查询子句。

消费订阅(Consume Subscription)是指为指定的订阅者请求订阅数据。消费订阅操作是同步的，不启动后台任务。请求的数据将直接以特定的XML格式作为返回值返回给调用者，订阅者的转换信息中定义的目标会被忽略。消费订阅操作只能操作订阅者。消费订阅操作只用于少量订阅数据的请求，对于大量订阅数据的请求，必须使用转换订阅(TransformSubscription)操作。

当资源管理器需要使用某个转换器完成数据转换时，资源管理器会将转换器的转换(Transformation)信息和附加的查询子句(Query Clauses)组合起来，构造成一个传输任务(Task)，交给传输器(Transferrer)执行。资源管理器本身不实现传输器，而是定义了传输器扩展点，传输器由其他插件实现。

传输器(Transferrer)负责解释和执行任务(Task)。一个任务是转换(Transformation)的一次执行。同一转换的两次执行将是两个独立的任务。如果把转换比作程序，那么转换器就是一个可执行文件，而任务则是一个进程。

任务包含了转换的所有信息。除此之外，任务还定义了以下的信息：一、名称(Task Name)，名称是任务的唯一标识；二、可选的任务标题(Title)和描述(Description)；三、查询子句(Query Clauses)，查询子句规定了任务执行时，从转换源提取数据的条件，查询子句的含义请参见错误！未找到引用源。(此处的引用源是指？)中关于转换操作的描述。

传输器必须支持同步执行和异步执行两种执行方式。

同步执行时的任务称为立即任务(Instant Task)。立即任务使用特殊的立即定位器(Instant Locator)指定源和目标。立即任务要求立即执行，并将结果返回。立即任务没有对应的活动任务或日志。立即任务用于少量、实时数据的传输。

异步执行的任务称为后台任务(Background Task)。后台任务用于大量数据的传输，在后台运行。后台任务要求建立相应的活动任务和日志。

对于后台任务，传输器必须负责创建活动任务(Active Task)和日志。传输器必须提供根据任务名查询活动任务的方法，并且可以撤销和删除任务。

资源管理器并不定义传输器管理活动任务和日志的具体方法。这由具体的传输器实现负责。

传输器必须有一种有效的任务通知(Notification)机制，以在任务完成后通知资源管理器。资源管理器依赖任务通知实现转换器(Transformer)的级联触发(Cascade Trigger)。

资源管理器并不定义传输器通知机制的具体方法。这由具体的传输器实现负责。

资源管理器使用发布器(Publisher)发布主题(Topic)。资源管理器本身不实现发布器，而是定义了发布器扩展点，发布器由其他插件实现。

主题(Topic)是一则公开发布的消息。发布器(Publisher)负责发布主题。一个主题由名称(Name)、题目(Subject)和内容(Content)三部分构成。名称(Name)是一个主题的唯一标识。题目(Subject)是一个主题的订阅凭据。某个订阅者凭题目订阅主题。不同的主题可以拥有相同的题目。所有拥有相同题目的主题都应被分发到订阅该题目的订阅者。内容(Content)是主题的主体。一个发布器不必关心主题的内容，它只负责将内容分发给相应的订阅者。内容的含义由订阅者解释。

资源管理器通过主题发布器发布订阅通知(Subscription)。订阅通知是一种特殊的主题，此主题的题目是订阅者的名字，内容是符合一定格式的订阅通知。某一个订阅者根据订阅通知的内容向平台请求相关的数据。

一个发布器必须提供主题管理的功能，例如主题的查询或删除。资源管理器不定义主题管理的具体方法，这由具体的发布器实现决定。

发布器必须确保将主题可靠地分发到订阅者。资源管理器不规定发布器分发主题的具体实现机制。例如，发布器可以采用回调的方式发布主题，也可以采用支持发布/订阅(Publish and Subscribe)模型的消息中间件实现主题的分发。

资源管理器工具插件(Resource Manager Utility)是资源管理器的辅助插件，它依赖于资源管理器插件。资源管理器工具插件负责实现数据引擎(Data Engine)的通知器(Notifier)扩展点接口，以实现转换器(Transformer)的级联触发(Cascade Trigger)。

为了更好地扩展本发明的可扩展资源管理平台的应用性，本发明还在可扩展资源管理平台对外提供了两种接口：

程序级接口(Program Level Interface)和应用级接口(ApplicationLevel Interface)。

程序级接口(Program Level Interface)是指平台开放给其他在代码一级调用平台的程序的接口。程序级接口由内核接口和各种插件服务接口构成，程序级接口供平台内核和插件使用。通过调用程序级接口，其他该可扩展资源管理平台内的程序可以使用平台的所有功能。由于程序级接口是在代码一级调用，因此要求调用的程序与平台工作在同一虚拟机内，这种程序称为“受限应用(Limited Application)”。受限应用虽然能使用平台的全部功能，但由于它与平台共享虚拟机资源，因此不建议有过多的受限应用或者过于消耗资源的受限应用--这也就是受限应用之所以称为“受限”应用的原因。受限应用完成平台管理员(Platform Administrator)的功能。比如，平台的管理控制台(Console)就是一个受限应用。

应用级接口(Application Level Interface)是一组平台对外开放的Web服务集合。应用级接口只提供有限的部分功能，例如：活动任务管理、转换器操作、监听器启动/停止等。应用级接口供平台外部的调用使用。

调用应用级接口的程序称为“一般应用(Normal Application)”。一般应用是平台的资源服务客户(Resource Service Client)，即资源提供者或资源使用者(消费者、接收者、订阅者)。

本发明中还提供一种接口，称为代理接口。如果某个一般应用期望调用程序级接口提供的功能，那么可以使用一个轻量级的受限应用代理完成：该受限应用对外开放一个Web服务，然后调用程序级接口完成此Web服务的功能。这种接口称为“代理接口(Proxy Interface)”。代理接口也可以用于实现其他类型的接口，例如，符合RMI(Remote MethodInvocation)规范的远程接口(Remote Interface)。代理接口由具体的应用实现，平台本身不予提供。

综合而言，采用本发明的技术方案，通过建立统一的可扩展资源管理平台，资源提供方向平台注册要开放的资源，通过平台代理开放，从而可以有效保证提供方本地资源的安全性；平台负责对各种不同种类的资源进行整合和维护，维持数据的一致性；资源使用方则以一种完全透明的方式访问资源。有效解决了资源共享的各种问题。

Claims (9)

1. 一种可扩展资源管理平台，其特征在于，包括：

平台内核，所述平台内核包括：

内核插件，所述内核插件是非内核插件的原始根，包括：

基础扩展点，基础扩展点是供非内核插件使用的接口；

基础扩展者，所述基础扩展点的接口实现，基础扩展者是可被非内核插件或者平台外部应用调用的扩展者；

插件系统，内核插件和非内核插件需要向插件系统进行注册，所述插件系统还保存内核插件与非内核插件、以及非内核插件与非内核插件之间的关联关系；

非内核插件，非内核插件与特定的功能相关，非内核插件用于实现：

扩展点，扩展点是一个被命名的接口；

扩展者，所述扩展点的接口实现；

扩展，所述扩展点和实现该扩展点接口的扩展者的命名连接；

所述非内核插件通过实现扩展点、扩展者和扩展来调用可扩展资源管理平台的资源。

2. 如权利要求1所述的可扩展资源管理平台，其特征在于，

所述内核插件提供的基础扩展点为服务扩展点，而基础扩展者为服务；

所述内核插件提供的基础扩展点以及基础扩展者包括：

日志服务点，提供日志服务，所述可扩展资源管理平台中的所有非内核插件使用日志服务点提供的日志服务进行日志记录；

所述日志服务点连接到记录器，内核插件的日志服务使用记录器完成日志记录。

3. 如权利要求1所述的可扩展资源管理平台，其特征在于，内核插件和非内核插件中的每一个具有一初始化顺序，内核插件和非内核插件在插件系统注册时根据其初始化顺序决定注册顺序；

其中，初始化顺序由插件之间的依赖关系确定。

4. 如权利要求1所述的可扩展资源管理平台，其特征在于，

提供扩展点的非内核插件需要使用扩展时，向平台内核借用连接到此扩展点上的扩展者，利用扩展者完成需要的功能，使用完毕后将扩展者归还平台内核。

5. 如权利要求1所述的可扩展资源管理平台，其特征在于，所述可扩展资源管理平台提供：

程序级接口，供平台内核与非内核插件使用；

应用级接口，供可扩展资源管理平台外部的应用使用。

6. 如权利要求1所述的可扩展资源管理平台，其特征在于，

所述非内核插件包括规则管理器插件和规则管理器工具插件，实现规则管理器的功能，用于管理资源的转换；

所述规则管理器插件提供的扩展点包括规则器扩展点，所述规则管理器插件提供的扩展包括规则服务；其中，所述规则器用于实现映射器，所述规则服务管理所述规则器和映射器；

所述规则管理器插件提供的扩展包括求值器构造器和一组预定义规则器。

7. 如权利要求1所述的可扩展资源管理平台，其特征在于，

所述非内核插件包括数据引擎插件、数据引擎工具插件和任务处理器插件，实现数据引擎的功能，用于完成资源转换任务的解释和执行；

所述数据引擎插件提供的扩展点包括适配器扩展点，求值器构造器扩展点以及通知器扩展点，所述数据引擎插件提供的扩展包括数据服务，所述数据服务用于活动适配器查询、活动任务管理；

所述数据引擎工具插件提供的扩展包括传输器、任务记录器以及一组缺省的适配器；

任务处理器插件用于集中处理任务，包括从任务队列取得任务，依赖适配器、求值器构造器和日志服务执行任务，最后利用通知器发布任务成功通知。

8. 如权利要求1所述的可扩展资源管理平台，其特征在于，

所述非内核插件包括主题分发器插件、主题分发器工具插件和主题处理器插件，实现主题分发器功能，用于完成主题的分发；

所述主题分发器插件提供的扩展点包括调用器扩展点；所述主体分发器插件提供的扩展包括主题服务，所述主题服务用于活动调用器查询、活动主题管理、活动监听器查询以及监听器管理；

所述主题分发器工具插件提供的扩展包括发布器、主题记录器以及一组缺省的调用器；

所述主题处理器插件用于后台处理主题分发，所述主题处理器从主题队列取得待分发主题，轮询与之相关的已启动监听器，并利用调用器完成主题的分发。

9. 如权利要求1所述的可扩展资源管理平台，其特征在于，

所述非内核插件包括资源管理器插件和资源管理器工具插件，用于维护表和转换器；

所述资源管理器插件提供的扩展点包括传输器扩展点和发布器扩展点；所述资源管理器插件提供的扩展包括资源服务；所述资源服务用于表管理和转换器管理；

所述资源管理器工具插件提供的扩展包括通知器。

Images