CN102053860B - 基于CORBA的OSGi分布式扩展系统及方法 - Google Patents

Abstract

本发明提供一种基于CORBA的OSGi分布式扩展系统，包括OSGi内核以及运行在该内核上的服务注册中心，还包括有CORBA分布式支持模块、CORBA名字服务模块、服务提供者模块以及消费者模块；其中，服务提供者模块将该模块提供的可供远程访问的服务在服务注册中心注册；CORBA分布式支持模块监控可被远程访问的服务在服务注册中心的注册，为该服务生成相应的服务端代理，并向本地OSGi内核提供基于CORBA的远程服务调用；消费者模块查询位于其他结点上的远程服务；CORBA名字服务模块给出关于该远程服务所在结点的信息；CORBA分布式支持模块根据该信息生成客户端代理，由客户端代理实现对远程服务的使用。

Description

基于CORBA的OSGi分布式扩展系统及方法

技术领域

本发明涉及一种OSGi分布式扩展系统及方法，特别涉及基于CORB-A的OSGi分布式扩展系统及方法。

背景技术

软件行业的工业化趋势导致了构件技术的产生。能够像硬件系统那样，将软件组合起来构建软件系统是软件行业多年来追求的目标。可以说，构件技术的出现是对传统软件开发过程的一次变革。Java是目前最主要的企业级软件开发技术，但是已有Java标准没有提供对构件开发的支持，阻碍了构件技术在Java中的应用。

OSGi(Open Services Gateway Initiative，开放服务网关协议)是由1999年成立的OSGi联盟所提出的一个开放的服务规范，该规范为Java提供了动态化、面向服务的构件化开发支持。采用OSGi技术能够显著降低软件开发各个阶段的复杂度，使得代码更加容易编写与测试，构建系统更加简单，部署更加可管理，也提高了软件的重用性和运行时的动态配置能力。

OSGi在本质上是一个为Java提供的动态、模块化的系统。OSGi中的运行于OSGi内核上的模块被称作bundle，bundle是由普通的JAR文件加上额外的元信息描述构成的。bundle模块之间通过元信息描述显式地声明包的导入、导出以实现代码和资源的共享，而OSGi内核自动地处理bundle模块之间的依赖解析。同时，OSGi也提供了一个面向服务的编程模型，在OSGi中服务就是普通的Java对象，bundle模块可以通过集中的服务中心来注册其所提供的服务，而其他bundle模块可以通过注册中心查询、监听、获取服务来实现bundle模块之间松耦合的协作，服务的契约用Java接口和一系列服务属性描述。需要指出的是，标准OSGi规范中只提供了针对单一JVM(Java Virtual Machine)的面向服务的编程模型。

OSGi所具有的动态化、模块化、面向服务的特点使得它不再局限于嵌入式领域，而是成为一个通用的动态组件开发环境，在各个领域得到了大量应用，如家居网关、智能手机、汽车制造业等。近年来，随着Eclipse错误！未找到引用源。采用OSGi来重构其插件体系结构和Spring与OSGi的结合，OSGi在企业计算领域也得到了越来越广泛的应用，如IBM的WebSphere和Oracle/BEA的WebLogic等都使用了OSGi技术。

OSGi规范为单个JVM内的Java应用提供了一个高度动态和设计良好的服务模型，但企业计算领域大规模、异构性的特点为标准OSGi规范提出了支持分布式处理的需求，即要求OSGi能够支持远程机器结点上的服务发现与调用，并支持企业应用拓扑，从而提高可用率、可靠性及可伸缩性。因此，提供OSGi分布式扩展机制以支持多进程、多JVM、多个结点、多种语言的企业计算是亟需解决的问题。OSGi联盟针对企业计算领域对OSGi的需求于2007年成立了企业专家组。在2009年4月，OSGi联盟的企业专家组制定完成了针对OSGi分布式扩展的RFC 119规范，但该规范只是给出了一个通用的解决方案，并没有涉及到与具体技术相结合的具体实现细节。Apache CXF项目成立了一个名称为D-OSGi(Distributed OSGi)的子项目作为RFC 119规范的参考实现，D-OSGi使用Web Service来实现远程服务调用。但是D-OSGi在服务发现方面还不完善，不满足OSGi环境中对服务的高度动态性的要求。而且D-OSGi与企业计算领域的主流通信协议IIOP(CORBA标准的通信协议)不兼容，难以实现对现有大量遵循CORBA标准的应用系统的集成和互操作。

此外，在EclipseCon2007大会上还提出了一个名称为R-OSGi(Remoting-OSGi)的OSGi分布式处理项目。R-OSGi遵循OSGi规范，使用对接口进行字节码分析的方式来动态产生服务代理bundle，以实现远程服务的透明访问，并使用SLP(Service Location Protocol)实现远程服务发现。但是R-OSGi针对嵌入式领域采用了基于消息的特定的远程互操作协议，无法满足企业计算领域对于基于标准互操作协议(如IIOP)的非OSGi系统交互的需求，并且R-OSGi在服务使用上不透明，服务消费者要实现R-OSGi自定义的服务监听接口，对原有的OSGi编程模型有一定的侵入性。

发明内容

本发明的目的是克服现有技术中的OSGi不支持分布式处理的缺陷，从而提供一种基于CORBA的OSGi分布式扩展系统及其对应的方法。

为了实现上述目的，本发明提供了一种基于CORBA的OSGi分布式扩展系统，包括OSGi内核以及运行在该内核上的服务注册中心，还包括有运行于所述OSGi内核上的CORBA分布式支持模块、CORBA名字服务模块、服务提供者模块以及消费者模块；其中，

所述的服务提供者模块将该模块提供的可供远程访问的服务在所述的服务注册中心注册；所述的CORBA分布式支持模块监控所述可被远程访问的服务在所述服务注册中心的注册，为该服务生成相应的服务端代理，并向本地OSGi内核提供基于CORBA的远程服务调用；

所述的消费者模块查询位于其他结点上的远程服务；所述的CORBA名字服务模块给出关于该远程服务所在结点的信息；所述的CORBA分布式支持模块根据该信息生成客户端代理，由所述客户端代理实现对远程服务的使用。

上述技术方案中，所述的CORBA分布式支持模块包括服务监控器、服务端代理生成器以及客户端代理生成器；其中，

所述的服务监控器用于监控注册到服务注册中心上的服务；

所述的服务端代理生成器用于生成服务端代理，所述的服务端代理用于在接收到ORB的CORBA调用请求后，将该请求转化为Java调用请求，然后根据Java调用请求调用服务，将服务的处理结果由Java形式再转变为CORBA形式后返回给ORB；

所述的客户端代理生成器用于生成客户端代理，所述的客户端代理用于实现对位于其他结点上的远程服务的接口，将该接口中的方法的Java调用请求转换成对所述远程服务的服务端代理的CORBA调用请求。

上述技术方案中，所述的服务监控器采用OSGi内核所提供的ServiceTracker类实现。

上述技术方案中，所述的服务端代理通过继承CORBA中的org.omg.PortableServer.DynamicImplementation类并实现其voidinvoke(ServerRequest request)方法来实现。

上述技术方案中，所述的客户端代理采用Java的动态接口代理技术实现，由java.lang.reflect.Proxy类在运行期时根据服务接口定义，并采用Java反射功能动态生成。

本发明还提供了一种基于CORBA的OSGi分布式扩展方法，在安装有所述的基于CORBA的OSGi分布式扩展系统的结点上实现，包括：

步骤1)、允许远程访问的服务通过服务提供者模块在其所在结点的服务注册中心上注册；

步骤2)、为所述允许远程访问的服务生成服务端代理；

步骤3)、远程结点上的消费者模块向该结点上的服务注册中心查询所要访问的服务；

步骤4)、当所要访问的服务在远程结点本地不存在时，所述远程结点生成客户端代理，通过所述客户端代理访问所述服务端代理，从而实现对所述服务的访问。

上述技术方案中，所述的步骤2)包括：

步骤2-1)、服务所在结点上的CORBA分布式支持模块监控到注册事件后，为该服务生成相应的服务端代理；

步骤2-2)、所述CORBA分布式支持模块将所述服务端代理加载到POA上，生成CORBA对象引用；

步骤2-3)、在服务所在结点上的CORBA名字服务模块注册所述服务端代理的CORBA对象引用以及所述服务的本地服务注册信息。

上述技术方案中，所述的步骤4)包括：

步骤4-1)、远程结点上的CORBA分布式支持模块通过该结点上的CORBA名字服务模块查询哪个结点上存在所需要的服务；

步骤4-2)、远程结点上的CORBA分布式支持模块根据查询结果生成所需服务的客户端代理，将对所述客户端代理的所有方法调用转变为对服务所在结点上服务端代理的调用；

步骤4-3)、远程结点上的CORBA分布式支持模块将所需服务的客户端代理注册到本地的服务注册中心。

本发明的优点在于：

本发明能够保持OSGi原有的编程模型和轻量级特点，使得OSGi服务消费者能够调用远程机器结点上的服务，适用于大规模、异构性的企业计算环境，并支持企业应用拓扑，从而提高可用率、可靠性及可伸缩性。

附图说明

图1为本发明的OSGi分布式扩展系统的结构示意图；

图2为本发明的OSGi分布式扩展方法的流程图。

具体实施方式

下面结合附图和具体实施方式对本发明进行说明。

公用对象请求代理体系结构(Common Object Request BrokerArchitecture，缩写为CORBA)是对象管理组织(Object Management Group)应对当今快速增长的软硬件协同工作能力的要求而提出的方案。CORBA是非常成熟的分布式中间件技术，使用CORBA技术来实现OSGi的远程服务调用不仅能够支持分布在网络中不同机器结点的OSGi应用之间的远程服务调用，同时由于底层采用国际标准IIOP协议，因此也支持与企业计算领域中大量CORBA遗留系统的互操作。基于上述原因，本发明的OSGi分布式扩展系统在CORBA的基础上实现。

在图1中给出了本发明的OSGi分布式扩展系统的示意图。从图中可以看出，本发明的OSGi分布式扩展系统除了包括有OSGi内核以及运行在该内核上的服务注册中心外，还包括有CORBA分布式支持模块、CORBA名字服务模块、服务提供者模块以及消费者模块。其中的CORBA分布式支持模块、CORBA名字服务模块、服务提供者模块以及消费者模块都安装并运行在所述的OSGi内核上。下面对该系统中所涉及的各个模块的功能加以说明。

所述的OSGi内核对运行于其上的OSGi应用模块提供了包括资源共享、生命周期管理和基于服务的协同等多种功能。OSGi内核的实现是现有的公知技术，因此不再对其做具体的说明。

所述的服务注册中心用于实现本地OSGi内核中面向服务的编程模式，某一bundle模块可以通过服务中心来注册其所提供的服务，而其他bundle模块可以通过注册中心查询、监听、获取服务，从而实现bundle模块之间松耦合的协作。服务注册中心的实现也是现有的公知技术。

所述的CORBA分布式支持模块用于监控本地服务注册中心的服务注册和查询情况，并给本地OSGi内核提供基于CORBA的远程服务调用能力。根据CORBA分布式支持模块的上述功能，该模块可进一步包括服务监控器、服务端代理生成器以及客户端代理生成器。

服务监控器用于监控注册到服务注册中心上的服务。服务监控器有多种实现方式，在本实施例中优选OSGi内核所提供的ServiceTracker类实现。ServiceTracker主要针对OSGi中服务的高度动态性而提出，能够帮助服务消费者灵活地使用服务。ServiceTracker类可以通过一个字符串来描述所要使用的服务，并有三个回调函数分别用于处理以下三种情况：(1)当所需的服务到来时该怎么处理；(2)当所需的服务被注销时该怎么处理；(3)当所需的服务发生改变(如服务属性的改变)时怎么处理。服务监控器对注册到本地服务中心的服务的监控就通过上述三个回调函数实现的。当注册到本地服务注册中心的某一服务的属性标识为可被远程访问时，服务监控器调用用于处理第一种情况的回调函数，在这一回调函数中先通过CORBA名字服务模块获取所注册远程服务的对象引用，并用该对象引用完成服务端代理动态生成等操作。在其他实施例中，服务监控器还可以采用其他实现方式，例如，由服务消费者所在bundle模块的初始化方法去调用服务注册中心所提供的查询、获取服务的接口来监控服务的注册。

服务端代理生成器的作用在于为本地的可被远程访问的服务生成服务端代理。所述的服务端代理的作用是当接收到ORB的CORBA调用请求后，负责将该请求转化为Java调用请求，然后根据Java调用请求调用服务，将服务的处理结果由Java形式再转变为CORBA形式后返回给ORB。一个可被远程访问的服务对应有一个特定的服务端代理。所述服务端代理的生成、运行、终结是动态的，其生存周期与其所关联的可被远程访问的服务的生存周期有关。服务端代理是通过继承CORBA中的org.omg.PortableServer.DynamicImplementation类并实现其voidinvoke(ServerRequest request)方法来实现的。其中的参数request来自ORB对服务对象的CORBA调用请求的封装，在invoke方法中通过对request的提取以获取方法名和调用参数等信息，然后把相应的CORBA调用请求转换为对通过监控获得的实际服务对象引用的Java方法调用，再将对实际服务对象引用的方法的执行结果转换为CORBA调用结果回填到request中，通过request返回给ORB。

客户端代理生成器的作用在于为位于其他结点上的远程服务生成客户端代理。所述的客户端代理的作用是实现对位于其他结点上的远程服务的接口，将该接口中的方法的Java调用请求转换成对所述远程服务的服务端代理的CORBA调用请求。客户端代理与前述的服务端代理相类似，其生成、运行、终结是动态的，其生存周期与其所关联的位于其他结点上的远程服务的生存周期有关。客户端代理的实现采用了Java的动态接口代理技术，由java.lang.reflect.Proxy类在运行期时根据服务接口定义，并采用Java反射功能动态生成。客户端代理所采用的java.lang.reflect.Proxy类与服务端代理所采用的java.lang.reflect.InvocationHandler类相结合，可以把对服务接口中方法的Java调用请求转换成对服务的服务端代理的CORBA调用请求。由于服务的客户端代理的生成是运行时动态生成的，因此对服务端代理的CORBA调用请求需要通过CORBA动态调用接口(DynamicInvocation Interface)来构造，CORBA动态调用接口使得CORBA客户端可在运行时动态地构造对目标对象的方法调用请求。

以上是对CORBA分布式支持模块的进一步描述，需要指出的是，虽然一个结点的CORBA分布式支持模块中可以同时包含服务端代理生成器和客户端代理生成器，但对于某一特定服务而言，服务端代理生成器和客户端代理生成器不会同时起作用。对于同一服务的服务端代理和客户端代理而言，两种代理会位于不同的结点上。

所述的CORBA名字服务模块用于辅助CORBA分布式支持模块为本地OSGi内核提供远程服务的注册与查询能力。CORBA名字服务模块通过在本地服务注册中心注册的DiscoveryService类实现。所述的DiscoveryService类是对CORBA名字服务的封装，它提供了服务注册、服务注销和服务查询三个方法。当前述的CORBA分布式支持模块为一可被远程访问的服务生成服务端代理时，将调用DiscoveryService类中的服务注册方法，通过该方法将可被远程访问的服务的接口名、相关属性的描述、服务端代理的CORBA对象引用注册到CORBA名字服务上，使得网络其他结点上的CORBA分布式支持模块可以借助CORBA名字服务模块的DiscoveryService类中的服务查询方法查询到可被远程访问的服务所对应的CORBA对象引用。需要说明的是，上述描述中所提到的CORBA名字服务与CORBA名字服务模块是两个不同的概念。CORBA名字服务以独立进程的形式运行在网络中的某一结点上，它可以将逻辑名和对象名相关联，服务提供者模块使用逻辑名将对象引用注册到名字服务中，随后向该服务的消费者模块发布其逻辑名；消费者模块得知逻辑名之后，就可以使用该逻辑名到名字服务中解析出相应的对象引用，调用服务对象支持的方法。

所述的服务提供者模块用于提供服务，并可将服务连同其服务属性注册到本地服务注册中心上。所述的消费者模块用于向消费者提供使用服务的平台。服务提供者模块与消费者模块是从这些模块在某一服务中所扮演的角色所做的区分，运行于OSGi内核之上的bundle模块都有可能是服务提供者模块或消费者模块。

在对本发明的OSGi分布式扩展系统做上述说明的基础上，下面结合具体的实例，对在该系统上如何实现对远程服务的访问加以说明。

仍然以图1为例，在一个实施例中，结点1与结点2是分布在网络上的两个不同的结点，在这两个结点上各自安装并运行着前述的OSGi分布式扩展系统。在结点2上存在有服务A，且这一服务是允许被远程访问的。如图2所示，结点2上的服务提供者模块向本地的服务注册中心注册服务A，在注册的过程中同时将该服务允许远程访问的信息通过属性加以标识(步骤201)。结点2上的CORBA分布式支持模块通过向本地的服务注册中心注册服务监控器，以监控注册到本地服务注册中心的属性表示为可被远程访问的服务，当监控到本地服务注册中心发生了远程服务A的注册事件，服务监控器通过服务注册中心获取服务A的对象引用，然后由服务端代理生成器使用服务A的对象引用为远程服务A动态地生成服务A的服务端代理(步骤202)。结点2上的CORBA分布式支持模块在生成服务A的服务端代理后，还要将该代理加载到POA上，从而生成CORBA对象引用。这一步骤可通过CORBA中已有的技术实现，因此不对其具体实现过程加以说明(步骤203)。将前面得到的服务A的服务端代理的CORBA对象引用与服务A的本地相关服务注册信息注册到结点2上的CORBA名字服务上(步骤204)。通过上述操作，结点2上的服务A将允许网络上的其它结点对其做基于CORBA的远程调用。

在某一时刻，结点1上的消费者模块通过OSGi的编程接口向本地服务注册中心来查询服务A(步骤205)。结点1上的CORBA分布式支持模块监控到本地服务注册中心的对服务A的查询请求后，首先判断本地是否存在服务A，由于结点1上的OSGi服务注册中心没有服务A，于是结点1上的CORBA分布式支持模块通过CORBA名字服务模块查询网络上的远程服务A(步骤206)。结点1上的CORBA分布式支持模块的客户端代理生成器根据获取的服务A的接口信息和服务A的服务端代理的CORBA对象引用，利用Java反射机制动态地生成服务A的客户端代理(步骤207)。结点1上的CORBA分布式支持模块将生成的远程服务A的客户端代理通过本地服务注册中心的服务注册接口注册到结点1上的服务注册中心(步骤208)。结点1上的服务注册中心由于注册了远程服务A的客户端代理，消费者模块就可以直接使用服务A的客户端代理，从而达到透明地使用远程服务A的目的。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，对本发明的技术方案进行修改或者等同替换，都不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。

Claims (8)

1.一种基于CORBA的OSGi分布式扩展系统，包括OSGi内核以及运行在该内核上的服务注册中心，其特征在于，还包括有运行于所述OSGi内核上的CORBA分布式支持模块、CORBA名字服务模块、服务提供者模块以及消费者模块；其中，

所述的服务提供者模块将该模块提供的可供远程访问的服务在所述的服务注册中心注册；所述的CORBA分布式支持模块监控所述可被远程访问的服务在所述服务注册中心的注册，为该服务生成相应的服务端代理，并向本地OSGi内核提供基于CORBA的远程服务调用；

所述的消费者模块查询位于其他结点上的远程服务，所述其他结点区别于该消费者模块所在的结点；所述的CORBA名字服务模块给出关于该远程服务所在结点的信息；所述的CORBA分布式支持模块根据该信息生成客户端代理，由所述客户端代理实现对远程服务的使用。

2.根据权利要求1所述的基于CORBA的OSGi分布式扩展系统，其特征在于，所述的CORBA分布式支持模块包括服务监控器、服务端代理生成器以及客户端代理生成器；其中，

所述的服务监控器用于监控注册到服务注册中心上的服务；

所述的服务端代理生成器用于生成服务端代理，所述的服务端代理用于在接收到ORB的CORBA调用请求后，将该请求转化为Java调用请求，然后根据Java调用请求调用服务，将服务的处理结果由Java形式再转变为CORBA形式后返回给ORB；

所述的客户端代理生成器用于生成客户端代理，所述的客户端代理用于实现对位于其他结点上的远程服务的接口，将该接口中的方法的Java调用请求转换成对所述远程服务的服务端代理的CORBA调用请求。

3.根据权利要求2所述的基于CORBA的OSGi分布式扩展系统，其特征在于，所述的服务监控器采用OSGi内核所提供的ServiceTracker类实现。

4.根据权利要求2所述的基于CORBA的OSGi分布式扩展系统，其特征在于，所述的服务端代理通过继承CORBA中的org.omg.PortableServer.DynamicImplementation类并实现其voidinvoke(ServerRequest request)方法来实现。

5.根据权利要求2所述的基于CORBA的OSGi分布式扩展系统，其特征在于，所述的客户端代理采用Java的动态接口代理技术实现，由java.lang.reflect.Proxy类在运行期时根据服务接口定义，并采用Java反射功能动态生成。

6.一种基于CORBA的OSGi分布式扩展方法，在安装有权利要求1-5之一所述的基于CORBA的OSGi分布式扩展系统的结点上实现，包括：

步骤1）、允许远程访问的服务通过服务提供者模块在其所在结点的服务注册中心上注册；

步骤2）、为所述允许远程访问的服务生成服务端代理；

步骤3）、远程结点上的消费者模块向该结点上的服务注册中心查询所要访问的服务；

步骤4）、当所要访问的服务在远程结点本地不存在时，所述远程结点生成客户端代理，通过所述客户端代理访问所述服务端代理，从而实现对所述服务的访问。

7.根据权利要求6所述的基于CORBA的OSGi分布式扩展方法，其特征在于，所述的步骤2）包括：

步骤2-1）、服务所在结点上的CORBA分布式支持模块监控到注册事件后，为该服务生成相应的服务端代理；

步骤2-2）、所述CORBA分布式支持模块将所述服务端代理加载到POA上，生成CORBA对象引用；

步骤2-3）、在服务所在结点上的CORBA名字服务模块注册所述服务端代理的CORBA对象引用以及所述服务的本地服务注册信息。

8.根据权利要求6所述的基于CORBA的OSGi分布式扩展方法，其特征在于，所述的步骤4）包括：

步骤4-1）、远程结点上的CORBA分布式支持模块通过该结点上的CORBA名字服务模块查询哪个结点上存在所需要的服务；

步骤4-2）、远程结点上的CORBA分布式支持模块根据查询结果生成所需服务的客户端代理，将对所述客户端代理的所有方法调用转变为对服务所在结点上服务端代理的调用；

步骤4-3）、远程结点上的CORBA分布式支持模块将所需服务的客户端代理注册到本地的服务注册中心。

Images