OSGI学习

OSGI官方网站

http://www.osgi.org/

OSGI组织成员

Aplix Corporation BenQ BMW Group Computer Associates Deutsche Telekom AG Electricit?de France (EDF) Ericsson Mobile Platforms AB Esmertec Espial Group, Inc. ETRI Electronics and Telecommunications Research Institute Gatespace Telematics AB Harman/Becker Automotive Systems GmbH Hitachi, Ltd. IBM Corporation Industrial Technology Research Institute Insignia Solutions Intel Corporation KDDI R&D Laboratories, Inc. KT Corporation Mitsubishi Electric Corporation Motorola, Inc. NEC Corporation Nokia Corporation NTT Oracle Corporation ProSyst Software GmbH Robert Bosch Gmbh Samsung Electronics Co., Ltd. Siemens AG Sprint Sun Microsystems, Inc. Telcordia Technologies, Inc. Telefonica I+D Vodafone Group Services Limited

OSGI的特点

1。JRE版本无关性。虽然Java一直被人们认为是“Write Once, Run Anywhere”，但对于许多大型项目并非如此，常常因为不同JRE之间的一些小差别而花费巨大，被人们戏称为“Write Once，Debug Anywhere”。OSGi首先希望能消除这种无关性，因此它提供给人们一个比JRE更稳定的承诺。

2。嵌入式设备的开发平台。OSGi创立之初的方向是瞄准了J2ME，可以看到委员会成员多数都不是软件企业。倒是Moto和Nokia这类企业非常热心。

3。高于package的完整的组件形式，还包括自从有组件开发以来一直困扰人们的组件版本问题。（这个可不是jar包啊，jar包只是bundle的一种实现­方式。）

4。推迟发生的依赖关系。当组件A（例如含有菜单的窗体）依赖于组件B（例如菜单所表达的一个功能）时，在语言级上必须先有B再有A，但显示中往往是先有A再有­B，所以OSGi为它们提供一种运行时后绑定的机制。

5。新的软件架构。OSGi几乎每个成员都是其所在领域的TOP，这些领域也都是在未来的数十年中软件大行其到的地方，软件商们（比如IBM）希望这些领域的软­件架构能够统一一些，甚至是组件可以通用。

OSGi: Eclipse的根基

OSGi为网络服务提供了一套标准的, 面向组件的规范. 而网络服务又是SOA(Service Oriented Architecture)的基础. 使用OSGI平台, 就可以很轻松的管理软件组件的生命周期, 这组件是可以位于网络中的任何设备上, 而且组件可以动态的安装, 加载, 升级和卸载, 而不用终止和重启设备. 这里的组件是指程序库或者是应用程序, 它们又可以动态的使用别的库和程序.

其实OSGi原本是为了解决家庭网络或者嵌入式设备由于本身的限制(CPU, 内存, 带宽等)而出的一个解决方案, 是一个轻量级的框架. 但现在OSGi已经远远的超过了它的原来的的功能. OSGi已经应用于移动通讯, 汽车, 电信, 嵌入设备, PC桌面和服务器等众多领域. 由于它的开放和简单的风格, 吸引越来越多的著名公司加入, 使OSGi也愈加强大和开放.

我不了解OSGi在其他领域的应用, 只是由于要使用Eclipse, 所以也只对OSGi在PC桌面方面的应用做了些熟悉和了解. 和OSGi一样, Eclipse也是个开放的平台, 它的基础就是OSGi服务平台(Services Platform), 架构在OSGi上的Eclipse具有融合其他应用和组件的能力, 使不同的组件能够运行在一个JVM(Java Virtual Machine)上, 使它们之间能够协同工作, 占用较少得内存和CPU时间, 而且能够由平台管理组件的全生命周期的活动, 可以说一切都在控制之中.

在OSGi中, 每个具体的组件都要继承于Bundle, Bundle是个接口, 定义了安装, 升级, 卸载, 启动, 停止等操作. 其实, 在Eclipse中, 插件(即上面所说的组件)并不是从Bundle继承的, 而是从另外一个重要接口BundleActivator继承的. 后者只有两个接口函数-Start和Stop. 从它的名称就可以看出, 它其实是一个控制Bundle的类. 在Eclipse中有大量这样的应用, 一个类负责提供接口满足不同的需要, 而有另外一个类负责操作这个类. 比如IWorkbench和WorkbenchAdvisor, IWorkbenchWindow和WorkbenchWindowAdvisor等, 这样可以避免客户直接和核心类打交道, 也减轻了客户的负担。

在Eclipse中, 组件都是以Plugin形式存在的, 几乎每个组件都要有一个类实现(继承)Plugin类(也有例外), 一般都是由Plugin来控制服务的加载和卸载, 因为Plugin继承于BundleActivor. 除了Bundle, BundleActivor外, OSGi也提供了BundleEvent, BundleListner等接口. 这些比较简单.

另外一个重要的接口是BundleContext, 该接口提供了一个Bundle所需要的上下文环境, 一个Bundle对应一个BundleContext, 当Bundle停止(Stop)时, 它也就销毁了. BundleContext提供注册服务工厂(ServiceFactory)的接口, Bundle可以注册一些服务工厂接口, 这样其他的Bundle就可以通过实现这些接口达到扩展的目的. 在Eclipse中对应的概念是”扩展点(IExtensionPoint)”和”扩展(IExtension)”. Bundle之间的交互是非常重要的, 利用这种技术, 就可以将很大的项目分成多个Bundle, 然后搭积木就可以了.

eclipse 3.0并没有用OSGI替换掉原来的PlugIn机制。它只是做了与标准兼容的工作：给用户提供了一系列的API来访问，在这个过程中，就必须要做一些改变(比如plugin registry和loading机制)来同OSGI标准完全兼容。最初的Plugin核心只支持静态的扩展，就是说，如果要改变一个已经存在的Plug就必须重启core,也就是要退出Eclipse并重启。

有很多人问Eclipse为什么要兼容OSGI规范而不是其他的规范呢?

在Eclipse被捐赠出来以前，Eclipse由OTI来开发，其目标是开发一个嵌入式Java软件的开发平台。互联网上现在仍然由很多的连接指向 Visual Age Micro Edition (VAME). 这也是SWT被构思的一个原因，他们想将SWT使用在嵌入式设备中的用户界面。这种渊源关系解释了当时为什么选择OSGI规范。

另外一个原因是除了OSGI没有其他的规范。OSGI规范在轻量级服务架构应用方面被广泛的支持。而且OSGI被好多电信业的知名公司和一些其他行业的知名公司所支持。他们需要使用OSGI来同Sun的J2ME来抗衡。

JSR277和JSR291

http://www.jcp.org/en/jsr/detail?id=291

Establish a JCP specification for a dynamic component framework supporting existing Java SE environments based on the OSGi dynamic component model specifications.

由Apache Software Foundation，BEA Systems, Inc.，IBM，Intel Corporation，Nokia，Nortel Networks，Peter Kriens，Richard Hall，SAS Institute, Inc发起。IBM是JSR291规范的领导者。

http://www.jcp.org/en/jsr/detail?id=277

The specification defines a distribution format and a repository for collections of Java code and related resources. It also defines the discovery, loading, and integrity mechanisms at runtime.

http://www.jcp.org/en/jsr/detail?id=232

Create a predictable management environment for mobile devices capable of installing, executing, profiling, updating, and removing Java^TM and associated native components in the J2ME^TM Connected Device Configuration.

有哪些开源的产品实现了 OSGI，他们的侧重点是什么

目前有不少公司对OSGi service platform推出了自己的实现，象ibm的smf(Service Management Framework,嗯，多好的名字，在那么多的platform实现中，我个人最喜欢这个名字，言简意赅)。

德国的ProSyst公司(http://www.prosyst.com)是OSGi Alliance中非常活跃的推动者，看看他们的产品列表吧http://www.prosyst.com/products/osgi.html(他们甚至提供了kvm + cldc的OSGi framework)

开源的Oscar(http://oscar.objectweb.org/),Knopflerfish(http://www.knopflerfish.org/)

对于OSGi的成功应用，最有名的应该是eclipse了，它就是基于OSGi service platform的产品。还有Apache，据说OSGi将被应用于其新一代的build工具中。这些都是j2se和j2ee的应用，而基于j2me的，手机（对应OSGi Alliance的MEG）和车载设备（对应OSGi Alliance的VEG）是OSGi的主要领域，OSGi Alliance已经有相应的规范，这些领域的应用相信会更加精彩，让我们拭目以待吧。

OSGI 与 JMX 的关系

JMX 与 OSGi 在功能上的许多重迭之处，在国外已经有人讨论过 (例如 Eclipse Embeds OSGi Based MicroKernel 及 JMX vs. OSGi - The New Flavor of the Eclipse Runtime)。不过我认为重点是：

1. JMX 本来设计的用途就只为了管理，我们不该把他拿来 (over use) 作为开发应用程序的组件 (那是 EJB 或 JavaBeans 该做的事)。但 OSGi 却可以!
2. JMX 多数用于 server 系统中，而 OSGi 却不限于所开发的应用程序。你可以用它开发 embedded 系统、desktop 程序，甚至是 server 程序。

OSGi 不但提供了与 JMX 相似的容器管理能力，甚至它本身就是一套精密的 Framework。OSGi 采用Micro-Kernel 的架构，可以提供无限延伸的功能。OSGi 的 Bundles 在线更新功能、以及应用程序之微量内存执行能力，都是开发应用程序的利基。

行文至此，又觉得 OSGi 与 JCA、JNDI 都有一些功能重迭及互补之处。只是 JMX、JCA、EJB、JNDI都经 JCP 标准，都属于 J2EE 家族成员，但 OSGi 过去屈居于 Embedded System，声名就不若前述标准响亮...。我觉得这完全是两种思维模式：J2EE 的思维是 build on large scale，OSGi 的思维是 build on dynamic scale。OSGi 以小搏大。

为什么要用osgi，我认为主要是因为java至今没有出现一个方便易用的组件配置模型。过去，JMX、ClassLoader、reflect都似乎可以做这个事情。但是，JMX太麻烦了，况且原本为J2EE准备的JMX，确实不太易用，走专用的协议，需要专门的客户端，需要adapter来访问等等....

而ClassLoader，单独用ClassLoader，需要自己在其上构建一层包装，否则用起来很麻烦。Reflect的配置方式和ClassLoader一样的问题 。

但是，所有java的组件配置方式，包括使用classloader的osgi在内共有的一个问题就是，被替换组件的回收时间无法控制。

OSGI 在 Server 端发挥作用

osgi是对j2se的增强，可以作为j2ee的基础。jboss之所以在jcp投osgi的反对票，是因为jboss的核心（新项目名为microco­ntainer）实际上与osgi做的是同一件事情，都是要实现组件的动态部署和配置，不同的是他们用的是JMX。Geronimo选用的是JMX+IoC这种­方案作为内核。Oracle的产品也是这种发展方向。所以我认为osgi可以用作j2ee应用服务器的内核，与j2ee标准没有冲突。最好的证明是Equiox­项目将会release一个osgi环境的Web/Servlet Container。

我认为osgi可以在j2ee上提供一个支撑平台的解决方案。很多j2ee容器都是通过自定义classloader来实现装载的，其实我觉得EJB的组建模型不过就是classloader上的噱头。

而osgi则给出了一个完善的classloader体系，不再象过去，使用j2ee的标准只见EJB不见classloader，于是各个场上自己搞自己的。 JMX比较起来还是太麻烦了。

OSGI 在 EOS 中的应用

。。。