可扩展资源管理平台的制作方法

专利名称：可扩展资源管理平台的制作方法
技术领域：
本发明涉及资源管理技术，更具体地说，涉及一种可扩展资源管理平 台及资源管理方法。背景抆术随着网络技术的不断发展，资源共享逐渐成为许多企业级应用迫切的 需求。虽然目前一些应用系统实现了部分共享的功能，但很多情况下，这 种共享只限于存取有限网络内的资源或为有限网络提供资源，不能满足更 普遍、更广泛共享的需求。通常的应用系统无法做到这种普遍.、广泛共享的原因主要有两点一 .是应用系统用户出于安全保密性的考虑，不愿将所有资源对外开放；二是即使应用系统用户愿意甚至需要将一部分资源对外开放，但却没有一种统 一的途径使其资源安全、可靠地开放。发明内容本发明的目的是提供一种统一并且可扩展的资源管理平台(Universal Resource Management Platform),针对上述问题，对资源进行统一管理。 统一可扩展资源管理平台是一个"资源服务提供者"(Resource Service Provider)，它的目标是为各种"资源服务客户"(Resource Service Client)——资源提供者(Resource Provider)和资源使用者(Resource Consumer) —一提供资源采集(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)方式实现， 所有插件彼此独立，平台内核负责维护所有插件间的关联。内核提供内核 插件(CorePlugin)作为所有插件的根。平台内核是一个"轻量级"部件， 它本身不实现任何应用的功能需求，只负责完成最基础的插件服务和提供 最基础的一组扩展点。在平台内核之上，插入各个功能模块，各个功能模 块之上再插入它们特定的插件，最终完成应用特定的功能。本发明的可扩展资源管理平台采用插件机制，可以很方便地扩展平台 功能，而不需改动已有的代码。插件系统是依赖扩展点(Extension Point)、 扩展者(Extender)和扩展(Extension)实现的。需要说明的是，本发明 的可扩展资源管理平台中，除了平台内核中的内核插件是基础插件，其余 的插件都是扩展应用使用的插件，都可以视为非内核插件。在下面的叙述 中，"插件"将用于指代非内核插件，而内核插件将专门指名。并且，对 于术语"插件"和"非内核插件"，表示同样的概念。扩展点(Extension Point)就是一个命名的接口。名字唯一标识了该 扩展点，而接口说明了该扩展点期望的功能规范。两个不同的扩展点可以具有同样的接口，但不能有同样的名字。如果一个插件期望其功能能够被 其他插件扩展，则将此功能接口命名，定义为一个扩展点，而插件本身不需要实现此接口。例如，数据引擎(Data Engine)插件需要读取某个数据 源的数据，但是不同的数据源(例如JDBC数据源和XML文档数据源)具 有不同的存取方式。数据引擎不期望依赖某种特定的实现读取特定的数据 源，因此定义了适配器(Adapter)扩展点。数据引擎本身只操作适配器接 口，并不负责适配器的实现。数据引擎将此扩展点注册给内核之后，内核 负责将其与其他插件注册的适配器实现关联，从而使数据引擎完全透明地访问适配器实现。扩展者(Extender)就是一个扩展点接口的实现。扩展者只关心实现， 而无须关心谁会使用这个实现。如果两个扩展点定义了同样的接口，那么 扩展者本身并不能确定它会被哪一个扩展点使用。 一个扩展者可以实现多 个扩展点接口。扩展者的实例由扩展者工厂(Extender Home)创建 扩展(Extension)就是一个扩展点和一个扩展其接口的扩展者的命名 连接。 一个扩展包含以下信息 一个唯一的名字，被扩展的扩展点的名字， 以及实现此扩展点接口的扩展者工厂。如果一个插件期望扩展其他插件的 扩展点，则必须实现相应的扩展者，提供相应的扩展者工厂，并向内核注 册相应的扩展。内核负责将扩展者与扩展点连接，并在定义扩展点的插件 需要的时候，利用扩展者工厂创建扩展者实例，提供给此插件使用。通常 将扩展的名字也叫做扩展所连接的扩展者的名字。平台内核在本发明的平台内核中，提供了一个基础的插件，内核插件。内核插 件(Core Plugin)是平台最底层的基础插件，是所有插件插入的原始根。 内核插件定义了平台的最底层基础扩展点服务(Service)。内核插件不 同于普通的独立插件，它是平台内核的一部分。服务就是平台对外的功能接口，是应用相关的功能集合。 一个平台内 核本身是一个"轻量级"部件，它只维护插件关联，而并不实现任何特定 的功能需求。如果某个插件需要对外开放某些特定的功能，则其需要将此组功能定义为一个服务，并依赖内核插件导出。例如，规则管理器(Rule Manager)需要对外提供一组维护规则的搡作接口 ，则它需要将这组搡作 定义为一个实现了服务扩展点接口的扩展者一一规则服务(Rule Service), 并将其通过一个扩展与内核插件的服务扩展点相连接，以后当用户需要使 用规则服务的时候，就可以使用此扩展的名字向内核借用(borrow)服务。每个服务都是一个扩展者，它扩展了内核插件的服务扩展点；将服务 和内核服务扩展点连结起来的扩展的名字也被定义为服务的名字。服务作 为扩展者不同于其他普通扩展者的区别在于，服务直接由内核对外导出， 作为平台功能的统一入口，由其他应用使用；而普通扩展者则不被外部应 用所知，只由其对应扩展点的提供插件使用。服务可以对外被平台外部的 应用调用，也可以对内被其他插件使用。曰志服务(Log Service)是内核插件提供的基础服务。系统中的所有 插件都可以使用此服务完成日志记录。记录器(Logger)是内核插件定义 的用于实现曰志服务的扩展点。内核插件的曰志服务会使用连接到此扩展 点上的记录器完成日志的记录.当日志服务被调用时，内核插件会轮流调 用所有已经连接的记录器完成日志的记录。如果没有任何一个记录器接受 该记录，则内核插件会将曰志记录到标准输出(stdout)或标准错误(stderr) 设备上。不同的日志发起者(Log Originator)可能会具有不同的曰志消息 格式，只有特定的针对此发起者的记录器能识别和记录其消息。平台内核中的另一个重要的的部件是插件系统，插件系统负责所有插 件，包括内核插件和非内核插件的注册；并维护所有插件，包括内核插件 和非内核插件之间的关联关系。所有的插件，包括内核插件和非内核插件都必须向内核注册。静态插 件在内核启动时由内核注册，动态插件在内核启动后由应用程序注册。插 件由名字唯一标识。不同版本的同名插件只有最高版本有效。如果某一插 件的低版本已经注册，又试图注册更高的版本，那么高版本必须完全兼容 低版本定义的所有扩展点和扩展。每个插件拥有一个初始化顺序(Initialization Order),决定了其注册 顺序。内核插件永远是第一个初始化的，它的初始化顺序为0。其他插件则必须按照依赖关系定义初始化顺序。例如数据引擎插件只依赖内核插件， 其初始化顺序为1;而数据引擎工具插件依赖数据引擎插件，其初始化顺序为2。初始化顺序只对平台启动时加载的静态插件有效。对于平台启动后注册的动态插件，初始化顺序即为其注册的顺序。提供扩展点的插件称为宿主插件(Host Plugin),提供扩展的插件称 为从属插件(D印endent Plugin)。 一个插件可以同时是宿主插件和从属 插件。因为从属插件依赖于相关的宿主插件，因此从属插件必须在宿主插 件注册之后注册。平台内核中的插件系统还负责维护插件与插件间(包括内核插件与非 内核插件以及非内核插件与非内核插件间)的扩展关联。 一个提供扩展点 的插件需要使用扩展功能时，首先向内核借用(borrow)连接到此扩展点 上的扩展者，然后利用扩展者完成需要的功能，最后将扩展者归还(revert)。 提供扩展点的插件搡作扩展者时仅按照扩展点定义的接口操作，而不必关 心扩展者的实现或是谁提供了扩展者，从而实现插件功能的透明扩展。平台内核依赖内核插件对外提供服务。内核本身不关心服务的实现。 外部应用或其他插件需要使用服务时，首先按照服务扩展的名字向内核借 用服务，使用完成之后将服务归还。插件举例下面介绍本发明的可扩展资源管理平台中使用的插件的示例。 规则管理器(Rule Manager)规则管理器负责维护用于资源转换过程中需要使用的"求值器 (Evaluator)"。求值器分为两类规则器(Ruler)和映射器(Mapper)。 规则管理器由规则管理器插件和规则管理器工具插件构成。 规则器(Ruler)是规则管理器插件定义的一个扩展点接口。它的功能是输入一组参数，求值后，将结果返回。规则器类似于"函数(Function)"的功能。每个规则器的实现本身是一个扩展者，不具有名字。但是规则器扩展者连接到规则器扩展点的扩展具有名字，此扩展的名字就被定义为规则器的名字。规则器的名字类似于"函数名(Function Name)"。规则器元数据(Ruler Metadata)描述了规则器接受的输入参数类型、 返回值类型以及规则器的功能。例如， 一个完成连接字符串搡作的规则器， 要求输入参数个数为2,参数类型均为String,返回值也为Str'mg。元数据 信息用于给外部可视化应用动态定义转换绑定(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)和映射表达式(Mapping Expression)。规则管理器工具插件向内核注册了 一个求值器构造器的扩展，从而将 规则管理器与数据引擎有机地结合起来。规则管理器工具插件向内核注册了一组预定义规则器扩展，这组预定义规则器包含了一些比较通用的规则器，例如字符串连接、取字符串长 度、数值比较、条件选择等。应用可以根据实际情况选择使用预定义规则器或自己实现新的规则器 插件。数据弓l擎(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)和替换(R印lace)。例如， 一个JDBC适配器可能所有的搡作 都支持，而一个XML适配器可能将不支持替换操作。支持查询操作的适配器才能被用作源，支持添加或替换操作的适配器 才能被用作目标。同时支持添加或替换操作的适配器将支持所有输出模式 (Output Mode)的任务。每个适配器都可以选择是否支持事务(Transaction)。支持事务的适 配器可以用于完成较高可靠度级别(Reliab川ty 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 Ada pter)是指已经连接到数据引擎适配器扩展点 的适配器。活动适配器不同于适配器，它只提供了适配器描述信息(名称、 协议、说明等)，而并不提供存取定位器的功能。通过査询活动适配器， 外部应用就可以知道目前引擎可以支持的定位器协议、任务可靠度级别以 及输出模式，从而定义适当的资源转换。所有提交给引擎执行的任务，引擎都会为其建立相应的活动记录，这 称为活动任务(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 )是数据引擎用于执行任务的构件。任务 处理器本身并不是一个插件。任务队列(TaskQueue)是引擎用于任务排队的队列。当数据引擎工 具插件的传输器接收到资源管理器的任务后，如果是立即任务(Instant Task),则传输器立即执行任务并将结果返回；如果是后台任务 (Background Task),则传输器会在创建了对应的活动任务(Active Task) 之后，将此任务放入任务队列排队。 一个正在排队的任务可以被撤销。任务处理器负责从任务队列中取出下一个任务并在后台执行。任务处 理器对任务的执行依赖适配器、求值器构造器以及内核的日志服务完成。 任务处理器执行任务的过程中，会按照任务进度更新对应的活动任务，并 在每执行到指定的簇大小(Cluster Size)时检测活动任务的撤销标记以中 止任务。如果对应的活动任务已经删除，则任务处理器不会更新活动任务， 并且不会进行撤销检查。任务处理器可以启动多个实例并发执行。任务处理器负责在任务执行完毕后通知已经注册的通知器。通知器只 有当任务成功完成并且数据传输量不为0的情况下被调用。立即任务的完 成通知也是由任务处理器在后台完成的。主题分发器(Topic Dispatcher)主题分发器(Topic Dispatcher)是一个针对发布/订阅(Publish and Subscribe)模型的特殊消息分发器。主题分发器管理所有待发布(Publish) 的主题(Topic),并依赖调用器(Invoker)将其可靠地分发给相应的监 听器(Listener)。主题分发器由主题分发器插件、主题分发器工具插件和 主题处理器构成。主题(Topic)是一个公开发布的消息。主题分发器负责分发主题到相 应的监听器(Listener)。每个主题都具有一个唯一的名字。主题还必须具 有一个题目(Subject)，题目是确定主题订阅者(监听器)的订阅凭据。 主题的内容(Content)主题分发器并不关心，主题分发器只负责将主题的 内容分发到相应的监听器，内容的含义由监听器解释。监听器(Listener)是一个对某类主题感兴趣的订阅者。监听器是主题 分发器维护的实体之一。主题分发器在接收到某个监听器感兴趣的主题时， 负责通过调用器(Invoker)将该主题分发给此监听器。每个监听器都必须 有一个可以唯一识别的名称。每一个监听器都必须说明它所感兴趣的题目(Subject)。每个主题 (Topic)都拥有一个题目(Subject),只有与监听器相同题目的主题才会 被分发到该监听器。不同的主题可以拥有相同的题目，不同的监听器也可 以监听相同的题目。例如，监听器L1和监听器L2同时监听题目Sl，那么 当两个题目也同为SI的主题T1和T2发布时，LI和L2分别都会接收到 Tl和T2。每一个监听器都必须提供一个回调(Callback)，主题分发器就是通过 调用回调将主题分发给此监听器的。"回调"是一个广义的概念，它并不 仅仅指"回调函数"。回调的具体含义由调用器(Invoker)解释。例如， 一个回调可能是一个HTTP URL，而执行此回调的调用器的功能是将主题 以HTTP表单的形式提交到此URL。不同的监听器可以使用相同的回调。调用器(Invoker)是主题分发器定义的用于解释和调用监听器回调 (Listener Callback)的扩展点接口。主题分发器虽然负责维护监听器，但 并不实现对监听器回调的调用，而是将调用交给其他插件实现的调用器处 理。每个调用器都只支持符合某种特定规则的回调，这种规则称为调用协议(Protocol)。例如，表单调用器将参数以HTTP表单的形式提交给一个 HTTP URL类型的回调；Web服务调用器则负责调用 一个Web服务形式的 回调；而MQ调用器则是将主题分发到MQ类型的回调所指定的消息队列 中。每个调用器只能识别和调用与其协议相同的回调；反之，每个回调也 必须遵循与其协议相同的调用器规定的调用规则。主题分发器向某个监听器分发主题时，将按照此监听器提供的回调规 定的协议查找相应的调用器，然后利用此调用器完成此主题到此监听器的 分发。当主题分发器需要调用一个调用器分发某个主题时，会传给该调用器 以下参数 一、调用器要调用的回调(待分发主题所关联的监听器回调)； 二、待分发主题所关联的监听器名称；三、待分发主题的题目；四、待分 发主题的内容(Content)。调用器可以选择将全部参数或部分参数传递给回调。对于使用相同回 调的多个监听器的情况，可能必须要求调用器将监听器名称和主题题目传 递给回调，否则可能导致回调无法区别触发回调的题目和监听器。主题分发器不关心调用器与回调沟通的细节，但是必须关心调用器的 返回值。如果一个调用器返回Tme，则意味着该主题已经被该调用器所调 用的回调接受(Accept),主体分发器将认为该主题已成功分发，从而停 止该主题的分发；反之，如果调用器返回False,则意味着该主题被此回调 拒绝(Reject)，主体分发器将继续尝试将此主题分发给其他监听器。如果一个调用器因为各种原因不能顺利调用回调(例如回调协议错误， 或者无法联系回调)，那么此调用器应抛出调用器异常(Invoker Exc印tion);如果一个调用器成功调用了回调，但是回调出现处理错误(例 如回调发现了无效的主题内容)，则此调用器应抛出回调异常(Callback Exception)。对于调用器异常，主题分发器会停止对此监听器的分发，直 至监听器再次被显式启动(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)，该模式指定输出数据只会替换目标中原有的数据； 三、添加失败则替换(R印lace If Append Failed),该模式指定首先尝试 将输出数据添加到目标，如果添加失败，则进行替换。并不是所有的目标都支持全部的输出模式。例如，XML文档型的目标 可能只支持添加操作；而DBNIS型的目标则可能所有的输出模式都支持。每个转换都具有一个可靠度级别(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向Tl中提供了一条新的数据后，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文档28型的转换器源，可能不支持査询子句。转换操作是异步的，将启动传输器 在后台完成转换任务。转换操作返回传输器的后台任务名，应用可以根据 任务名向传输器查询活动任务状态。转换订阅(Transform Subscription)是指为指定的订阅者完成订阅数 据的传送。通常，订阅者在收到订阅通知(Subscription)后，使用此功能 获取变化数据。转换订阅操作只能操作订阅者。类似转换操作，转换订阅 操作也是异步的，并且返回相应的传输器后台任务名。提供(Provide)是指由指定的提供者提供数据。提供搡作是同步的， 不启动后台任务。要提供的数据直接以特定的XML格式作为参数传递给此 搡作，并且在数据处理完毕后返回。提供搡作只能用于操作提供者。提供 操作是一种方便的、实时的、少量数据的提供方法。对于大数据量，不应 使用提供操作，而应使用转换(Transform)操作完成数据提供。由于提供 操作时，数据直接以参数形式提供，因此相应提供者的转换信息中定义的 源会被忽略。消费(Consume)是指为指定的消费者(接收者，订阅者)请求数据。 消费搡作是同步的，不启动后台任务。请求的数据将直接以特定的XNIL格 式作为返回值返回给调用者。消费操作只能用于消费者、接收者或订阅者。 类似提供操作，消费操作也不能用于大量数据的请求，并且，相应消费者 (接收者，订阅者)的转换信息中定义的目标会被忽略。类似转换搡作，消费搡作也可以提供一个可选的査询子句。消费订阅(Consume Subscription)是指为指定的订阅者请求订阅数 据。消费订阅搡作是同步的，不启动后台任务。请求的数据将直接以特定 的XML格式作为返回值返回给调用者，订阅者的转换信息中定义的目标会 被忽略。消费订阅操作只能搡作订阅者。消费订阅搡作只用于少量订阅数 据的请求，对于大量订阅数据的请求，必须使用转换订阅(Transform Subscription)操作。当资源管理器需要使用某个转换器完成数据转换时，资源管理器会将 转换器的转换(Transformation)信息和附加的查询子句(Query Clauses) 组合起来，构造成一个传输任务(Task)，交给传输器(Transferrer)执行。资源管理器本身不实现传输器，而是定义了传输器扩展点，传输器由 其他插件实现。传输器(Transferrer)负责解释和执行任务(Task)。 一个任务是转 换(Transformation)的一次执行。同一转换的两次执行将是两个独立的 任务。如果把转换比作程序，那么转换器就是一个可执行文件，而任务则 是一个进程。任务包含了转换的所有信息。除此之外，任务还定义了以下的信息 一、名称(Task Name)，名称是任务的唯一标识；二、可选的任务标题 (Title)和描述(Description);三、查询子句(Query Clauses)，查询 子句规定了任务执行时，从转换源提取数据的条件，査询子句的含义请参 见错误！未找到引用源。(此处的引用源是指？)中关于转换操作的描述。 传输器必须支持同步执行和异步执行两种执行方式。 同步执行时的任务称为立即任务(InstantTask)。立即任务使用特殊 的立即定位器(Instant Locator)指定源和目标。立即任务要求立即执行， 并将结果返回。立即任务没有对应的活动任务或日志。立即任务用于少量、 实时数据的传输。异步执行的任务称为后台任务(Background Task)。后台任务用于大 量数据的传输，在后台运行。后台任务要求建立相应的活动任务和日志。对于后台任务，传输器必须负责创建活动任务(ActiveTask)和曰志。 传输器必须提供根据任务名査询活动任务的方法，并且可以撤销和删除任 务。资源管理器并不定义传输器管理活动任务和曰志的具体方法。这由具 体的传输器实现负责。传输器必须有一种有效的任务通知(Notification)机制，以在任务完 成后通知资源管理器。资源管理器依赖任务通知实现转换器(Transformer) 的级联触发(Cascade Trigger)。资源管理器并不定义传输器通知机制的具体方法。这由具体的传输器 实现负责。资源管理器使用发布器(Publisher)发布主题(Topic)。资源管理器本身不实现发布器，而是定义了发布器扩展点，发布器由其他插件实现。主题(Topic)是一则公幵发布的消息。发布器(Publisher)负责发布 主题。 一个主题由名称(Name)、题目(Subject)和内容(Content)三 部分构成。名称(Name)是一个主题的唯一标识，题目(Subject)是一 个主题的订阅凭据。某个订阅者凭题目订阅主题。不同的主题可以拥有相 同的题目。所有拥有相同题目的主题都应被分发到订阅该题目的订阅者。 内容(Content)是主题的主体。 一个发布器不必关心主题的内容，它只负 责将内容分发给相应的订阅者。内容的含义由订阅者解释。资源管理器通过主题发布器发布订阅通知(Subscription)。订阅通知 是一种特殊的主题，此主题的题目是订阅者的名字，内容是符合一定格式 的订阅通知。某一个订阅者根据订阅通知的内容向平台请求相关的数据。一个发布器必须提供主题管理的功能，例如主题的查询或删除。资源 管理器不定义主题管理的具体方法，这由具体的发布器实现决定。发布器必须确保将主题可靠地分发到订阅者。资源管理器不规定发布 器分发主题的具体实现机制。例如，发布器可以采用回调的方式发布主题， 也可以采用支持发布/订阅(Publish and Subscribe)模型的消息中间件实 现主题的分发。资源管理器工具插件(Resource Manager Ut川ty)是资源管理器的辅 助插件，它依赖于资源管理器插件。资源管理器工具插件负责实现数据引 擎(Data Engine)的通知器(Notifier)扩展点接口，以实现转换器 (Transformer)的级联触发(Cascade Trigger)。为了更好地扩展本发明的可扩展资源管理平台的应用性，本发明还在 可扩展资源管理平台对外提供了两种接口 程序级接口 (Program Level Interface)和应用级接口 (ApplicationLevel Interface)。程序级接口 (Program Level Interface)是指平台开放给其他在代码一 级调用平台的程序的接口。程序级接口由内核接口和各种插件服务接口构 成，程序级接口供平台内核和插件使用。通过调用程序级接口，其他该可扩展资源管理平台内的程序可以使用平台的所有功能。由于程序级接口是 在代码一级调用，因此要求调用的程序与平台工作在同一虛拟机内，这种程序称为"受限应用(Limited Application)"。受限应用虽然能使用平台 的全部功能，但由于它与平台共享虛拟机资源，因此不建议有过多的受限 应用或者过于消耗资源的受限应用一一这也就是受限应用之所以称为"受 限"应用的原因。受限应用完成平台管理员(Platform Administrator)的 功能。比如，平台的管理控制台(Console)就是一个受限应用。应用级接口 ( A叩lication Level Interface )是一组平台对外开放的Web 服务集合。应用级接口只提供有限的部分功能，例如活动任务管理、转 换器操作、监听器启动/停止等。应用级接口供平台外部的调用使用。调用应用级接口的程序称为"一般应用(Normal Application)"。 一 般应用是平台的资源服务客户(Resource Service Client),即资源提供者 或资源使用者(消费者、接收者、订阅者)。本发明中还提供一种接口，称为代理接口。如果某个一般应用期望调 用程序级接口提供的功能，那么可以使用一个轻量级的受限应用代理完成 该受限应用对外开放一个Web服务，然后调用程序级接口完成此Web服 务的功能。这种接口称为"代理接口 (Proxy Interface)"。代理接口也 可以用于实现其他类型的接口 ，例如，符合RMI ( Remote Method Invocation)规范的远程接口 ( Remote Interface)。代理接口由具体的应 用实现，平台本身不予提供。综合而言，采用本发明的技术方案，通过建立统一的可扩展资源管理 平台，资源提供方向平台注册要开放的资源，通过平台代理开放，从而可 以有效保证提供方本地资源的安全性；平台负责对各种不同种类的资源进 行整合和维护，维持数据的一致性；资源使用方则以一种完全透明的方式 访问资源。有效解决了资源共享的各种问题。
权利要求
1. 一种可扩展资源管理平台，其特征在于，包括平台内核，所述平台内核包括内核插件，所述内核插件是非内核插件的原始根，包括基础扩展点，基础扩展点是供非内核插件使用的接口；基础扩展者，所述基础扩展点的接口实现，基础扩展者是可被非内核插件或者平台外部应用调用的扩展者；插件系统，内核插件和非内核插件需要向插件系统进行注册，所述插件系统还保存内核插件与非内核插件、以及非内核插件与非内核插件之间的关联关系；非内核插件，非内核插件与特定的功能相关，非内核插件用于实现扩展点，扩展点是一个被命名的接口；扩展者，所述扩展点的接口实现；扩展，所述扩展点和实现该扩展点接口的扩展者的命名连接；所述非内核插件通过实现扩展点、扩展者和扩展来调用可扩展资源管理平台的资源。
2. 如权利要求l所述的可扩展资源管理平台，其特征在于， 所述内核插件提供的基础扩展点为服务扩展点，而基础扩展者为服务； 所述内核插件提供的基础扩展点以及基础扩展者包括曰志服务点，提供日志服务，所述可扩展资源管理平台中的所有 非内核插件使用日志服务点提供的日志服务进行曰志记录；所述日志服务点连接到记录器，内核插件的曰志服务使用记录器 完成日志记录。
3. 如权利要求l所述的可扩展资源管理平台，其特征在于，内核插件 和非内核插件中的每一个具有一初始化顺序，内核插件和非内核插件在插 件系统注册时根据其初始化顺序决定注册顺序；其中，初始化顺序由插件之间的依赖关系确定。
4. 如权利要求l所述的可扩展资源管理平台，其特征在于，提供扩展点的非内核插件需要使用扩展时，向平台内核借用连接到此 扩展点上的扩展者，利用扩展者完成需要的功能，使用完毕后将扩展者归 还平台内核。
5. 如权利要求l所述的可扩展资源管理平台，其特征在于，所述可扩展资源管理平台提供程序级接口，供平台内核与非内核插件使用； 应用级接口，供可扩展资源管理平台外部的应用使用。
6. 如权利要求l所述的可扩展资源管理平台，其特征在于， 所述非内核插件包括规则管理器插件和规则管理器工具插件，实现规则管理器的功能，用于管理资源的转换；所述规则管理器插件提供的扩展点包括规则器扩展点，所述规则管理 器插件提供的扩展包括规则服务；其中，所述规则器用于实现映射器，所 述规则服务管理所述规则器和映射器；所述规则管理器插件提供的扩展包括求值器构造器和一组预定义规则器。
7. 如权利要求l所述的可扩展资源管理平台，其特征在于， 所述非内核插件包括数据引擎插件、数据引擎工具插件和任务处理器插件，实现数据引擎的功能，用于完成资源转换任务的解释和执行；所述数据引擎插件提供的扩展点包括适配器扩展点，求值器构造器扩展点以及通知器扩展点，所述数据引擎插件提供的扩展包括数据服务，所述数据服务用于活动适配器查询、活动任务管理；所述数据引擎工具插件提供的扩展包括传输器、任务记录器以及一组缺省的适配器;，任务处理器插件用于集中处理任务，包括从任务队列取得任务，依赖 适配器、求值器构造器和日志服务执行任务，最后利用通知器发布任务成功通知。
8.如权利要求l所述的可扩展资源管理平台，其特征在于， 所述非内核插件包括主题分发器插件、主题分发器工具插件和主题处 理器插件，实现主题分发器功能，用于完成主题的分发；所述主题分发器插件提供的扩展点包括调用器扩展点；所述主体分发 器插件提供的扩展包括主题服务，所述主题服务用于活动调用器査询、活 动主题管理、活动监听器查询以及监听器管理；所述主题分发器工具插件提供的扩展包括发布器、主题记录器以及一 组缺省的调用器；所述主题处理器插件用于后台处理主题分发，所述主题处理器从主题 队列取得待分发主题，轮询与之相关的已启动监听器，并利用调用器完成 主题的分发。
9.如权利要求l所述的可扩展资源管理平台，其特征在于， 所述非内核插件包括资源管理器插件和资源管理器工具插件，用于维 护表和转换器；所述资源管理器插件提供的扩展点包括传输器扩展点和发布器扩展 点；所述资源管理器插件提供的扩展包括资源服务；所述资源服务用于表 管理和转换器管理；所述资源管理器工具插件提供的扩展包括通知器。
全文摘要
本发明揭示一种可扩展资源管理平台，包括平台内核，平台内核包括内核插件和插件系统，内核插件是非内核插件的原始根，提供基础扩展点和基础扩展者；插件系统进行插件的注册，插件系统还保存内核插件与非内核插件、以及非内核插件与非内核插件之间的关联关系；该可扩展资源管理平台的非内核插件与特定的功能相关，非内核插件用于实现扩展点、扩展者和扩展，非内核插件通过实现扩展点、扩展者和扩展来调用可扩展资源管理平台的资源。非内核插件实现的功能包括规则管理器、数据引擎、主题分发器和资源管理器。本发明的可扩展资源管理平台负责对各种不同种类的资源进行整合和维护，维持数据的一致性；资源使用方则以一种完全透明的方式访问资源。有效解决了资源共享的各种问题。
文档编号G06F9/44GK101276269SQ20071003883
公开日2008年10月1日 申请日期2007年3月30日 优先权日2007年3月30日
发明者孙圭宁, 伟 王, 顾国强, 高建强, 高念高 申请人:上海众恒信息产业有限公司