CN101266542A - 一种在容器中装载组件的方法及装置 - Google Patents

Abstract

本发明提供了一种在容器中装载组件的方法，包括：指定当前组件装载的类装载器，并在预置存储路径下定位组件；获取所述组件的描述文件，所述描述文件包括装载配置信息；解析所述组件描述文件，生成相应的组件描述对象；判断所述组件描述对象的装载配置信息是否对应具体的配置文件及解析规则文件，若是，则提取所述配置文件，并依据所述解析规则文件解析所述配置文件，生成相应的组件对象；若否，则依据所述装载配置信息由代码定制的组件装载器产生相应的组件对象。本发明可以在节约系统资源的前提下，有效提高容器的可扩展性和灵活性。

Description

一种在容器中装载组件的方法及装置

技术领域

本发明涉及信息处理技术领域，特别是涉及一种在容器中装载组件的方法及一种在容器中装载组件的装置。

背景技术

J2EE架构是当前主流的架构之一，目前大多数企业采用J2EE技术的结构设计与解决方案。J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持Enterprise JavaBeans(EJB)，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。

J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。传统的J2EE多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层，以下是J2EE典型的四层结构：

1、运行在客户端机器上的客户层组件；

2、运行在J2EE服务器上的Web层组件；

3、运行在J2EE服务器上的业务逻辑层组件；

4、运行在EIS服务器上的企业信息系统(Enterprise information system)层软件。

目前，J2EE平台被广泛地认为是这个架构，运行在J2EE服务器上的EJB容器可以认为是此架构的核心，EJB容器管理着所有EJB的执行，以及EJB的生命周期，并且为EJB提供所有系统级的服务。EJB组件则负责接受，处理WEB容器的客户请求和连接提供整个企业使用的数据，服务的EIS层。在此架构中，所有的数据访问都要通过entity bean，业务对象都是带远程接口的无状态session bean，运行在EJB容器中。具体而言，EJB容器是一个管理一个或多个EJB类/实例的抽象。它通过规范中定义的接口使EJB类访问所需的服务。EJB结构中的角色EJB组件结构是基于组件的分布式计算结构，是分布式应用系统中的组件。EJB组件通常部署在被称为EJB容器的应用服务器中，由EJB容器提供EJB组件的状态管理、事务管理、线程管理、远程数据资源访问、连接管理和安全性管理等系统级服务。所有的EJB组件实例都运行在EJB容器中，由EJB容器控制着EJB组件的生命周期。EJB组件可以被定制为提供安全和事务处理等各种系统级服务。

然而，这种EJB容器和J2EE绑定，对EJB组件的开发有严格的规范限制，扩展性和灵活性也较差，例如，其不能同时在WEB容器和标准应用程序中运行，对于容器强制业务对象采用特定的接口等。并且，这种EJB容器中在组件部署时较为复杂，严重耗费系统开销。

所以，本领域技术人员迫切需要发展一种能在节约系统资源的前提下，能有效提高容器的可扩展性和灵活性的组件装载方法。

发明内容

本发明所要解决的技术问题是提供一种在容器中装载组件的方法，用以在节省系统资源的前提下，有效提高容器的可扩展性和灵活性。

本发明还提供了一种在容器中装载组件的装置，用以保证上述方法在实际中的实现及应用。

为了解决上述问题，本发明公开了一种在容器中装载组件的方法，包括：

指定当前组件装载的类装载器，并在预置存储路径下定位组件；

获取所述组件的描述文件，所述描述文件包括装载配置信息；

解析所述组件描述文件，生成相应的组件描述对象；

判断所述组件描述对象的装载配置信息是否对应具体的配置文件及解析规则文件，

若是，则提取所述配置文件，并依据所述解析规则文件解析所述配置文件，生成相应的组件对象；

若否，则依据所述装载配置信息由代码定制的组件装载器产生相应的组件对象。

优选的，所述描述文件还包括组件标识和资源路径，所述的方法还包括：

从所述资源路径获取所述组件相关的资源；

在容器中注册组件，所述组件包括所述组件对象及其相关资源，所述组件对象由所述组件标识区分。

优选的，所述描述文件还包括组件装载类型信息，所述的方法还包括：

依据所述组件装载类型信息整理所述组件对象。

优选的，所述预置存储路径包括组件部署目录和组件资源目录，所述组件定位步骤还包括：

第一判断步骤：判断是否存在未遍历的组件部署目录，如果是，则遍历所述组件部署目录；

第二判断步骤：判断所述组件资源目录是否未处理，如果是，则定位所述未处理的组件；如果否，则返回所述第一判断步骤。

优选的，所述类装载器设置在当前线程上下文中。

本发明实施例还公开了一种在容器中装载组件的装置，包括：

预处理单元，用于指定当前组件装载的类装载器，并在预置存储路径下定位组件；

获取单元，用于获取所述组件的描述文件，所述描述文件包括装载配置信息；

解析单元，用于解析所述组件描述文件，生成相应的组件描述对象；

判断单元，用于判断所述组件描述对象的装载配置信息是否对应具体的配置文件及解析规则文件，若是，则调用第一处理单元；若否，则调用第二处理单元；

第一处理单元，用于提取所述配置文件，并依据所述解析规则文件解析所述配置文件，生成相应的组件对象；

第二处理单元，用于依据所述装载配置信息由代码定制的组件装载器产生相应的组件对象。

优选的，所述描述文件还包括组件标识和资源路径，所述的装置还包括：

资源提取单元，用于从所述资源路径获取所述组件相关的资源；

注册单元，用于在容器中注册组件，所述组件包括所述组件对象及其相关资源，所述组件对象由所述组件标识区分。

优选的，所述描述文件还包括组件装载类型信息，所述的装置还包括：

整理单元，用于依据所述组件装载类型信息整理所述组件对象。

优选的，所述预置存储路径包括组件部署目录和组件资源目录，所述预处理单元还包括：

第一判断子单元：用于判断是否存在未遍历的组件部署目录，如果是，则遍历所述组件部署目录；

第二判断子单元：用于判断所述组件资源目录是否未处理，如果是，则定位所述未处理的组件；如果否，则调用所述第一判断子单元。

优选的，所述类装载器设置在当前线程上下文中。

与现有技术相比，本发明具有以下优点：

首先，本发明中的组件仅与配置文件和业务实现相关，容器仅与底层的构建(即解析和装载组件)相关，从而将底层的构建与业务实现分离开来，有效提高了容器的可扩展性和灵活性；

再者，本发明的组件之间的依赖性较低，组件的类和配置文件变更后可以自动装载更新，从而进一步提高了容器的可扩展性和灵活性；

此外，本发明中AOP的组件代理可以方便地为组件添加功能(如监控等)，而无需对组件本身作任何修改；

并且，本发明的组件部署简单，从而可以有效节约系统资源；

最后，本发明对于服务提供商来说，技术实现简单，无技术障碍，无特殊保密算法，成本和风险较低。

附图说明

图1是本发明的一种在容器中装载组件的方法实施例1的流程图；

图2是本发明的一种在容器中装载组件的方法实施例2的流程图；

图3是本发明的支持AOP的轻量级组件容器平台的框架示意图；

图4是AOP的拦截示意图；

图5是所述容器平台装载层次的示意图；

图6是所述组件容器平台对所有组件进行装载的流程图；

图7是所述组件容器平台执行多任务装载的流程图；

图8是在所述容器中装载组件的流程图；

图9是所述组件注册的流程图；

图10是所述组件的通用装载过程示意图；

图11是一种组件动态装载的过程示意图；

图12是一种组件调用的流程图；

图13是本发明的一种在容器中装载组件的装置实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、包括以上任何系统或设备的分布式计算环境等等。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

参考图1，示出了本发明的一种在容器中装载组件的方法实施例1的流程图，可以包括以下步骤：

步骤101、指定当前组件装载的类装载器，并在预置存储路径下定位组件；

步骤102、获取所述组件的描述文件，所述描述文件包括装载配置信息和资源路径；

步骤103、解析所述组件描述文件，生成相应的组件描述对象；

步骤104、判断所述组件描述对象的装载配置信息是否对应具体的配置文件及解析规则文件，若是，则执行步骤105；若否，则执行步骤106；

步骤105、提取所述配置文件，并依据所述解析规则文件解析所述配置文件，生成相应的组件对象；

步骤106、依据所述装载配置信息由代码定制的组件装载器产生相应的组件对象。

在本实施例中，组件可以表现为一个实例，用以实现明确的接口，并可以被线程间共享或声明可以复制，组件是静态的，它没有状态属性、仅用于提供服务；相应地，容器可以理解为承载组件的容器，用以提供注册组件、销毁组件、更新组件、获取组件实例等组件生命周期的管理功能。并且，可以通过组件插件来支持在组件的特定事件点执行某些功能，同时还可以对组件插件进行管理。优选的是，在组件创建过程中，容器可以对ThreadSafe(线程安全，是指当一个线程使用它时不能被其它线程更改，即变量不能被异步改变)的组件返回同一实例，对非ThreadSafe的组件能够进行复制。其中，组件插件可以理解为拦截器，用于在对组件的调用过程中间执行的功能，这些调用和时间相关(如在服务的执行前后，需要记录服务流水信息)。拦截器在流程执行中可以对调用进行拦截，这时它需要根据当前的情况来完成一些功能。拦截器与组件可以通过定义进行关联。

优选的，所述类装载器可以为所述类装载器设置在当前线程上下文中。。

参考图2，示出了本发明的一种在容器中装载组件的方法实施例2的流程图，可以包括以下步骤：

步骤201、指定当前组件装载的类装载器；

步骤202、判断是否存在未遍历的组件部署目录，如果是，则执行步骤203；如果否，则结束装载；

步骤203、遍历所述组件部署目录；

步骤204、判断所述组件资源目录是否未处理，如果是，则定位所述未处理的组件，然后执行步骤205；如果否，则返回步骤202；

步骤205、获取所述组件的描述文件，所述描述文件包括组件标识、组件装载类型信息、装载配置信息和资源路径；

步骤206、解析所述组件描述文件，生成相应的组件描述对象；

步骤207、判断所述组件描述对象的装载配置信息是否对应具体的配置文件及解析规则文件，若是，则执行步骤208；若否，则执行步骤209；

步骤208、提取所述配置文件，并依据所述解析规则文件解析所述配置文件，生成相应的组件对象；

步骤209、依据所述装载配置信息由代码定制的组件装载器产生相应的组件对象；

步骤210、依据所述组件装载类型信息整理所述组件对象；

步骤211、从所述资源路径中获取所述组件相关的资源；

步骤212、在容器中注册组件，所述组件包括所述组件对象及其相关资源，所述组件对象由所述组件标识区分。

注册完成后，可以返回步骤204循环执行。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

基于本发明的优选实施例，可以开发一种支持AOP的轻量级组件容器平台，以下结合所述容器平台对本发明实施例进一步说明。

所述容器平台的框架示意图如图3所示，可以看出，在这种框架中，组件是运行期提供服务的对象，组件的存储是组件对象在应用系统中的定义。组件在应用系统中具有一致的特征，并能通过一致的方式完成装载。组件容器负责组件的管理，为组件提供诸如生命周期管理(创建、更新、销毁、启动、停止)和组件装载等服务。AOP(Aspect OrientedProgramming，面向方面编程)代理对组件进行封装，实现组件接口，同时包含组件的实现。拦截器通过AOP代理对组件进行拦截。组件的使用者从容器中获取组件实例，然后调用组件的接口。

其中，AOP可以将基本横切关注点的代码，与程序的核心应用逻辑相分离，如图4所示，401为JoinPoint发生作用的点，402为PointCut被切割的截面，代表被拦截对象的集合(例如：类C1的A1方法、类C2的B2方法、类C3的C3方法就构成了一个PointCut)。Advice是拦截的行为，即在拦截发生作用时执行的动作。Advisor将Advice和PointCut关联起来。各种拦截器(Interceptor)对应于不同的拦截位置。框架按照AOP配置产生AOP代理(AopProxy)，AOP代理在实际执行过程中执行拦截功能。

组件和容器沟通的接口可以通过组件描述文件定义，简而言之，组件描述文件定义了容器需要了解的组件自身信息。在实际中，组件的描述主要包括组件的特征和组件装载的入口点，其中，组件的特征是组件装载成组件对象后，进行代理和拦截所需要的信息；组件装载的入口点包括明确的接口，用于启动装载的过程。组件配置用于对组件的具体实现和属性进行描述。组件创建器负责创建组件的实例对象；容器承载组件，并对组件进行管理。组件容器可以用于实现以下功能：

1、组件的存储：

组件是运行期提供服务的对象，组件的存储是组件对象在应用系统中的定义，即组件资源。具体而言，组件可以包括组件描述和组件配置。其中，组件描述可以包括组件的命名、组件的接口、组件装载器的配置信息；组件配置可以包括组件存在依赖的类和配置文件。

所述组件描述可以以XML文件的形式存储于应用系统中，如component.xml。该XML文件描述了组件的服务接口、组件的装载逻辑、组件资源获取目录等信息。

优选的是，根据配置加载的需求，所述XML数据的配置加载可以采用扩展commons-digester来实现。具体而言，commons-digester可以将XML数据装载成java object API。它使用了SAX解析器，当解释到某个XML事件标签时，触发同该标签相关的一组动作，在动作中而完成javaobject的创建、加工、方法调用等操作。基于所述commons-digester框架，可以开发config.rule，该包通过对commons-digester包的扩展，定义了一组对象模型特征，同时定义了所述对象模型特征的名称。XML标签用于编写XML规则脚本，规则脚本产生SAX解析器，SAX解析器可以用来解析XML配置创建对象。规则脚本通过解析配置文件的对象模型特征，通过对栈的操作，完成配置数据和生成对象的缓存及运算的过程。例如，当遇到XML事件时，定义的对象模型特征可能产生新的对象，新产生的对象便保存在栈中；或者当从XML的事件中读取的属性，定义的对象模型特征可以用该属性的值，设置栈中对象的属性。

在这种情况下，所述XML文件的配置及解析过程可以参考以下步骤实现：

一、定义一组新的规则动作，每个规则动作都具有有一个特定属性target，它标识该标签动作操作的栈名。同时对原有commons-digester的解析器进行扩展，在原有内置栈的基础上，新增了一个扩展栈及其数据结构和对象出入栈操作，在解析过程中还可以动态建立临时栈。经过所述扩展后，所述解析器可以对规则动作target属性命名栈的识别，并支持新增规则动作对命名栈的操作。

例如，在扩展解析器中将新增扩展栈名为″__extend__″，commons-digester的解析器的原有内置栈名为″__base__″。新增规则动作通过命名栈target的方式，支持栈与栈之间操作。

二、针对上述定义的规则动作，定义与规则动作对应的规则标签，规则标签用于书写XML规则脚本。同时，扩展规则解析器以支持相应规则标签识别、从而触发规则对象工厂的调用，实现规则标签到规则动作对象的转化。

基于上述定义，应用本发明的一种XML文件解析过程为：

三、使用规则标签编写XML规则脚本，编写XML文件，其中，所述XML文件可以包括装载任务对象脚本和组件对象脚本，具体而言，所述装载任务对象脚本可以包括装载对象配置文件和装载规则脚本；所述组件对象脚本可以包括组件对象配置文件和组件规则脚本，

为了解决组件对象脚本与装载任务对象脚本之间的关联问题，引入了统一资源标识符(Uniform Resource Identifier，简称″URI″)唯一标识一个组件，公知的是，URI一般由三部分组成：访问资源的命名机制；存放资源的主机名；资源自身的名称、路径或者参数。例如，http://www.webmonkey.com.cn/html/html40/；这个URI表示了一个可通过HTTP协议访问的资源，位于主机www.webmonkey.com.cn上，通过路径“/html/html40”访问即可。在网络资源数据传输领域中比较常用的是URL(Uniform Resource Location，统一资源定位符)，URL是URI命名机制的一个子集。在本例中，每个URI需要关联两份文件，组件对象脚本dataxml与装载任务对象脚本rulexml。进一步地，采用URI标识信息的一部分同另外的目录信息、获取方式信息组成URL，最终定位dataxml和rulexml。

四、解析装载任务对象脚本，在装载管理器中生成装载任务，具体可以包括以下步骤：

1、依据所述装载规则脚本生成SAX解析器。

2、由所述SAX解析器解析装载任务对象脚本，动态生成装载任务序列，每个装载任务序列具有URI标识。

五、指定装载任务URI，装载由URI标识的装载任务序列，以创建组件对象，具体可以包括以下步骤：

1)遍历URI标识的装载任务序列，取得指定装载任务的组件对象脚本；

2)依据所述组件对象脚本的组件规则脚本生成SAX解析器；

3)由所述SAX解析器解析组件对象脚本；

4)SAX解析器返回栈顶组件对象。

当然，上述方法仅仅用于举例，本领域技术人员采用现有技术中的任一种XML文件配置及解析方法都是可行的，本发明对此不需要进行限定。

例如，组件描述的DTD文件如以下代码所示：

<？xml version＝″1.0″encoding＝″gb2312″？>

<！--组件的描述信息

1.type描述了组件的服务接口

2.desc为组件的文字描述信息

3.loader为组件的装载逻辑-->

<！ELEMENT component(type，desc？，loader)>

<！ATTLIST component

name CDATA#REQUIRED

>

<！--组件的类型，如果实现了多个接口，使用“，”分隔-->

<！ELEMENT type(#PCDATA)>

<！--对组件的描述-->

<！ELEMENT desc(#PCDATA)>

<！--组件的装载器-->

<！ELEMENT loader(update-manner，path？，(default-entry|class-entry))>

<！ELEMENT update-manner(attr*)>

<！ATTLIST update-manner

name(VaryReload|TimerReload|ConsoleReload|NeverReload)#REQUIRED

>

<！ELEMENT attr(#PCDATA)>

<！ATTLIST attr

name CDATA#REQUIRED

>

<！--资源的获取目录-->

<！ELEMENT path(item)+>

<！ELEMENT item(#PCDATA)>

<！--XML入口的配置-->

<！ELEMENT default-entry(rule，conf)>

//*其中，rule即为解析规则文件，conf即为相应的配置文件

<！ELEMENT rule(#PCDATA)>

<！ELEMENT conf(#PCDATA)>

<！--CLASS入口的配置-->

<！ELEMENT class-entry EMPTY>

<！ATTLIST class-entry

class CDATA#REQUIRED

>

公知的是，DTD是Document Type Definition的缩写。它的作用是确保XML文件的正确性，具体而言，DTD定义了XML文档中可用的合法元素。通过定义一系列合法的元素决定了XMl文档的内部结构。通常，格式正确的XML文档是满足以下三个基本结构需求的文档：(1)有一个包含所有其它元素的父(或根)元素；(2)每个开始标记都有结束标记；(3)所有元素都正确嵌套的，如以下代码所示：

<person>

    <firstname>Jane</firstname>

    <lastname>Fung</lastname>

    <nothing/>

</person>

在这种情况下，DTD适合三个基本用途：(1)对标记编制文档；(2)加强标记参数内部的一致性；(3)使XML语法分析器能够确认文档，如以下代码所示：

<！ELEMENT person(firstname，lastname)>

<！ELEMENT firstname(#PCDATA)>

<！ELEMENT lastname(#PCDATA)>

<！ELEMENT nothing EMPTY>

其中，DTD的第一行定义了上述XML文档的父元素：person；person元素有两个子元素：firstname和lastname。第二和第三行包含了元素属性#PCDATA，它表明firstname和lastname元素可能包含经过语法分析的字符数据(在这种情况下是文本)。TD文件的最后一行描述了一个空标记：nothing。从上述DTD的示例代码可以看出，任何阅读XML文档的人(以及对它进行语法分析的语法分析器)都知道person元素仅包含两个文本元素：firstname和lastname。此外，上述DTD代码还规定，在整个文档中，firstname元素必须在lastname元素之前出现。

在实际中，组件采用目录或者jar文件方式存储。其中，所述目录方式可以使用离散的class文件的方式，组件的部署目录可以在所述组件描述文件component.xml中定制。组件缺省目录结构如下：

component.xml

./class/

./lib/

./conf/

相应地，所述容器的总体目录结构如下所示：

容器的根目录

actions动作

interceptors拦截器

bin系统启动

components组件

|

adaptor通信接出组件

|

atom-service原子服务

|

channel渠道

|composite-service复杂服务

|

simple-service简单服务

conf公用平台配置(日志等)

||commons-logging.properties

||log4j.properties

doc软件文档(非生成)

dtd平台配置DTD

logs日志文件存放

server平台

||actor-config.rule.xml

||aop-config.rule.xml

||server-init.rule.xml

||server-conf.xml

||urn-conf.rule.xml

|

class平台类文件

|ext平台补丁

||

class类代码

||

lib引用类库

|

lib引用类库

|plugin平台插件

common平台/组件公用类代码

shared组件公用

||app-init.rule.xml

||app-conf.xml

||urn-conf.rule.xml

|lib引用类库

|

class类代码

temp工作用临时目录

work工作目录(平台工作生成文件用)

可以看出，容器中的组件可以分为平台组件和应用组件。平台组件是容器自身运行所依赖的组件；应用组件是针对不同的应用所特制的组件。

2、容器平台的装载：

根据组件的分类，对组件的装载采用不同的装载层次。不同层次的组件对象采用不同层次的ClassLoader(类装载器)进行装载，用以对应用组件屏蔽平台组件的实现细节，从而可以支持对象的动态重新载入，还可以定制自定义的类来源样式、优先级关系以及类装载过程，而且由于应用不直接接触到平台类和平台对象，使得应用开发者不能试图修改平台的行为，系统也将具有更高的安全性。

在这种情况下，本例中的装载层次的定义可以如图5所示，其中，SystemClassLoader(系统类装载器)是容器的最高级装载器，用于装载平台和应用共同依赖的对象资源；Server ClassLoader(平台类装载器)，用于装载平台依赖的对象资源；Components shared ClassLoader(应用类装载器)，用于装载所有应用组件共同依赖的对象资源。ComponentClassLoader(组件装载器)，用于每个组件的定制装载。

基于所述分层装载的方法可以参考图6，示出了所述组件容器平台对所有组件进行装载的流程图，具体可以包括以下步骤：

步骤601、设定系统资源路径；

步骤602、创建系统资源装载器；

步骤603、设定平台资源路径；

步骤604、创建平台资源装载器；

步骤605、设定应用资源路径；

步骤606、创建应用资源装载器；

步骤607、将当前线程的上下文装载器设为平台资源装载器；

步骤608、创建组件容器为组件管理器；

步骤609、解析平台系统启动任务配置(serverconf.xml)，生成平台系统启动任务定义对象；

步骤610、根据平台启动任务定义，解析平台系统启动任务配置，生成平台系统启动任务装载器，所述装载器包括组件路径和启动任务序列；

步骤611、设置是否进行惰性装载的标志；

步骤612、装载平台系统启动任务，所述任务包括装载平台系统组件依赖的类及属性；

步骤613、获取组件管理器，即组件容器(可参见步骤608)；

步骤614、创建平台系统组件监控器；

步骤615、向容器中注册所述平台系统组件监控器；

步骤616、获取平台系统组件路径；

步骤617、使用平台系统组件监控器向容器中装载平台系统组件；

步骤618、将当前线程的上下文装载器设为应用资源装载器；

步骤619、解析应用启动任务配置(appcon.xml)，生成应用启动任务定义对象；

步骤620、根据应用启动任务定义，解析应用启动任务配置，生成应用启动任务装载器，其中，所述装载器包含组件路径和启动任务序列；

步骤621、装载应用启动任务，所述任务包括装载应用组件依赖的类及属性；

步骤622、创建应用组件监控器；

步骤623、向所述容器中注册所述应用组件监控器；

步骤624、获取应用组件路径；

步骤625、使用应用组件监控器向容器中装载应用组件；

步骤626、设置拦截器；

步骤627、启动活动，即线程执行器。

其中，一种优选的实施方式为，装载平台系统启动任务和应用启动任务都是采用多任务装载器进行装载。参考图7，示出了一种多任务装载执行的流程图，具体可以包括以下步骤：

步骤701、遍历装载任务序列，判断是否还有装载任务，如果是，则执行步骤702；如果否，则结束多任务装载；

步骤702、获取所述装载任务开始装载；

步骤703、获取所述任务的定义，所述任务定义包括任务的配置文件和解析规则文件；

步骤704、根据所述解析规则文件解析所述任务配置文件，生成相应的对象。

参考图8，示出了在所述容器中装载组件的流程图，所述流程基于本发明优选实施例实现，具体可以包括以下步骤：

步骤801、指定当前组件装载的类装载器；

步骤802、判断是否存在未遍历的组件部署目录，如果是，则执行步骤803；如果否，则结束装载；

步骤803、遍历所述组件部署目录；

步骤804、判断所述组件资源目录是否未处理，如果是，则定位所述未处理的组件，然后执行步骤805；如果否，则返回步骤802；

步骤805、获取所述组件的描述文件Component.xml；

步骤806、解析所述组件描述文件，生成相应的组件描述对象；

步骤807、读取所述组件的装载类型；

步骤808、读取所述组件的资源路径；

步骤809、判断是否具有组件装载过程的配置文件，若是，则执行步骤810；若否，则执行步骤811；

步骤810、调用所述组件装载过程配置文件及其相应的解析规则配置文件；

步骤811、从所述资源路径中获取相应的组件资源创建组件装载器；

步骤812、依据所述组件装载类型信息创建组件装载管理器；

步骤813、在容器中注册所述组件。

3、组件的注册：

容器装载组件完成后，需要完成组件向容器的注册，这样被装载的组件才能够通过组件标识查找和调用。参考图9，示出了所述组件注册的流程图，具体可以包括以下步骤：

步骤901、创建组件的封装对象，所述封装对象包括组件标识、组件描述、组件接口等信息；

步骤902、判断是否通过所述组件装载管理器装载，如果是，则执行步骤903；如果否，则执行步骤904；

步骤903、构建组件装载管理器，然后执行步骤905；

步骤904、直接装载组件对象，然后执行步骤906；

步骤905、判断是否进行惰性装载，如果是，则执行步骤906；如果否，则执行步骤907；

步骤906、将所述组件封装对象添加到注册列表中；

步骤907、判断所述组件是否已装载，如果是，则执行步骤908，如果否，则执行步骤909；

步骤908，判断所述组件是否需要重新装载，如果是，则执行步骤909；如果否，则执行步骤906；

步骤909、通过所述组件装载管理器装载所述组件，然后执行步骤906。

4、组件的装载

所述组件装载管理器用于管理组件的通用装载过程。参考图10，所述组件的通用装载过程可以包括以下步骤：

步骤1001、更新类装载器；

步骤1002、判断是否具有组件装载过程配置文件，如果是，则执行步骤1003；如果否，则执行步骤1004；

步骤1003、解析所述组件装载过程配置文件，生成组件装载器；

步骤1004、根据所述组件描述信息直接创建组件装载器；

步骤1005、所述组件装载器装载组件，所述组件包括组件对象及其相关资源。

可以看出，组件的装载过程是可定制的。也就是说，组件可以自定义装载逻辑，在实际中，通过定义组件装载器即可定制不同组件的装载逻辑。在这种情况下，要实现组件的动态装载就很简单了，具体而言，组件的动态装载包括类的装载和配置的装载。参考图11，一种组件的动态装载过程可以包括以下步骤：

步骤1101、装载器检查组件文件的改变，并将改变通知监听者；

步骤1102、监听者获得组件改变信息；

步骤1103、容器去除发生改变的组件；

步骤1104、判断所述组件是否支持启停，如果是，则执行步骤1105；如果否，则执行步骤1106；

步骤1105、停止该组件；

步骤1106、组件装载管理器装载新组件；

步骤1107、向容器中注册新组件。

5、组件的调用：

组件的调用是组件提供服务的基础，在组件调用之前，需要从容器中获取相应的组件。参考图12，示出了一种组件调用的流程图，可以包括以下步骤：

步骤1201、判断容器中是否具有组件对象缓存，如果是，则执行步骤1202；如果否，则执行步骤1203；

步骤1202、返回所述组件对象；

步骤1203、获取组件封装对象；

步骤1204、通过所述组件封装对象获取组件对象；

步骤1205、判断是否需要创建AOP代理，如果是，则执行步骤1206；如果否，则执行步骤1209；

步骤1206、创建动态代理；

步骤1207、组件动态取得拦截器列表，并与动态代理绑定；

步骤1208、将拦截器列表加入动态代理；

步骤1209、判断组件是否支持启停，如果是，则执行步骤1210；如果否，则执行步骤1211；

步骤1210、组件启动，然后执行步骤1211；

步骤1211、将组件对象添加到缓存，然后执行步骤1202。

在本例中，在组件的获取过程中，对组件封装了一个AOP代理。利用AOP代理，在组件的调用过程中加入了面向方面的功能(即支持调用的拦截)。对于调用的拦截，可以设置以下几个拦截点：调用前拦截，调用(前后)拦截，返回拦截，调用异常拦截。拦截器是在一个方面(一组接口)的一个切入点(某些方法)调用过程中发生的动作。容器则可以用于将真实的对象(目标对象)包装成代理对象，代理对象负责在调用目标的调用中使得拦截器发生动作。由于代理接口不定，动态代理可以使用通用代理模型。组件代理(JdkDynamicProxy)按照AOP配置、使用JDK提供的API生成通用代理对象，即动态代理。动态代理对组件进行封装，实现组件接口，同时包含组件的实现。动态代理在实际执行过程中使用拦截器对组件进行拦截，并执行拦截的行为。

综上所述，本发明中的组件仅与配置文件和业务实现相关，容器仅与底层的构建(即解析和装载组件)相关，从而将底层的构建与业务实现分离开来，有效提高了容器的可扩展性和灵活性；再者，本发明的组件之间的依赖性较低，组件的类和配置文件变更后可以自动装载更新，从而进一步提高了容器的可扩展性和灵活性；此外，本发明中AOP的组件代理可以方便地为组件添加功能(如监控等)，而无需对组件本身作任何修改；最后，本发明的组件部署简单，从而可以有效节约系统资源。

参考图13，示出了本发明的一种在容器中装载组件的装置实施例的结构框图，可以包括以下单元：

预处理单元1301，用于指定当前组件装载的类装载器，并在预置存储路径下定位组件；

获取单元1302，用于获取所述组件的描述文件，所述描述文件包括装载配置信息；

解析单元1303，用于解析所述组件描述文件，生成相应的组件描述对象；

判断单元1304，用于判断所述组件描述对象的装载配置信息是否对应具体的配置文件及解析规则文件，若是，则调用第一处理单元1305；若否，则调用第二处理单元1306；

第一处理单元1305，用于提取所述配置文件，并依据所述解析规则文件解析所述配置文件，生成相应的组件对象；

第二处理单元1306，用于依据所述装载配置信息由代码定制的组件装载器产生相应的组件对象。

优选的，所述描述文件还可以包括组件标识和资源路径，在本实施例中，所述装置还可以包括以下单元：

资源提取单元，用于从所述资源路径获取所述组件相关的资源；

注册单元，用于在容器中注册组件，所述组件包括所述组件对象及其相关资源，所述组件对象由所述组件标识区分。

优选的，所述描述文件还可以包括组件装载类型信息，在本实施例中，所述装置还可以包括以下单元：

整理单元，用于依据所述组件装载类型信息整理所述组件对象。

优选的，所述预置存储路径可以包括组件部署目录和组件资源目录，在这种情况下，所述预处理单元还可以包括以下子单元：

第一判断子单元：用于判断是否存在未遍历的组件部署目录，如果是，则遍历所述组件部署目录；

第二判断子单元：用于判断所述组件资源目录是否未处理，如果是，则定位所述未处理的组件；如果否，则调用所述第一判断子单元。

优选的，所述类装载器设置在当前线程上下文中。

应用图13所示的优选实施例在容器中装载组件可以包括以下步骤：

步骤Z1、预处理单元指定当前组件装载的类装载器，并在预置存储路径下定位组件；

所述预置存储路径包括组件部署目录和组件资源目录，具体可以包括以下子步骤：

子步骤S1、第一判断子单元判断是否存在未遍历的组件部署目录，如果是，则遍历所述组件部署目录；

子步骤S2、第二判断子单元判断所述组件资源目录是否未处理，如果是，则定位所述未处理的组件；如果否，则调用所述第一判断子单元进行处理。

步骤Z2、获取单元获取所述组件的描述文件；

优选的是，所述描述文件可以包括组件标识、组件装载类型信息、装载配置信息和资源路径；

步骤Z3、解析单元解析所述组件描述文件，生成相应的组件描述对象；

步骤Z4、判断单元判断所述组件描述对象的装载配置信息是否对应具体的配置文件及解析规则文件，若是，则调用第一处理单元执行步骤Z5；若否，则调用第二处理单元执行步骤Z6；

步骤Z5、第一处理单元提取所述配置文件，并依据所述解析规则文件解析所述配置文件，生成相应的组件对象；

步骤Z6、第二处理单元依据所述装载配置信息由代码定制的组件装载器产生相应的组件对象；

步骤Z7、整理单元依据所述组件装载类型信息整理所述组件对象；

步骤Z8、资源提取单元从所述资源路径中获取所述组件相关的资源；

步骤Z9、注册单元在容器中注册组件。

所述组件包括所述组件对象及其相关资源，所述组件对象由所述组件标识区分。

对于装置实施例而言，由于其基本相应于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上对本发明所提供的一种在容器中装载组件的方法及一种在容器中装载组件的装置进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1、一种在容器中装载组件的方法，其特征在于，包括：

指定当前组件装载的类装载器，并在预置存储路径下定位组件；

获取所述组件的描述文件，所述描述文件包括装载配置信息；

解析所述组件描述文件，生成相应的组件描述对象；

判断所述组件描述对象的装载配置信息是否对应具体的配置文件及解析规则文件，

若是，则提取所述配置文件，并依据所述解析规则文件解析所述配置文件，生成相应的组件对象；

若否，则依据所述装载配置信息由代码定制的组件装载器产生相应的组件对象。

2、如权利要求1所述的方法，其特征在于，所述描述文件还包括组件标识和资源路径，所述的方法还包括：

从所述资源路径获取所述组件相关的资源；

在容器中注册组件，所述组件包括所述组件对象及其相关资源，所述组件对象由所述组件标识区分。

3、如权利要求1或2所述的方法，其特征在于，所述描述文件还包括组件装载类型信息，所述的方法还包括：

依据所述组件装载类型信息整理所述组件对象。

4、如权利要求1所述的方法，其特征在于，所述预置存储路径包括组件部署目录和组件资源目录，所述组件定位步骤还包括：

第一判断步骤：判断是否存在未遍历的组件部署目录，如果是，则遍历所述组件部署目录；

第二判断步骤：判断所述组件资源目录是否未处理，如果是，则定位所述未处理的组件；如果否，则返回所述第一判断步骤。

5、如权利要求1所述的方法，其特征在于，所述类装载器设置在当前线程上下文中。

6、一种在容器中装载组件的装置，其特征在于，包括：

预处理单元，用于指定当前组件装载的类装载器，并在预置存储路径下定位组件；

获取单元，用于获取所述组件的描述文件，所述描述文件包括装载配置信息；

解析单元，用于解析所述组件描述文件，生成相应的组件描述对象；

判断单元，用于判断所述组件描述对象的装载配置信息是否对应具体的配置文件及解析规则文件，若是，则调用第一处理单元；若否，则调用第二处理单元；

第一处理单元，用于提取所述配置文件，并依据所述解析规则文件解析所述配置文件，生成相应的组件对象；

第二处理单元，用于依据所述装载配置信息由代码定制的组件装载器产生相应的组件对象。

7、如权利要求6所述的装置，其特征在于，所述描述文件还包括组件标识和资源路径，所述的装置还包括：

资源提取单元，用于从所述资源路径获取所述组件相关的资源；

注册单元，用于在容器中注册组件，所述组件包括所述组件对象及其相关资源，所述组件对象由所述组件标识区分。

8、如权利要求6或7所述的装置，其特征在于，所述描述文件还包括组件装载类型信息，所述的装置还包括：

整理单元，用于依据所述组件装载类型信息整理所述组件对象。

9、如权利要求6所述的装置，其特征在于，所述预置存储路径包括组件部署目录和组件资源目录，所述预处理单元还包括：

第一判断子单元：用于判断是否存在未遍历的组件部署目录，如果是，则遍历所述组件部署目录；

第二判断子单元：用于判断所述组件资源目录是否未处理，如果是，则定位所述未处理的组件；如果否，则调用所述第一判断子单元。

10、如权利要求6所述的装置，其特征在于，所述类装载器设置在当前线程上下文中。

Images