基于OSGi的异构服务集成系统及方法

摘要

本发明提供一种基于OSGi的异构服务集成系统，包括Java虚拟机、OSGi容器，还包括服务管理模块、处理器管理模块、监视模块、服务发现模块以及处理器模块；其中，服务管理模块负责监听远程服务注册和使用请求，对不同类型的服务进行管理，针对不同的服务配置类型，通知处理器管理模块进行发布和调用；处理器管理模块用于对处理器模块进行管理，并向远程端点发布和调用服务，还根据服务管理模块所传递的信息调用处理器模块，维护当前发布的服务以及使用的远程服务的信息；监视模块负责监视本地注册中心，并从服务管理模块得到要监控的信息；服务发现模块用于实现远程的服务发现；处理器模块用于实现OSGi容器内的模块向OSGi容器外的服务的访问。

说明书

技术领域

本发明涉及网络传输领域，特别涉及一种基于OSGi的异构服务集成系统及方法。

背景技术

计算机作为人类历史上最伟大的发明之一，代替人工处理了大量的重复性的工作，特别是在企业应用当中，扮演着决策、生产、销售、售后服务等过程中的诸多角色，降低了成本，大大提高了生产效率。为此，各个企业机构进行了大量的投资，针对各自的关注领域开发了各种类型的信息系统，以帮助企业进行内部或外部业务的处理和管理。正是由于关注领域的不同，导致各类系统之间没有统一的接口标准和规范，即使是在同一个企业内部，各职能部门之间也会各自为政，众多关键的信息被封闭在相互独立的系统中，形成一个个所谓的“信息孤岛”。使得企业的工作效率降低，运营成本提高。

随着企业规模的扩大，以及市场规则作用下企业的兼并破产行为，原有的信息系统也不可避免地会发生变化，如何适应这种变化，如何将众多的“信息孤岛”联系起来，以便让不同的系统之间交互信息，成为亟待解决的问题。用于解决这一问题的异构服务集成技术开始广受关注。

传统的异构服务集成技术往往使用具体的组件化和分布式技术，如CORBA(Common Object Request Broker Architecture，公用对象请求代理体系结构)、COM/DCOM、RMI等，这样做虽然在一定程度上解决了集成问题，但一方面会使得系统结构变复杂，对原有系统侵入性较大，另一方面，不同的技术体系之间相对独立，虽然有这样那样的桥接技术，但这些技术自身仅是针对某些特定的技术体系，这样依然产生了更高层面上的针对不同技术体系的应用集成问题。

鉴于传统异构服务集成技术所具有的上述缺陷，本领域技术人员提出了SOA(Service Oriented Architecture，面向服务的体系结构)，这类系统将异构平台上应用程序的不同功能部件(也被称为服务)之间定义良好的接口和规范按松耦合方式整合在一起。基于SOA的相关思想，本领域技术人员又为Java进一步提出了动态、模块化的体系模型OSGi(OpenServices Gateway initiative，开放服务网关协议)。

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

近年来，随着越来越多的大型应用采用OSGi技术，特别是Eclipse3.0版本采用OSGi来重构其体系结构以后，OSGi在企业计算领域也得到了越来越广泛的应用，如IBM的WebSphere和Oracle/BEA的WebLogic等都使用了OSGi技术。虽然在OSGi中也定义了跨虚拟机的实现方式，但在具体实现上同样采用某种具体的互操作机制，破坏了基于不同的远程访问方式的OSGi容器之间进行互操作的可能。

发明内容

本发明的目的是克服基于现有技术的异构服务集成系统采用某一种具体的互操作机制所带来的局限性，从而提供一种适用范围广的异构服务集成系统。

为了实现上述目的，本发明提供了一种基于OSGi的异构服务集成系统，包括Java虚拟机、OSGi容器，还包括在所述OSGi容器上运行的服务管理模块、处理器管理模块、监视模块、服务发现模块以及处理器模块；其中，

所述的服务管理模块负责监听远程服务注册和使用请求，对不同类型的服务进行管理，针对不同的服务配置类型，通知所述的处理器管理模块进行发布和调用；所述的处理器管理模块用于对所述的处理器模块进行管理，并向远程端点发布和调用服务，还根据所述服务管理模块所传递的信息调用相应的处理器模块，维护当前发布的服务以及使用的远程服务的信息；所述的监视模块负责监视所述OSGi容器中的本地注册中心，并从所述服务管理模块得到要监控的信息；所述的服务发现模块用于实现远程的服务发现；所述的处理器模块用于实现所述OSGi容器内的模块向OSGi容器外的服务的访问。

上述技术方案中，所述的处理器模块包括web服务处理器模块、CORBA处理器模块以及SCA处理器模块。

上述技术方案中，所述的web服务处理器模块采用Axis作为底层互操作组件。

上述技术方案中，所述的CORBA处理器模块采用JacORB作为底层互操作组件。

上述技术方案中，SCA处理器模块采用Apache Tuscany作为底层互操作组件。

上述技术方案中，所述服务发现模块包含用于发现某一种远程服务的服务发现方式；所述服务发现方式的种类与系统所能集成的异构服务的种类有关。

上述技术方案中，所述服务发现方式的种类包括：UDDI、CORBA的名字服务机制、SLP的服务发现机制以及本地配置文件。

上述技术方案中，所述的处理器管理模块将所述处理器模块底层的远程互操作功能抽象出来，用统一的接口实现所述的向远程端点发布和调用服务。

上述技术方案中，所述的要监控的信息包括：使用的远程服务、对外暴露的服务、包的依赖关系以及本地的线程数和堆栈使用情况。

本发明还提供了一种用于所述的基于OSGi的异构服务集成系统的方法，包括：

步骤1)、允许远程访问的服务在其所在节点的本地注册中心上注册；

步骤2)、根据配置的类型将所述允许远程访问的服务发布到远程；

步骤3)、远程节点上的服务使用者向该节点上的服务注册中心查询所要访问的服务；

步骤4)、当所要访问的服务在远程节点本地不存在时，所述远程节点通过服务发现模块进行远程服务发现，并根据配置的类型启动相应的处理器模块，完成服务调用。

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

步骤2-1)、服务所在节点上的服务管理模块监控到注册事件后，获取该服务的描述信息，通知服务发现模块创建服务描述实例；

步骤2-2)、所述的服务发现模块将服务注册到远程服务注册中心；

步骤2-3)、所述的处理器管理模块根据配置的类型创建相应的处理器模块；

步骤2-4)、处理器模块根据服务描述实例发布该服务。

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

步骤4-1)、远程节点上的服务管理模块通过该节点上的服务发现模块查询哪个节点上存在所需要的服务；

步骤4-2)、远程节点上的服务发现模块根据查询结果生成服务描述实例；

步骤4-3)、远程节点上的处理器管理模块根据配置的类型创建对应的处理器模块；

步骤4-4)、处理器模块使用服务描述实例完成服务调用。

本发明的优点在于：

本发明具有广泛的适用性和灵活性。

附图说明

图1为本发明的基于OSGi的异构服务集成系统整体结构图；

图2为本发明的基于OSGi的异构服务集成系统典型应用场景图；

图3为本发明的基于OSGi的异构服务集成方法服务发布过程示意图；

图4为本发明的基于OSGi的异构服务集成方法服务查找和调用过程示意图。

具体实施方式

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

在图1中给出了本发明的基于OSGi的异构服务集成系统的整体结构，从图中可以看出，该系统包括有JVM(Java Virtual Machine，Java虚拟机)、OSGi容器、服务管理模块、处理器管理模块、监视模块、服务发现模块以及处理器模块。下面对上述各个模块的功能分别予以说明。

所述的JVM为编程语言Java的运行环境，所述的OSGi容器在本质上是一个为Java提供的动态、模块化的系统，能够对运行于其中的模块(即Bundle)进行管理。上述JVM和OSGi容器的实现都为本领域的公知常识，因此不在此做详细说明。所述的服务管理模块、处理器管理模块、监视模块、服务发现模块以及处理器模块都在OSGi容器的基础上予以运行。

所述的服务管理模块负责监听远程服务注册和使用请求，在本系统加载时，该模块需要向OSGi容器中的本地注册中心注册监听服务，所注册的监听服务针对远程服务注册和使用请求有不同的实现方式，下面分别加以说明。

对于远程服务的注册而言，在执行这一注册过程时，OSGi内核会产生一个服务注册的事件，而服务管理模块使用OSGi内核所提供的ServiceListener类接收到OSGi内核发出的服务注册事件，并通过OSGi内核提供的上下文获取到注册服务的属性信息。该属性信息以字符串的形式表示，并在服务注册的时候被写入到本地注册中心。例如，属性信息中包含“Remote”字段，表示具有该属性的服务希望发布给远程使用；属性信息中包含“Type”字段，则指明了具有该属性的服务的发布类型信息，如“CORBA”、“Web”、“SCA”等都表明了服务发布时采用的方式，如采用“#”则表明要使用所支持的所有类型进行发布；如属性信息中包含“Method”字段表明需要发布的服务对象内的方法名，默认为“*”，即全部方法。在完成上述的远程服务注册后，服务管理模块就会通知处理器管理模块进行服务发布。

对于服务使用请求，服务管理模块使用OSGi内核提供的ListenerHOOK类。该类包含三个回调函数分别用于处理以下三种情况：(1)当所需的服务到来时该怎么处理；(2)当所需的服务被注销时该怎么处理；(3)当所需的服务发生改变(如服务属性的改变)时怎么处理。同时，ListenerHOOK类还包含一个ListenerInfo类型的私有类，当有服务使用请求时，ListenerInfo类型会实例化为具体的请求信息(包括服务接口名，调用的函数名，使用的通信方式等)，服务管理模块得到这些请求信息，通过一个字符串来描述所要使用的服务，通知服务发现模块进行服务发现。

另外，在服务管理模块内包含一个链表的数据结构，记录了当前已经发布的和正在调用的远程服务的信息，进而可以对不同类型的服务进行管理。服务管理模块以及下文中所提到的模块都可由OSGi中的Bundle模块实现。

处理器管理模块用于对不同的处理器模块进行管理，包括不同处理器模块的创建、初始化、注销等。该模块内定义了一个名为Handler的接口类，该接口中定义了一个Endpointdescription类型(端点描述实例，包含了诸如服务ID、框架UUID、接口名、服务发布方式等服务描述信息)的私有属性以及Export()和Import()两个抽象的方法，由本模块派生出来的处理器模块都需要实现上述接口类及其属性和方法，这样就将处理器模块的底层的远程互操作功能抽象出来，使得处理器模块能够用统一的接口向远程端点发布服务，及从远程端点调用服务。在本实施例中，处理器管理模块可采用软件工程中的工厂模式实现，这一模式的应用有利于提高处理器管理模块的扩展性。

处理器管理模块与服务管理模块之间通过OSGi规范提供的RSAListener类所提供的方法进行通信，使得处理器管理模块可以得到从服务管理模块传递来的配置类型和服务描述信息，从而调用对应的处理器模块进行处理。处理器管理模块还能维护当前发布的服务和使用的远程服务，以及服务的创建、删除、调用的失败等信息，并通知给服务管理模块，这样服务管理模块就可以了解当前状态，并对前述的链表进行维护。

监视模块负责使用前述的监听服务监视OSGi容器内的本地注册中心，同时还会使用OSGi规范提供的EndpointListener类(该类包含一个服务引用类型的属性和EndpointAdded()、EndpointRemoved()、Export()、Import()、getEndpoint()等方法，分别对服务发布和服务调用过程中端点描述实例的增减等进行控制)，所述由服务管理模块处得到远程服务的相关信息。这些信息主要包括：使用的远程服务、对外暴露的服务、包的依赖关系等；另外还会基于JAVA语言提供的Thread.currentThread()、getThreadGroup()方法得到本地的线程数，使用java.lang.Runtime.totalMemory()和java.lang.Runtime.freeMemory()等方法并使用自定义的算法获得本地堆栈使用情况。上述的信息和运行情况都会以可视化的形式展现；此外，该模块还要根据监控信息对系统的运行状态做出评估，进而能够基于JAVA语言提供的java.lang.Runtime.gc()函数以及OSGi内核提供的针对Bundle生命周期进行管理的一系列控制台命令等相关机制主动地改变系统运行行为，使得在尽可能少的人为干预下，系统能够长时间运行在良好状态。

服务发现模块负责远程的服务发现。跟处理器管理模块类似，该模块包括有一个Discovery的接口类，该类包含一个ServiceReference类型(服务引用，可以理解成一个具体的服务对象的对象名)的私有属性，用来记录由服务管理模块传递来的服务描述信息，还包含Export()、Search()以及GenerateEndpoint()三个抽象方法，分别对应于服务发布、服务查询过程以及产生EndpointDescription实例的方法。在本实施例中，在该模块内创建了UDDI、CORBA的名字服务机制、SLP的服务发现机制以及本地配置文件等多种服务发现方式。每种方式都实现了上述的Discovery接口，同时，系统运行前可以配置需要加载的服务发现类型。服务发现模块使用EndpointListener类跟服务管理模块进行交互。服务发现模块对于服务发布过程与服务调用过程有不同的处理，下面分别予以说明。

对于服务发布过程，当所述的服务管理模块监听到服务发布事件后，服务发现模块就会接收到服务管理模块传递来ServiceReference类型的参数，然后调用GenerateEndpoint()方法产生EndpointDescription实例，并传递给服务管理模块。根据前述的配置的加载的服务发现类型，写入本地文件或者向远程的服务注册中心注册。

对于服务调用过程，当所述的服务管理模块监听到远程服务调用请求后，如果请求的服务属性中包含“configfile”字段，服务发现模块从本地的默认位置读取配置文件的信息，配置文件通常是一个*.xml文件，里面用标准的xml语法描述了远程服务的信息，包括地址、暴露的类名、方法名等等，如果不含上述“configfile”字段，则启动配置的服务发现方式到远程注册中心查找，最后调用GenerateEndpoint()方法产生EndpointDescription实例，并传递给服务管理模块。

处理器模块基于现有的远程互操作实现机制(如CORBA、WebService等等)完成OSGi容器内的模块对OSGi容器外的服务的访问过程。处理器模块根据服务的类型有多种类型，在本实施例中包括有web服务处理器模块、CORBA处理器模块以及SCA处理器模决。处理器模块的类型也可根据需要灵活地增加或减少。

所有类型的处理器模块都由处理器管理模块产生，由于每种处理器都实现了前面所述的Handler接口类，因此，都会拥有一些共同的属性和方法。使用这些共同的方法可以分别对不同配置类型的服务发布和服务调用进行处理。每种处理器模块中都建立了相应的运行时组件，如：CORBA处理器模块使用JacORB(一个开放源码的CORBA产品，设计支持Java语言映射，满足CORBA2.3标准并提供广泛的平台支持)作为CORBA配置类型服务的底层互操作组件。类似的，Web服务处理器模块和SCA处理器模块分别使用Axis(全称Apache eXtensible Interaction System，是apache组织下的一个开源项目，用来做webservice开发的)和ApacheTuscany(一个开源项目，提供一个SOA基础设施和SCA运行时环境，Tuscany项目本身并不提供SOA开发和管理IDE插件)作为相应的配置类型服务的底层互操作组件。

在某种具体的处理器创建阶段，前述的EndpointDescription类型的私有属性会使用服务管理模块从服务发现模块得来的EndpointDescription实例初始化，同时，该处理器所采用的运行时组件，会针对其特有的编程模型进行一些初始化工作，如类库的加载、通信协议的建立。在CORBA中，对应于初始化ORB、初始化POA等，对于WebService，对应于初始化Axis引擎等，对于SCA，对应于初始化Tuscany，实例化SCADomain等；在运行阶段，某种具体的处理器的export()和import()方法会被调用，进行服务的发布和调用；在注销阶段，各处理器的析构函数会被调用，完成资源释放等工作。需要说明的是上述初始化过程、运行期以及注销时的操作，针对某种具体的处理器都需要遵循各自的编程模型，而这些编程模型都是公知的，因此没有赘述。

以上是对本发明的基于OSGi的异构服务集成系统中各个功能模块的说明。下面结合这些模块，对本发明如何进行远程服务的注册，远程服务的查找和使用分别予以说明。

为了便于理解，如图2，给出了一个使用本发明的典型应用场景，该场景中共有A、B、C、D、E五个节点，节点A提供CORBA服务，节点B提供SCA服务，节点C提供Web服务，节点D提供运行于OSGi容器的OSGi服务，而节点E则是服务的使用者，该使用者运行于OSGi容器内。

结合图3对远程服务的注册过程加以说明。节点D内的OSGi本地服务需要发布给远程的节点A、B、C、E。在将本地服务发布到远程节点之前，首先需要做基本的注册操作。这一注册操作包括由节点D上的监视模块向位于本节点的OSGi容器内的本地注册中心注册监听服务，并由该监视模块监视OSGi容器的运行情况；然后，由服务管理模块向本地注册中心注册监听服务(服务管理模块所注册的监听服务与监视模块所注册的监听服务的内容不同)，监视服务注册事件。上述注册操作不仅仅是远程服务的注册过程所要完成的，在远程服务的查找与使用之前，同样要完成类似的注册操作。

在完成上述注册操作后，服务提供者(即节点D内的OSGi本地服务)向所述的本地注册中心注册，由于该服务要向远程节点A、B、C、E发布，因此该服务具有远程属性。接着，服务管理模块从本地注册中心获取所要发布服务的远程属性，将所得到的所述远程属性发送到服务发现模块，由服务发现模块根据服务的远程属性信息创建端点描述实例，所述端点描述实例中包括服务的属性，服务ID，框架ID等服务描述信息。所述服务发现模块根据端点描述实例中的信息将所要发布的服务注册到诸如CORBA的名字服务器或者UDDI的远程注册中心等。最后，所述处理器管理模块还要根据所述远程属性以及服务提供者向本地注册中心注册服务时所标识的配置类型信息(如CORBA、Web、SCA中的一种或几种的组合)，创建对应的处理器模块，由所述的处理器模块根据服务描述实例发布服务。

以上是对远程服务注册过程的说明，下面结合图4对远程服务的查找和使用过程加以说明。

在完成基本的注册操作后，节点E本地的OSGi Bundle(即服务使用者)调用远程服务时，首先在节点E上的本地注册中心查找，该本地注册中心发现需要的服务带有远程属性，会通知服务管理模块，启动节点E上的服务发现模块。该服务发现模块使用对应的服务发现方式到远程中心查找，根据查找的结果生成服务描述实例。在得到服务描述实例后，服务管理模块通知处理器管理模块根据服务描述实例中的服务描述信息和配置类型信息(如CORBA、Web、SCA中的一种或几种的组合)派生出对应的处理器模块，为远程的服务创建本地代理并将该代理注册为本地服务，这样服务消费者就可以像使用本地服务一样调用远程服务。

以上是对本发明的异构服务集成系统以及相关集成过程的说明。由于本发明将不同类型的处理器模块的共有的底层的远程互操作功能抽象出来形成独立的处理器管理模块，使得不同的处理器模块都能用统一的接口向远程端点发布服务，及从远程端点调用服务，从而克服了现有的异构服务系统由于基于特定互操作机制所带来的适用范围较窄的缺陷，具有广泛的适用性和灵活性。

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