摘要
本文介绍了OSGi的概念、特点、例子，以及如何使用NetBeans6与Knopflerfish（OSGi的一个RI）来进行OSGi开发一个入门程序——HelloOSGi。在介绍的部分里，转载了一些网络上OSGi的帖子，未能全部提及其出处，请作者见谅！
关于OSGi的介绍
一. 什么是OSGi？
OSGi是Open Service Gateway Initiative的简称，该组织建立于1999年，是一个非赢利机构，旨在建立一个开放的服务规范，为通过网络向设备提供服务建立开放的标准。
OSGI 规范包括了构建开放的可交付网络服务的各方面，OSGI规范又包括了以下子规范：
◆ Framework规范(OSGI核心，提供一个安全的可管理的Java Framework来部署可扩展的Java服务。)
◆ Package Admin Service规范（来管理不同的Bundle之间的引用关系。当Bundle更新或者反安装时判断是否有其他的服务正在使用当前的Bundle）
◆ Start Level规范(定义了启动和停止一个OSGi Service Platform时，不同的Bundles的启动或者停止的先后顺序)
◆ Permission Admin Service规范（Bundle是否许可执行另外的Bundle的代码）
◆ URL Handlers Service规范(怎样注册URL Schema，如何将java.io.InputStream对象转换为特定的Java对象)
◆Log Service规范
◆Configuration Admin Service规范
◆Device Access Specification
◆User Admin Service Specification
◆IO Connector Service Specification
◆Http Service Specification
◆Preference Service Specification
◆Wire Admin Service Specification
◆XML Parser Service Specification
◆Metatype Specification
◆Service Tracker Specification
◆Measurment and State Specification
◆Position Specification
◆Execution Environment Specfication
OSGI Framework
Framework是OSGI Service Platform规范的核心组成部分。它提供了一个通用的、安全可管理的Java framework。通过这个Framework可以支持一种叫做bundles的Service application的部署和扩展。
OSGI兼容设备可以下载并且安装OSGI bundles，也可一当他们不再需要的时候删除。bundles安装后会注册一定数量的Services,并被由同一个Framework下的其他bundles使用。
在一个动态扩展的的 OSGI环境中，Framework管理bundles的安装和更新。同时也管理bundles和Services之间的依赖关系。
Framework提供给bundle开发者必须的资源来在Java平台上开发，为开发的bundles提供了代码动态加载的功能, 也使得开发者开发、部署一个大规模的Services变的很容易。
其次，Framework为Java bundle开发者提供了简明一致的编程模型。简化了开发部署的复杂性。这个编程模型允许开发者将自己的接口规范绑定到OSGI环境中的Service。 The selection of a specific implementation, optimized for a specific need or from a specific vendor, can thus be deferred to run-time.
一个一致的编程模型帮助开发者可以应付一些可估计的危急错误。Framework将会运行在不同的硬件环境上，但一致的接口确保软件组建可以运行在一致的服务接口上。
The Bundle Object
对于每一个安装在OSGI Service Platform的bundle都有一个与之关联的bundle object。一个bundle对象用来管理bundle的生命周期。这项工作通常由Management Agent来做。
Bundle State
bundle有以下状态;
INSTALLED – The bundle has been successfully installed. Native code clauses must have been validated.
RESOLVED – All Java classes that the bundle needs are available. This state indicates that the bundle is either ready to be started or has stopped.
STARTING – The bundle is being started, and the BundleActivato r. start method has been called and has not yet returned.
STOPPING – The bundle is being stopped, and the BundleActivato r. stop method has been called and has not yet returned.
ACTIVE – The bundle has successfully started and is running.
UNINSTALLED – The bundle has been uninstalled. It cannot move into another state.
二. 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典型的应用案例
一. 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来抗衡。
二. BMW汽车的应用控制系统
BMW 汽车的应用控制系统采用OSGI作为其底层架构，估计这一定程度上颠覆了很多人对于Java的认识，很多人都认为基于java的系统低效，不可能用 于汽车这样的应用控制系统上，在EclipseCon 2006会议上BMW采用OSGI得到了证实，估计是猜想会被很多人怀疑，演讲者在PPT上讲了下BMW汽车的应用控制系统，这套系统主要用来控制汽车上 的音箱、灯光等等设备，总共由1000多个Bundle构成，但BMW汽车的应用控制系统启动时间却只需要3.5秒，是不是很令人惊讶呢，这也从很大程度 上反应了采用OSGI的系统的效率并不会低。
这两个非常成功的案例向大家证明了基于OSGI开发系统的可行性，同时这个两个成功案 例的足够的知名性以及优秀的使用、技术效果也为OSGI的推广铺设了不错的基础，到目前为止，关于OSGI被商业领域（例如IBM P5服务器系列、Websphere V6.1、Lotus Sametime、Adobe CS2等）、知名开源软件领域（例如Apache等）采用的消息已经是不断的传出，可以看出OSGI在服务器端应用、企业应用中已经开始广泛流行了，而这 对于OSGI更好的发展成为支撑服务器端应用和企业应用的规范会起到很好的推动作用。
OSGi与类似技术的讨论
一. OSGi与JMX
JMX 本来设计的用途就只为了管理，我们不该把他拿来 (over use) 作为开发应用程序的组件 (那是 EJB 或 JavaBeans 该做的事)。但 OSGi 却可以!
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与SCA
OSGi 和SCA到底能有什么关系呢，确实，至少从现有的OSGi规范以及SCA规范分别来看，两者没有直接的关联，由于OSGi规范是对于嵌入式领域的 软件而制定的，其特别注重软件的动态性的支持，而SCA规范是对于企业应用领域的软件而制定的，并且是基于SOA的，其特别注重对于企业应用而言的基础设 施的实现，同时又尽量的去屏蔽对于SCA容器使用者而言SOA带来的技术实现细节的难度；但根据OSGi规范以及SCA规范，同时又能发现两者有个共同希 望解决的问题，那就是规范的模块化，这是OSGi规范和SCA规范中的一个共同目标。
在规范的模块化上无疑OSGi占据了优势，OSGi规范详细 的定义了作为OSGi框架应该如何去实现以支撑规范的模块化，同时也定义了应该如何规范的来建设模块，而在SCA规范中只定义了如何规范的来建设模块，并 未定义如何规范的来实现SCA容器，既然是这样，SCA规范是否可以考虑直接使用现有的好轮子