专利名称：组件的分布式部署系统和方法
技术领域：
本发明涉及组件部署技术，具体而言，涉及组件的分布式部署系统和方法。
背景技术：
基于组件编程一直是增强软件可重用性、扩展性、提高软件开发效率及质量的一个重要方法，但是对于不同语言、不同平台往往需要不同的组件模型，不同实现模型的组件间无法直接交互。SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用。这种方式也使得客户的企业应用具有良好的分层架构，能够很好的分离应用的业务逻辑和IT逻辑，不但易于应用的构建，也易于应用的更改和部署。SCA全称Service Component Architecture，S卩服务组件框架。服务组件体系结构(SCA)是一个规范，它描述用于使用SOA构建应用程序和系统的模型。SCA 可大大简化使用SOA进行的应用程序开发和实现工作，已成为SOA体系架构中最重要的规范之一。一个组件通常由下列属性描述服务描述了该类型的组件所能提供的功能；引用描述了该类型的组件相关功能的依赖性；属性定义了配置参数，控制程序逻辑如何实现，例如，支付服务中使用何种货币；策略描述了组件行为策略，主要有两种策略实现策略对组件实现施加影响，例如事务、监视以及日志；互动策略定义组件如何互动，例如安全。如图1所示，一个典型的组件100包括组件属性102、组件策略、服务106和引用 108。一个组件可以使用任何用户想要的编程语言去实现，例如用BPEL去实现业务流程控制，XSLT实现转换，RUBY来编写脚本，也可以使用纯JAVA。这些服务、引用、属性以及策略如何去定义界定了一个组件的是具体实现类型。组件是最基本的单元，实际企业应用中，很少有如此简单的业务通过一个单一的组件即可满足，而是通过将多个组件组装在一起，形成复合组件，还可以将复合组件和单一组件继续组合，通过不断组装、重用已有组件，形成更大粒度的组件，满足更高层面、更复杂的业务需求，真正实现软件人一直追求的搭积木一样构建应用的梦想。随着组件被不断的组装和复用，组件间随之产生越来越复杂的依赖关系。最简单的部署方案就是将这些有依赖关系的组件全部部署在一个服务器节点上，但随着组件数量的增多以及不同组件对应用服务器的要求各有不同，集中部署往往无法保证组件所提供服务的质量(高并发性和高可用性)。此时一般采取的方案是根据组件对服务器的性能要求，将组件部署到性能指标相匹配的服务器上，比如做成本运算的组件相比一般网页检索的组件来说就需要性能更好的服务器。另外一种情况则是由于被组装的组件属于不同的部门或者组织，处于保护组件版权或者为了便于就近维护和管理组件，以及为了组件能够就近和本地数据库及其他遗留系统交互，各部门及组织的组件一般会被部署到本地的服务器上。基于上述的分析，复杂的有依赖关系的组件在特定的业务场景需要分布部署到不同的服务器节点上，这就需要解决组件分布式部署的一序列问题，如组件依赖关系分析，透明部署，错误恢复等。
SCA规范的参考实现Tuscany项目中通过域管理器，可以系统的管理组件分布式部署。具体配置的时候，物理部署包(contribution)、组件组装配置文件(composite)、运行节点(Node)、组件组装配置文件部署配置(Cloud)等均须手工注册，这不但增加了软件的运维成本，还容易出错，即服务器真正运行的状态和配置容易出现不一致。另外在组件实例管理方面，现有技术存在一个问题，就是一旦通过域管理器将组件组装配置文件注册到特定的运行节点，则节点启动时，相应的组件实例便被创建，而不是基于组件间的依赖关系去动态创建和启动相应的组件实例，这就造成有些根本就没有被引用的组件也会被创建并启动服务，造成宝贵的服务器资源浪费。同样当某个组件停止运行时，其单线依赖的组件实例也不能自动停止服务并销毁实例，而那些反向依赖此组件的组件也无法做相应的处理(比如也采取停止服务的策略)。此外在分布式环境中，有时根据安全及管理需要会修改服务器节点的配置，现在的技术框架在处理这类问题时，除了要求人工去重启部署在被修改配置的服务器节点上的所有组件，还必须通过人工重启所有引用了这些组件的其他组件，这些组件可能分布在不同的服务器节点上，在组件间有复杂依赖关系时，这是一件非常困难的工作，管理成本很高，导致管理员往往会重启所有服务器，导致其他本可以正常运行的服务中断。因此，需要一种新的组件部署技术，可以实现在分布式环境下对有复杂依赖关系的组件的方便部署和对实例的精细化管理，同时实现按需创建和启动，避免对整体系统的影响。
发明内容
本发明正是基于上述问题，提出了一种新的组件部署技术，可以实现在分布式环境下对有复杂依赖关系的组件的方便部署和对实例的精细化管理，同时实现按需创建和启动，避免对整体系统的影响。有鉴于此，本发明提出了一种组件的分布式部署系统，包括客户端、存储装置和服务器，其中，所述客户端包括第一生成模块，利用配置完成的组件项目生成组件部署包； 第一通信模块，连接至所述存储装置，用于将部署信息发送至所述存储装置，所述部署信息包括所述组件项目的信息、所述组件项目中的至少一个组件的信息、多个组件之间的关联信息以及所述组件部署包的信息；所述存储装置，连接至所述客户端和所述服务器，存储所述部署信息；所述服务器包括第二通信模块，连接至所述客户端，用于接收所述组件部署包；扫描模块，扫描所述第二通信模块接收到的所述组件部署包，并获取所述组件部署包中的组件的状态属性；部署模块，在所述状态属性为静态的情况下，所述组件为静态组件，将所述静态组件部署于对应的服务器节点，在所述状态属性为动态的情况下，所述组件为动态组件，将所述动态组件部署于对应的服务器节点，并将所述组件与所述服务器节点的对应关系存储在所述存储装置中；创建模块，为组件创建实例。在该技术方案中，客户端为组件生成部署包后，由服务器对包中的组件进行分析，若为静态组件，则可以自行生成实例， 对系统无影响，若为动态组件，则常常与其他组件有着复杂的依赖关系，需要进行记录，如将组件的标识与被部署的节点的标识进行关联后存储这两者之间的对应关系，则后续可以通过查询该对应关系，在相应的节点上创建相应的动态组件实例。同时，通过将组件与节点的对应关系进行存储，便于在组件出现问题或需要进行检测、重启等时，对单个组件或部分组件进行操作，而不必对整个系统进行重启，减少对其他组件的影响，降低系统的维护成本。在上述技术方案中，优选地，所述客户端的所述第一通信模块还用于将所述组件部署包发送至服务器节点上。在该技术方案中，客户端在生成部署包后，后续的工作如部署通常由服务器来完成，并且首先需要服务器从客户端获取其生成的部署包，但也可以由客户端在生成部署包后，直接将部署包传输至需要被部署的节点或其他预定的位置，方便服务器进行部署操作。在上述技术方案中，优选地，所述服务器还包括第二生成模块，为动态组件生成加载器，所述加载器用于加载所述动态组件中的资源。在该技术方案中，服务器可以在检测到动态组件后，为其生成加载器，以便对其进行加载，加载过程可以在OSGI (Open Service Gateway Initiative)框架下准确进行。在上述技术方案中，优选地，所述服务器还包括解析模块，用于解析组件的配置文件，并对所述组件进行第一判断，所述第一判断包括判断所述组件是否由其他组件构成， 若判断结果为否，则为所述组件创建实例，若所述判断结果为是，则进行第二判断，所述第二判断包括判断所述其他组件是否位于本地，若所述其他组件位于本地，则对所述其他组件进行所述第一判断，若所述其他组件不位于本地，则通过查询模块查询所述存储装置中存储的所述其他组件的部署信息；所述查询模块，用于对存储在所述存储装置中的部署信息进行查询；检测模块，根据所述查询模块查询到的所述部署信息，获取部署有所述其他组件的服务器节点，并检测部署于所述服务器节点上的所述其他组件是否被正常部署，若是， 则通过所述创建模块为所述其他组件创建实例。在该技术方案中，主要是为静态组件创建实例的过程，该组件若与其他组件没有依赖关系，这里的依赖关系，主要是指该组件是否由其他组件构成，若没有，则可以直接创建实例，若有依赖关系，如组件A和组件B —同构成了组件C，此时对于组件C而言，其实例的创建需要涉及组件A和组件B，此时应查询组件A和组件B的位置，若在本地，则从本地进行加载，或不是，则从之前存储的组件与节点的对应关系中查找其所在的节点，并对其进行查询。此处的处理方式，主要就是一层一层地，将处于上层构建的组件进行分析，从最底层的组件开始创建实例，并一层层地被上层组件引用。 此外，这里解析的配置文件位于组件项目中，且每一个组件对应一个配置文件。在上述技术方案中，优选地，在所述创建模块为所述其他组件创建实例前，还包括所述服务器通过所述第二通信模块连接至所述服务器节点，并通过所述检测模块获取所述服务器节点上发起调用的实例的标识，然后通过所述查询模块查询存储在所述存储装置中的对应于所述其他组件的部署信息，并获取与所述其他组件存在调用关系的调用组件的标识，以及所述服务器还包括比较模块，所述比较模块用于比较所述实例的标识和所述调用组件的标识，若所述实例的标识中没有所述调用组件的标识，则由所述创建模块为所述调用组件创建实例。在该技术方案中，位于底层的组件可能被多个组件使用，因而一些组件在引用时，该底层组件可能已经被引用过而已经创建了实例，此时该实例可以直接被后来的组件所引用，而对于尚未创建实例的底层组件，则可以在被查询时进行实例的创建。通过这种查询方式，可以避免已经创建的实例经历重复操作，简化上层组件的实例创建。根据本发明的又一方面，还提出了一种组件的分布式部署方法，包括步骤202， 利用配置完成的组件项目生成组件部署包，并存储部署信息，所述部署信息包括所述组件项目的信息、所述组件项目中的至少一个组件的信息、多个组件之间的关联信息以及所述组件部署包的信息；步骤204，扫描所述组件部署包，获取所述组件部署包中的组件的状态属性，若所述状态属性为静态，所述组件为静态组件，将所述静态组件部署于对应的服务器节点，若所述状态属性为动态，所述组件为动态组件，将所述动态组件部署于对应的服务器节点，并存储所述组件与所述服务器节点的对应关系。在该技术方案中，客户端为组件生成部署包后，由服务器对包中的组件进行分析，若为静态组件，则可以自行生成实例，对系统无影响，若为动态组件，则常常与其他组件有着复杂的依赖关系，需要进行记录，如将组件的标识与被部署的节点的标识进行关联后存储这两者之间的对应关系，则后续可以通过查询该对应关系，在相应的节点上创建相应的动态组件实例。同时，通过将组件与节点的对应关系进行存储，便于在组件出现问题或需要进行检测、重启等时，对单个组件或部分组件进行操作，而不必对整个系统进行重启，减少对其他组件的影响，降低系统的维护成本。在上述技术方案中，优选地，所述步骤202还包括将所述组件部署包发送至服务器节点上。在该技术方案中，客户端在生成部署包后，后续的工作如部署通常由服务器来完成，并且首先需要服务器从客户端获取其生成的部署包，但也可以由客户端在生成部署包后，直接将部署包传输至需要被部署的节点或其他预定的位置，方便服务器进行部署操作。在上述技术方案中，优选地，所述步骤204还包括为动态组件生成加载器，所述加载器用于加载所述动态组件中的资源。在该技术方案中，服务器可以在检测到动态组件后，为其生成加载器，以便对其进行加载，加载过程可以在OSGI框架下准确进行。在上述技术方案中，优选地，在所述步骤204之后，还包括步骤206，解析组件的配置文件，并对所述组件进行第一判断，所述第一判断包括判断所述组件是否由其他组件构成，若判断结果为否，则为所述组件创建实例，若所述判断结果为是，则进行第二判断，所述第二判断包括判断所述其他组件是否位于本地，若所述其他组件位于本地，则对所述其他组件进行所述第一判断，若所述其他组件不位于本地，则查询存储的所述其他组件的部署信息；步骤208，根据所述其他组件的所述部署信息，获取部署有所述其他组件的服务器节点，并在检测到部署于所述服务器节点上的所述其他组件被正常部署时，为所述其他组件创建实例。在该技术方案中，主要是为静态组件创建实例的过程，该组件若与其他组件没有依赖关系，这里的依赖关系，主要是指该组件是否由其他组件构成，若没有，则可以直接创建实例，若有依赖关系，如组件A和组件B —同构成了组件C，此时对于组件C而言，其实例的创建需要涉及组件A和组件B，此时应查询组件A和组件B的位置，若在本地，则从本地进行加载，或不是，则从之前存储的组件与节点的对应关系中查找其所在的节点，并对其进行查询。此处的处理方式，主要就是一层一层地，将处于上层构建的组件进行分析，从最底层的组件开始创建实例，并一层层地被上层组件引用。此外，这里解析的配置文件位于组件项目中，且每一个组件对应一个配置文件。在上述技术方案中，优选地，在所述步骤208中，所述创建实例的过程还包括连接至所述服务器节点，记录所述服务器节点上发起调用的实例的标识，并查询存储的对应于所述其他组件的部署信息，获取与所述其他组件存在调用关系的调用组件的标识，若所述实例的标识中没有所述调用组件的标识，则为所述调用组件创建实例。在该技术方案中， 位于底层的组件可能被多个组件使用，因而一些组件在引用时，该底层组件可能已经被引用过而已经创建了实例，此时该实例可以直接被后来的组件所引用，而对于尚未创建实例的底层组件，则可以在被查询时进行实例的创建。通过这种查询方式，可以避免已经创建的实例经历重复操作，简化上层组件的实例创建。通过以上技术方案，可以实现在分布式环境下对有复杂依赖关系的组件的方便部署和对实例的精细化管理，同时实现按需创建和启动，避免对整体系统的影响。
图1示出了相关技术的组件的构成示意图；图2示出了根据本发明的实施例的组件的分布式部署系统的框图；图3示出了根据本发明的实施例的组件的分布式部署方法的流程图；图4示出了根据本发明的实施例的组件的分布式部署的示意图；图5示出了根据本发明的实施例的客户端运作的流程图；图6示出了根据本发明的实施例的组件的分布式部署的流程图；图7示出了根据本发明的实施例的组件依赖关系的示意图；图8示出了根据本发明的实施例的服务器节点通信装置的框图；图9示出了根据本发明的实施例的为组件创建实例的流程图；图10示出了根据本发明的实施例的为组件创建实例的流程图；以及图11示出了根据本发明的实施例的为组件创建实例的示意图。
具体实施例方式为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式
对本发明进行进一步的详细描述。在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明并不限于下面公开的具体实施例的限制。图2示出了根据本发明的实施例的组件的分布式部署系统的框图。如图2所示，根据本发明的实施例的组件的分布式部署系统200，包括客户端 202、存储装置204和服务器206，其中，所述客户端包括第一生成模块208，利用配置完成的组件项目生成组件部署包；第一通信模块210，连接至存储装置204，用于将部署信息发送至存储装置204，部署信息包括组件项目的信息、组件项目中的至少一个组件的信息、多个组件之间的关联信息以及组件部署包的信息；存储装置204，连接至客户端202和服务器206，存储部署信息；服务器206包括第二通信模块212，连接至客户端202，用于接收组件部署包；扫描模块214，扫描第二通信模块212接收到的组件部署包，并获取组件部署包中的组件的状态属性；部署模块216，在状态属性为静态的情况下，组件为静态组件，将静态组件部署于对应的服务器节点，在状态属性为动态的情况下，组件为动态组件，将动态组件部署于对应的服务器节点，并将组件与服务器节点的对应关系存储在存储装置204中； 创建模块218，为组件创建实例；第二生成模块220，为动态组件生成加载器，加载器用于加载动态组件中的资源；解析模块222，用于解析组件的配置文件，并对组件进行第一判断， 第一判断包括判断组件是否由其他组件构成，若判断结果为否，则为组件创建实例，若判断结果为是，则进行第二判断，第二判断包括判断其他组件是否位于本地，若其他组件位于本地，则对其他组件进行第一判断，若其他组件不位于本地，则通过查询模块224查询存储装置204中存储的其他组件的部署信息；查询模块224，用于对存储在存储装置204中的部署信息进行查询；检测模块226，根据查询模块224查询到的部署信息，获取部署有其他组件的服务器节点，并检测部署于该服务器节点上的其他组件是否被正常部署，若是，则通过创建模块218为其他组件创建实例。在该技术方案中，客户端202为组件生成部署包后，由服务器206对包中的组件进行分析，若为静态组件，则可以自行生成实例，对系统无影响，若为动态组件，则常常与其他组件有着复杂的依赖关系，需要进行记录，如将组件的标识与被部署的节点的标识进行关联后存储这两者之间的对应关系，则后续可以通过查询该对应关系，在相应的节点上创建相应的动态组件实例。同时，通过将组件与节点的对应关系进行存储，便于在组件出现问题或需要进行检测、重启等时，对单个组件或部分组件进行操作，而不必对整个系统200进行重启，减少对其他组件的影响，降低系统的维护成本。在上述技术方案中，客户端202的第一通信模块208还用于将组件部署包发送至服务器节点上。在该技术方案中，客户端202在生成部署包后，后续的工作如部署通常由服务器206来完成，并且首先需要服务器206从客户端202获取其生成的部署包，但也可以由客户端202在生成部署包后，直接将部署包传输至需要被部署的节点或其他预定的位置， 方便服务器206进行部署操作。在上述技术方案中，服务器206可以在检测到动态组件后，为其生成加载器，以便对其进行加载，加载过程可以在OSGI (Open Service Gateway Initiative)框架下准确进行。在上述技术方案中，在为静态组件创建实例的过程，该组件若与其他组件没有依赖关系，这里的依赖关系，主要是指该组件是否由其他组件构成，若没有，则可以直接创建实例，若有依赖关系，如组件A和组件B —同构成了组件C，此时对于组件C而言，其实例的创建需要涉及组件A和组件B，此时应查询组件A和组件B的位置，若在本地，则从本地进行加载，或不是，则从之前存储的组件与节点的对应关系中查找其所在的节点，并对其进行查询。此处的处理方式，主要就是一层一层地，将处于上层构建的组件进行分析，从最底层的组件开始创建实例，并一层层地被上层组件引用。在上述技术方案中，在创建模块218为其他组件创建实例前，还包括服务器206 通过第二通信模块212连接至服务器节点，并通过检测模块226获取服务器节点上发起调用的实例的标识，然后通过查询模块224查询存储在存储装置204中的对应于其他组件的部署信息，并获取与其他组件存在调用关系的调用组件的标识，以及服务器202还包括比较模块228，用于比较实例的标识和调用组件的标识，若实例的标识中没有调用组件的标识，则由创建模块218为调用组件创建实例。在该技术方案中，位于底层的组件可能被多个组件使用，因而一些组件在引用时，该底层组件可能已经被引用过而已经创建了实例，此时该实例可以直接被后来的组件所引用，而对于尚未创建实例的底层组件，则可以在被查询时进行实例的创建。通过这种查询方式，可以避免已经创建的实例经历重复操作，简化上层组件的实例创建。图3示出了根据本发明的实施例的组件的分布式部署方法的流程图。如图3所示，根据本发明的实施例的组件的分布式部署方法，包括步骤302，利用配置完成的组件项目生成组件部署包，并存储部署信息，部署信息包括所述组件项目的信息、组件项目中的至少一个组件的信息、多个组件之间的关联信息以及组件部署包的信息； 步骤304，扫描组件部署包，获取组件部署包中的组件的状态属性，若状态属性为静态，则组件为静态组件，将静态组件部署于对应的服务器节点，若状态属性为动态，则组件为动态组件，将动态组件部署于对应的服务器节点，并存储组件与服务器节点的对应关系。在该技术方案中，客户端为组件生成部署包后，由服务器对包中的组件进行分析，若为静态组件， 则可以自行生成实例，对系统无影响，若为动态组件，则常常与其他组件有着复杂的依赖关系，需要进行记录，如将组件的标识与被部署的节点的标识进行关联后存储这两者之间的对应关系，则后续可以通过查询该对应关系，在相应的节点上创建相应的动态组件实例。同时，通过将组件与节点的对应关系进行存储，便于在组件出现问题或需要进行检测、重启等时，对单个组件或部分组件进行操作，而不必对整个系统进行重启，减少对其他组件的影响，降低系统的维护成本。在上述技术方案中，步骤302还包括将组件部署包发送至服务器节点上。在该技术方案中，客户端在生成部署包后，后续的工作如部署通常由服务器来完成，并且首先需要服务器从客户端获取其生成的部署包，但也可以由客户端在生成部署包后，直接将部署包传输至需要被部署的节点或其他预定的位置，方便服务器进行部署操作。在上述技术方案中，步骤304还包括为动态组件生成加载器，加载器用于加载动态组件中的资源。在该技术方案中，服务器可以在检测到动态组件后，为其生成加载器，以便对其进行加载，加载过程可以在OSGI框架下准确进行。在上述技术方案中，在步骤304之后，还包括步骤306，解析组件的配置文件，并对组件进行第一判断，第一判断包括判断组件是否由其他组件构成，若判断结果为否，则为组件创建实例，若判断结果为是，则进行第二判断，第二判断包括判断其他组件是否位于本地，若其他组件位于本地，则对其他组件进行所述第一判断，若其他组件不位于本地，则查询存储的其他组件的部署信息；步骤308，根据其他组件的部署信息，获取部署有其他组件的服务器节点，并在检测到部署于服务器节点上的其他组件被正常部署时，为其他组件创建实例。在该技术方案中，主要是为静态组件创建实例的过程，该组件若与其他组件没有依赖关系，这里的依赖关系，主要是指该组件是否由其他组件构成，若没有，则可以直接创建实例，若有依赖关系，如组件A和组件B —同构成了组件C，此时对于组件C而言，其实例的创建需要涉及组件A和组件B，此时应查询组件A和组件B的位置，若在本地，则从本地进行加载，或不是，则从之前存储的组件与节点的对应关系中查找其所在的节点，并对其进行查询。此处的处理方式，主要就是一层一层地，将处于上层构建的组件进行分析，从最底层的组件开始创建实例，并一层层地被上层组件引用。在上述技术方案中，在步骤208中，创建实例的过程还包括连接至服务器节点， 记录服务器节点上发起调用的实例的标识，并查询存储的对应于其他组件的部署信息，获取与其他组件存在调用关系的调用组件的标识，若实例的标识中没有调用组件的标识，则为调用组件创建实例。在该技术方案中，位于底层的组件可能被多个组件使用，因而一些组件在引用时，该底层组件可能已经被引用过而已经创建了实例，此时该实例可以直接被后来的组件所引用，而对于尚未创建实例的底层组件，则可以在被查询时进行实例的创建。通过这种查询方式，可以避免已经创建的实例经历重复操作，简化上层组件的实例创建。图4示出了根据本发明的实施例的组件的分布式部署的示意图。
如图4所示，根据本发明的实施例的组件的分布式部署主要由部署管理客户端装置402、部署管理服务端装置404和部署资源注册中心406构成，其中，部署管理客户端装置402用于将开发配置完成的组件项目导出为运行环境可识别的组件部署包(本发明采用 OSGI Bundle格式)，该组件部署包可以直接由部署管理客户端装置402发送至需要被安装的服务器节点上，也可以仅仅生成，之后由部署管理服务端装置404获取并进行部署，同时，部署管理客户端装置402还将第一部署信息发送至部署资源注册中心406，其中，第一部署信息中包括部署包基本信息和组件部署包所含组件信息，以及在部署管理客户端装置 402直接将组件部署包发送至节点时，第一部署信息中还包括服务器节点信息。然后，部署管理服务端装置404用于将组件部署包部署在服务器节点上，在部署过程中，对于部署包中的动态组件，还需要将包含该动态组件与其被部署的服务器节点的信号作为第二部署信息发送至部署资源注册中心406，以及在对具有依赖关系的静态组件进行实例的创建时，还需要由部署管理服务端装置404在部署资源注册中心406中查询第一部署信息和第二部署 fn息ο图5示出了根据本发明的实施例的客户端运作的流程图。如图5所示，进行组件的分布式部署时，客户端运作的流程如下步骤502，服务器节点发布，这里是指由管理客户端装置选择服务器节点并进行发布，其中，服务器节点是分布式环境中服务器管理的基本单元，用于安装组件部署包，是组件运行的载体和容器。服务器节点对应独立的服务器进程，在基于java实现的服务器中， 对应一个独立的JVM,可配置管理端口，用于服务器节点间通信。步骤504，告知部署资源注册中心，这里是指将步骤502中选择出的节点信息配置到部署资源注册中心。步骤506，组件发布，这里是指选择组件项目，用该组件项目生成组件部署包并进行发布，以及发布组件部署包内的所有组件，其中，组件项目主要用于在开发形态下管理和组件开发相关的资源，比如组件配置文件，服务定义文件(如wsdl或者java接口)，实体定义文件(xsd或者javaPOJO类)、组件实现文件(java源代码、groovy脚本或者bpel流程定义文件，取决于组件具体依赖何种技术实现)。步骤508，告知部署资源注册中心，这里是指将步骤506中生成的组件部署包的信息配置到部署资源注册中心。经过部署管理客户端装置和部署管理服务端装置的信息配置，在部署资源注册中心中可能包括的信息为服务器节点信息主要包括服务器节点编号，是否主节点，节点配置(如HTTP服务端口 )，管理端口等信息；组件部署包信息主要记录部署bundle的标识名，包版本，包路径等；组件配置信息包括组件标识，组件路径，组件所属部署包，组件类型，组件实现类型等；组件部署包和服务器节点关联信息包括组件部署包标识、服务器节点标识。步骤510，部署方案设置，这里的部署方案定义了一个分布式服务器节点集群中， 组件项目和具体服务器节点的对应关系。步骤512，部署方案执行，即由部署管理服务端装置根据步骤510中的部署方案进行组件部署包在对应的服务器节点上的部署。
图6示出了根据本发明的实施例的组件的分布式部署的流程图。如图6所示，部署管理服务端装置在对组件部署包进行部署时，具体步骤如下步骤602，扫描组件配置文件，这里的组件扫描和启动装置基于OSGI动态化的生命周期管理机制，通过对OSGI Bundle格式的组件部署资源包的启动、停止事件的监控，实现对部署资源包内组件配置文件的动态扫描。步骤604，根据步骤602的扫描结果判断组件的状态属性，若为静态组件，则进入步骤606，若为动态组件，则进入步骤618，其中，静态组件是指那些直接可配置具体绑定信息，部署后直接被启动对外提供服务的组件，而动态组件是指那些无法直接配置绑定信息， 部署后如果没有被引用则不会创建实例及启动的组件。同时，静态组件和动态组件分别又分为复合组件和原子组件。所以组件总共有如下四种类型静态原子组件，设定其配置文件扩展名为scomp ；静态复合组件，设定其配置文件扩展名为icomp ；动态原子组件，设定其配置文件扩展名为comp ；动态复合组件，设定其配置文件扩展名为ccomp。此外，动态原子组件和动态复合组件只有被静态复合组件直接或者间接使用时才会相应的创建实例并启动服务。步骤606，将组件配置文件加入OSGI服务扫描路径。步骤608，OSGI框架扫描并启动静态组件服务。步骤610，判断该静态组件是否存在依赖组件，这里的依赖组件是指与其他组件存在依赖关系，这里的组件依赖关系主要由两种，如图7所示，其中的复合组件A702由动态原子组件B704、动态原子组件C706和动态复合组件D708构成，那么称复合组件A702依赖了动态原子组件B704、动态原子组件C706和动态复合组件D708，这是第一种依赖关系，而第二种依赖关系为在复合组件A702内部，动态原子组件B704分别通过特定的服务调用了动态原子组件C706和动态复合组件D708，此处称动态原子组件B704依赖了动态原子组件C706和动态复合组件D708。当复合组件A702启动时，会通过对依赖关系的分析，启动依赖的所有组件对应的服务。此外，本发明中组件的配置文件采用XML格式定义，具有第一种依赖关系的动态组件在配置文件里通过〈import〉元素导入，比如对于上述的复合组件A702，引用部分定义如下<import resource = “ classpath:com/ufida/eip/test/componentB. comp“ /><import resource =" classpath:com/ufida/eip/test/componentC. comp" />〈import resource = " classpath:com/ufida/eip/test/componentD. ccomp" />其中 classpath 路径"classpath:com/ufida/eip/test/componentB. comp，，为 B 组件704的唯一性路径，可认为是B组件704的id，通过此路径便可从部署资源注册中心查询组件配置，组件部署所在的服务器节点等信息。第二种依赖关系则通过wire方式定义，同样对于上述的复合组件A702，B组件704 对C组件706的调用依赖定义如下<bean class="com.ufida.eip.comp.wire.support.DynamicToDynamicWire"
>
〈property name="name" value="B2CWire"/>
〈property name="wireMode" value="AUTO"/>
〈property name="sourceRefPath" value="componentB.queryReferen
ce"/>
〈property name="targetRefPath" value="componentC.queryService"/
>
</bean>从上面的定义可以看出，组件的调用依赖是通过关联一个组件上的引用和另一个组件上的服务建立起来的。调用依赖根据组件类型不同，可分为动态_静态调用依赖和动态_动态调用依赖， 上面的定义中B704和C706均为动态组件，所以B704对C706的调用依赖为动态-动态调用依赖类型。明确定义组件依赖类型和具体依赖定义后，组件依赖关系的分析可采用通用技术实现，比如XML解析技术，Spring IOC技术等等，此处不再赘述。依赖关系的处理涉及到组件实例创建及启动管理，故放到图9中进行进一步说明。步骤612，在步骤610判断为存在依赖组件时，分析得到依赖的远程组件。步骤614，创建或启动该远程组件实例，对于步骤612得到的远程组件可能是动态组件或是静态组件，若为动态组件，则可以直接进行创建或启动实例，而对于静态组件，其创建或启动实例的过程又将从步骤610开始，也就是进行下一层的解析，而且之后出现的每个静态组件都将这样处理，以层层解析的方式，直至得到最底层的组件。步骤616，若步骤610判断静态组件没有远程依赖组件时，启动原静态组件。步骤618，将步骤604中判断出的动态组件注册至部署资源注册中心，登记组件所在的服务器节点，这是为了之后在被其他组件调用时，方便进行查找。步骤620，注册动态组件类加载器，该加载器便于在OSGI框架里准确的加载组件内资源。图8示出了根据本发明的实施例的服务器节点通信装置的框图。如图8所示，服务器节点通信装置800主要负责服务器节点间通信，当机及网络中断检测；可支持按组件进行实例管理。在服务器节点如节点A启动时，会通过服务器节点通信装置800注册一个节点A 通信管理器806，该节点A的通信管理器806 —旦和其他节点如节点B的通信管理器812建立连接，则以后只要节点B或其他节点出现当机或者网络异常，与其发生过连接的节点通信管理器如节点A的通信管理器806就会得到通知事件，并由其他部分如组件实例管理器根据此通知事件进行组件实例的清理。每个动态组件启动时，都会通过服务器节点通信装置向其所部署的服务器节点注册一个用于远程组件管理的组件管理器，如对于节点A处的组件1和组件2会分别注册得到组件1管理器808和组件2管理器810，而对于节点B处的组件3和组件4会分别注册得到组件3管理器814和组件4管理器816，则如组件1可以通过节点A通信管理器806远程访问节点B处的组件3，通过对组件管理器的利用，从而可以创建、初始化及停止远程组件实例。图9示出了根据本发明的实施例的为组件创建实例的流程图。如图9所示，为组件创建实例的流程如下步骤902，解析组件配置文件，分析组件的构成，图6中提到静态组件会被触发而创建实例，并启动服务，而动态组件则不会，动态组件只有在被静态组件组装依赖的时候， 才会创建相应的实例，所以组件实例创建流程从最开始的时候，接收的是静态组件配置文件。步骤904，判断该组件是否由其他组件构成，也就是说分析该组件与其他组件是否存在上述的第一种依赖关系，若存在则进入步骤912，否则，进入步骤906。步骤906，判断该组件是否为静态组件，若是，则进入步骤908，否则进入步骤910。步骤908，为该静态组件创建实例并启动静态组件。步骤910，为该动态组件创建动态组件实例，在图6中，对于动态组件只是进行信息注册等，而既不创建实例也不启动服务，而这里，已经判断了其没有依赖关系，且由配置文件解析得到，则直接创建实例。步骤912至步骤928，都是对导入的组件列表中的每一个组件路径进行的操作，其中，组件列表为步骤904中判断由其他组件构成时，将参与构成的组件的标识记录在组件列表中得到的。步骤912，通过路径在本地加载导入的组件，这里由于需要依赖其他的组件，因此系统被依赖的组件能够存在于本地。步骤914，判断该组件是否存在于本地，若是，则返回步骤902，对该组件的状态属性和是否依赖于其他组件进行解析，否则进入步骤916。步骤916，判断部署资源注册中心是否存在相关信息，在生成部署包后，部署管理客户端装置会向部署资源注册中心发送第一部署信息，且部署管理服务端装置会在部署上述部署包时，向部署资源注册中心发送第二部署信息，从而可以通过对部署资源注册中心的查询，得到组件的信息。在判断为是是，进入步骤920，否则进入步骤918。步骤918，提示依赖的组件没有发布，然后结束。步骤920至步骤926为对每一个部署有该组件的服务器节点的操作。步骤920，通过服务器通信装置里的远程组件管理器查询目标服务器节点，这里的通信过程已经通过图8进行了详细说明。步骤922，判断组件是否正常部署，若正常，则进入步骤926，否则进入步骤924。步骤924，通过记入日志以警告管理员服务器节点上的组件部署不正常。步骤926，记入有效组件部署信息列表，这里是指在查询到所依赖的组件，并且该组件被正常部署的话，将该组件的标识进行记录，并形成有效组件部署信息列表。步骤928，生成远程组件实例代理，这里将结合图10对远程组件实例的创建过程进行分析，具体过程如下步骤1002，连接远程服务器节点，这是根据步骤926中形成的有效组件部署信息列表中的信息，连接到相关联的组件所在的服务器节点。步骤1004，获取远程组件管理器，该管理器用于管理对应的组件的实例创建过程。步骤1006，调用创建命令，用于进行实例的创建。步骤1008，记录发起调用的组件实例，将向该组件发起过调用的组件记录下来，也就是说，对于组件之间的调用，需要进行记录和存储，方便之后的查找和使用。步骤1010，分析组件间调用依赖关系，对于调用该组件且具有依赖关系的组件，需要进行步骤1012的操作。步骤1012，从组件管理器中按组件实例ID查找组件实例，对于创建的实例，都拥有唯一对应的ID，则可以通过ID查找已经创建的组件实例。步骤1014，根据查找结果，判断实例是否存在，若存在，则可以对该实例直接进行引用，否则进入步骤1016。步骤1016，创建组件实例，可以看出，图10的过程，是为了对依赖的组件进行分析，并对已经创建实例的组件进行直接引用，而没有创建的再进行创建，从而节省资源和时间，方便管理。步骤930，创建复合静态组件实例并启动。图11示出了根据本发明的实施例的为组件创建实例的示意图。如图11所示，组件实例创建流程主要利用的是上述第一种依赖关系，解决的是按需创建组件实例的问题，并没有说明动态组件实例上的绑定服务是如何被启动的。远程组件实例管理装置基于组件正向的调用型依赖关系，可有效解决按需启动组件实例上绑定服务的问题；基于组件反向的调用依赖关系，可解决服务器节点配置变化而导致的人工重启问题，还可解决因为整个组件依赖链中因为某个组件实例失效，其他组件实例虽然正常运行但却无法提供有效服务的问题。下面基于图11详细描述基于正反向调用型依赖关系解决以上问题的工作原理假设复合静态组件S 1102通过上述第一种方式依赖了动态复合组件A 1104， 基于组件实例创建流程，创建复合静态组件S 1102的实例Si，相应的会创建复合组件A 1104、动态原子组件B 1106、动态原子组件C1108及动态复合组件D 1110的组件实例，分别记为Ai，Bi，Ci及Di，其中，Ai记录了反向组装依赖关系{Si组装依赖Ai}；Bi记录了反向组装依赖关系{Ai组装依赖Bi}；Ci记录了反向组装依赖关系{Ai组装依赖Ci}，同时记录了反向调用依赖关系{Bi 组装依赖Ci}；Di记录了反向组装依赖关系{Ai组装依赖Di}，同时记录了反向调用依赖关系{Bi 组装依赖Di}。组件扫描和启动装置启动Si上的服务Ssi，服务Ssi实际上由服务Asi提供，SCA里称这种自身并不真正提供服务实现的服务为升级服务(Promoting Service)，同样Asi由Bsi 提供，所以启动Ssi时会根据服务依赖关系去启动BS1。当服务启动时，通过对组件调用依赖的分析，即查询引用Bei和引用Be2分别连接的服务Csi及服务Dsi，并启动Csi和Dsi ；如果组件C1108和组件D 1110同样有调用依赖存在，则按同样方法递归处理即可，通过这种方法可有效解决不被弓I用的服务也被启动的问题。
现在假设组件C 1108部署在服务器节点NodeC上，因为管理需要，NodeC的配置发生变化，比如原来Csi提供http服务地址为http://192. 168. 1. 122 :8080/csl，现在修改 http服务端口为8088。NodeC配置一旦修改，需要重启NodeC，组件C 1108相应也被重启， 而组件C重启时，组件管理器基于持久化机制恢复之前的组件实例Ci。组件实例Ci通过绑定信息版本，判断是否服务绑定信息发生变化，如果没有变化，则直接略过，如果绑定信息变化了，则取得记录的反向依赖关系，得知Bi调用依赖了 Ci，取得Bi对应的组件管理器，通过组件管理器更新组件Bi的服务绑定信息并重启Bi。通过以上方法，可有效解决服务器节点配置变化而导致的人工重启问题。另外如果整个组件依赖链中因为某个组件实例失效，也是通过同样的反向调用依赖关系的分析而实现的，工作原理相同，此处不再赘述。以上结合附图详细说明了本发明的技术方案，考虑到相关技术中，容易造成宝贵的服务器资源浪费，而当某个组件停止运行时，往往导致管理员会重启所有服务器，导致其他本可以正常运行的服务中断。因此，本发明通过提出了一种组件部署系统和一种组件部署方法，可以实现在分布式环境下对有复杂依赖关系的组件的方便部署和对实例的精细化管理，同时实现按需创建和启动，避免对整体系统的影响。以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种组件的分布式部署系统，其特征在于， 包括客户端、存储装置和服务器，其中，所述客户端包括第一生成模块，利用配置完成的组件项目生成组件部署包；第一通信模块，连接至所述存储装置，用于将部署信息发送至所述存储装置，所述部署信息包括所述组件项目的信息、所述组件项目中的至少一个组件的信息、多个组件之间的关联信息以及所述组件部署包的信息；所述存储装置，连接至所述客户端和所述服务器，存储所述部署信息； 所述服务器包括第二通信模块，连接至所述客户端，用于接收所述组件部署包； 扫描模块，扫描所述第二通信模块接收到的所述组件部署包，并获取所述组件部署包中的组件的状态属性；部署模块，在所述状态属性为静态的情况下，所述组件为静态组件，将所述静态组件部署于对应的服务器节点，在所述状态属性为动态的情况下，所述组件为动态组件，将所述动态组件部署于对应的服务器节点，并将所述组件与所述服务器节点的对应关系存储在所述存储装置中；创建模块，为组件创建实例。
2.根据权利要求1所述的组件的分布式部署系统，其特征在于，所述客户端的所述第一通信模块还用于将所述组件部署包发送至服务器节点上。
3.根据权利要求1所述的组件的分布式部署系统，其特征在于，所述服务器还包括 第二生成模块，为动态组件生成加载器，所述加载器用于加载所述动态组件中的资源。
4.根据权利要求1至3中任一项所述的组件的分布式部署系统，其特征在于，所述服务器还包括解析模块，用于解析组件的配置文件，并对所述组件进行第一判断，所述第一判断包括判断所述组件是否由其他组件构成，若判断结果为否，则为所述组件创建实例，若所述判断结果为是，则进行第二判断，所述第二判断包括判断所述其他组件是否位于本地，若所述其他组件位于本地，则对所述其他组件进行所述第一判断，若所述其他组件不位于本地，则通过查询模块查询所述存储装置中存储的所述其他组件的部署信息；所述查询模块，用于对存储在所述存储装置中的部署信息进行查询； 检测模块，根据所述查询模块查询到的所述部署信息，获取部署有所述其他组件的服务器节点，并检测部署于所述服务器节点上的所述其他组件是否被正常部署，若是，则通过所述创建模块为所述其他组件创建实例。
5.根据权利要求4所述的组件的分布式部署系统，其特征在于，在所述创建模块为所述其他组件创建实例前，还包括所述服务器通过所述第二通信模块连接至所述服务器节点，并通过所述检测模块获取所述服务器节点上发起调用的实例的标识，然后通过所述查询模块查询存储在所述存储装置中的对应于所述其他组件的部署信息，并获取与所述其他组件存在调用关系的调用组件的标识，以及所述服务器还包括比较模块，所述比较模块用于比较所述实例的标识和所述调用组件的标识，若所述实例的标识中没有所述调用组件的标识，则由所述创建模块为所述调用组件创建实例。
6.一种组件的分布式部署方法，其特征在于，包括步骤202，利用配置完成的组件项目生成组件部署包，并存储部署信息，所述部署信息包括所述组件项目的信息、所述组件项目中的至少一个组件的信息、多个组件之间的关联信息以及所述组件部署包的信息；步骤204，扫描所述组件部署包，获取所述组件部署包中的组件的状态属性，若所述状态属性为静态，则所述组件为静态组件，将所述静态组件部署于对应的服务器节点，若所述状态属性为动态，则所述组件为动态组件，将所述动态组件部署于对应的服务器节点，并存储所述组件与所述服务器节点的对应关系。
7.根据权利要求6所述的组件的分布式部署方法，其特征在于，所述步骤202还包括将所述组件部署包发送至服务器节点上。
8.根据权利要求6所述的组件的分布式部署方法，其特征在于，所述步骤204还包括为动态组件生成加载器，所述加载器用于加载所述动态组件中的资源。
9.根据权利要求6至8中任一项所述的组件的分布式部署方法，其特征在于，在所述步骤204之后，还包括步骤206，解析组件的配置文件，并对所述组件进行第一判断，所述第一判断包括判断所述组件是否由其他组件构成，若判断结果为否，则为所述组件创建实例，若所述判断结果为是，则进行第二判断，所述第二判断包括判断所述其他组件是否位于本地，若所述其他组件位于本地，则对所述其他组件进行所述第一判断，若所述其他组件不位于本地，则查询存储的所述其他组件的部署信息；步骤208，根据所述其他组件的所述部署信息，获取部署有所述其他组件的服务器节点，并在检测到部署于所述服务器节点上的所述其他组件被正常部署时，为所述其他组件创建实例。
10.根据权利要求9所述的组件的分布式部署方法，其特征在于，在所述步骤208中，所述创建实例的过程还包括连接至所述服务器节点，记录所述服务器节点上发起调用的实例的标识，并查询存储的对应于所述其他组件的部署信息，获取与所述其他组件存在调用关系的调用组件的标识，若所述实例的标识中没有所述调用组件的标识，则为所述调用组件创建实例。
全文摘要
本发明提供了一种组件的分布式部署系统和方法，包括步骤202，利用配置完成的组件项目生成组件部署包，并存储部署信息，部署信息包括组件项目的信息、组件项目中的至少一个组件的信息、多个组件之间的关联信息以及组件部署包的信息；步骤204，扫描组件部署包，获取组件部署包中的组件的状态属性，若状态属性为静态，则将静态组件部署于对应的服务器节点，若状态属性为动态，则将动态组件部署于对应的服务器节点，并存储组件与服务器节点的对应关系。通过本发明的技术方案，可以实现在分布式环境下对有复杂依赖关系的组件的方便部署和对实例的精细化管理，同时实现按需创建和启动，避免对整体系统的影响。
文档编号H04L29/08GK102360308SQ20111029558
公开日2012年2月22日 申请日期2011年9月29日 优先权日2011年9月29日
发明者程操红 申请人:用友软件股份有限公司