一、 引言
随着网络技术和Internet 的快速发展，软件运行从封闭、静态的主机 / 桌面逐步走向开放、多变的分布环境 [1] 。由于 OSGi 技术最初定位于嵌入式领域，进程间通信需要较为丰富的计算资源，因此 OSGi 规范只为单个 Java 虚拟机内的 Java 应用提供了一个高度动态和设计良好的构件运行环境。 OSGi 的动态性、模块化和面向服务的特性使得其在企业计算领域得到了广泛的应用，但企业计算领域所具有的大规模、异构性的特点对标准 OSGi 规范提出了支持分布式处理的需求，即能够支持网络中多个 Java 虚拟机内的 OSGi 应用之间的远程服务发现与远程服务方法调用，并支持 OSGi 应用与网络中非 OSGi 应用的互操作，从而支持企业应用拓扑，提高可用率、可靠性及可伸缩性。因此，提供 OSGi 分布式扩展机制以支持多进程、多 Java 虚拟机、多个节点、多种语言的企业计算是亟需解决的问题。
OSGi分布式处理能力是企业计算领域对 OSGi 提出的核心需求之一。 OSGi 联盟针对企业计算领域对 OSGi 的需求于 2007 年成立了企业专家组，制定相关的规范以提供通用的解决方案，其中支持 OSGi 分布式处理始终是企业专家组会议议程里级别最高的需求之一。 RFC 119[2] 规范是 OSGi 企业专家组制定的针对 OSGi 分布式扩展的规范，提倡使用已有的成熟的分布式技术来实现 OSGi 分布式扩展，如 CORBA 、 WebService 等。
二、相关研究
近年来，学术界在OSGi 分布式扩展技术相关领域展开了很多研究。 Newton[3] 项目是通过改变 OSGi 构件模型的方式来实现 OSGi 分布式处理的典型项目，其目的是建立一个分布式构件模型， OSGi 是 Newton 整个构件模型的中心，而 Jini 则是其远程基础设施的基石， Newton 使用 SCA （ Service Component Architecture ）来描述构件装配模型。 R-OSGi[4] （ Remoting-OSGi ）是 EclipseCon2007 大会上提出的实现 OSGi 分布式处理的项目。 R-OSGi 遵循 OSGi 规范，使用对接口字节码分析的方式来动态产生服务代理 bundle ，以实现远程服务的透明访问，并使用 SLP[5,6] （ Service Location Protocol ）协议实现远程服务发现。 Apache CXF[7] 项目成立了一个名称为 DOSGi （ Distributed OSGi ）的子项目作为 RFC 119 规范的参考实现， DOSGi 使用 Web Service 来实现远程服务调用，使用基于 HTTP 的 SOAP 协议来实现远程服务的方法调用，并通过 WSDL 来发布服务。 ECF[8] 项目和 Rinia[9] 项目也旨在实现 RFC 119 规范。
三、关键问题
OSGi分布式扩展需要能够支持网络中多个 Java 虚拟机内的 OSGi 应用之间的远程服务发现和远程服务方法调用，并支持 OSGi 应用与网络中非 OSGi 应用的互操作，从而满足企业应用拓扑，提高可用率、可靠性及可伸缩性。然而在 OSGi 分布式扩展机制研究中，存在着如下几个突出的问题，具有一般性，值得深入展开研究： （1 ）在编程模型上，对 OSGi 编程模型存在一定的侵入性。 当前，绝大多数OSGi 分布式扩展机制的研究仅仅是为了实现分布式处理能力，在分布式扩展的同时没有考虑利用 OSGi 本身的特性以保持 OSGi 原有的编程模型，这就使得分布式 OSGi 开发人员需要根据 OSGi 分布式扩展机制所采用的分布式技术来学习相应的分布式编程模式才能开发分布式 OSGi 应用，具有较陡的学习曲线，不利于将集中式的 OSGi 应用透明地转化为分布式应用。（ 2 ）在互操作能力上，不支持 OSGi 应用和企业计算领域中 CORBA[21] 遗留系统的互操作。企业计算领域存在大量的 CORBA 遗留系统，提供一种友好易用的方式来支持 OSGi 应用与 CORBA 遗留系统的互操作是企业计算领域对 OSGi 分布式扩展的主要需求之一。（ 3 ）在技术实现上，没有满足 OSGi 的最小执行环境要求，限制了分布式 OSGi 应用的适用领域。轻量级、平台独立性和可移植性是 OSGi 的本质属性，分布式 OSGi 应用也应该保持该特性，以促进 OSGi 技术在各个领域更为广泛的应用，但是，部分 OSGi 分布式扩展研究项目的远程调用实现技术依赖特定的、能力较强的 Java 虚拟机环境，不适用于资源受限的环境，限制了分布式 OSGi 应用的适用领域。
（一）OSGi的分布式扩展模型
针对目前现有OSGi 分布式扩展研究中存在的问题，我们以 OSGi 分布式扩展规范 RFC 119 为基础，以非侵入性、通用性和良好互操作性为目标提出了基于 CORBA 的 OSGi 分布式扩展模型及扩展机制，如图 1 所示，其特点是采用 CORBA 的 DII/DSI （ Dynamic Invocation Interface/Dynamic Server Interface ）技术和 Java 反射技术实现远程服务方法调用，能够透明地将集中式的 OSGi 应用转变为分布式应用，既保持了 OSGi 原有面向服务的编程模型和轻量级特点，又支持 OSGi 应用与 CORBA 应用的互操作。
图 1 基于CORBA的OSGi分布式扩展模型
基于CORBA 的 OSGi 分布式扩展模型的核心是 CORBA远程调用支持模块 CORBA-DSW（ CORBA-Distribution-Software ）和远 程服务发现模块 CORBA-NDS（ CORBA-Naming-Discovery-Service ）。 CORBA-DSW 远程调用支持模块负责监控本地服务中心的服务注册、查询和注销情况，根据监控情况动态生成远程服务 的 服务端代理或客户端代理，服务端代理和客户端代理提供了基于CORBA 的远程服务调用能力。服务端代理的作用是当接收到 来自对象请求代理 ORB （Object Request Broker ） 的CORBA 调用请求后，负责将该请求转化为 Java 调用请求，然后根据 Java 调用请求调用服务，将服务的处理结果由 Java 形式再转变为 CORBA 形式后返回给 ORB 。客户端代理的作用是实现位于其他节点上的远程服务的接口，将该接口中的方法的 Java 调用请求转换成对远程服务的服务端代理的 CORBA 调用请求。客户端代理与服务端代理 的 生成、运行 和 终结是动态 、透明 的，其生存周期与其所关联的服务的生存周期 相关 。远程服务发现模块 CORBA-NDS 用于辅助CORBA 远程调用支持模块为本地 OSGi 框架 提供远程服务 发现能力，用于支持远程服务的注册、查询、改变和注销 。
基于CORBA 的 OSGi 分布式扩展机制 支持分布在网络中的OSGi 应用与 OSGi 应用之间的远程服务发现与调用能力 ， 如图 2 所示， 该机制 以符合OSGi 标准的 b undle集的形式部署并运行在节点 1 和节点 2 的 OSGi 框架之上，在 OSGi 框架 1 上为服务消费者提供服务 A 的客户端代理，在 OSGi 框架 2 上为服务提供者提供服务 A 的服务端代理，服务 A 的客户端代理和服务端代理通过 IIOP 协议来实现远程互操作。
四、小结
OSGi分布式扩展是 OSGi 在企业计算领域面临的重要问题。本文提出了一种基于 CORBA 的 OSGi 分布式扩展模型及扩展机制并将其集成到“核高基”课题“国产中间件参考实现及平台”中。与现有的 R-OSGi 以及 D-OSGi 等相比，其特点在于既保持 OSGi 面向服务的编程模型和轻量级特点，又可以将集中式的 OSGi 应用透明地转变为分布式应用，并支持 OSGi 应用与 CORBA 应用的互操作。下一步我们将进行进一步的完善和改进，进一步扩大 OSGi 分布式扩展中服务发现的通用性。
参考文献
[1] 杨芙清, 梅宏 , 吕建 , 金芝 . 浅论软件技术发展 . 电子学报 ,2002,12(30):1901~1906 .
[2] OSGi Alliance. RFC 119 Specification. http://www.osgi.org/Specifications/HomePage, 2009.
[3] Paremus. The Newton Project. http://newton.codecauldron.org, 2006.
[4] Rellermeyer J.S., Alonso, G., Roscoe, T. R-OSGi: Distributed Applications Through Software Modularization. Proceedings of the ACM/IFIP/USENIX 8th International Middleware Conference, 2007.
[5] Veizades J., Guttman E., Perkins C. RFC 2165: Service Location Protocol. IETF, 1997.
[6] Rellermeyer J.S. jSLP project. http://jslp.sourceforge.net, 2005.
[7] Apache Alliance. Apache CXF Project. http://cxf.apache.org/distributed-osgi.html, 2009.
[8] The Eclipse Foundation. Eclipse Communication Framework Project. http://www.eclipse.org/ecf, 2009.
[9] The Eclipse Foundation. Riena Platform Project. http://www.eclipse.org/riena/, 2009.