使用NetBeans6开发OSGi应用(1)——FirstOSGi[88250原创]

<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"> <meta name="GENERATOR" content="OpenOffice.org 2.3 (Linux)"> <style type="text/css"> <!-- @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } H2 { margin-bottom: 0.08in } H2.cjk { font-family: "AR PL ShanHeiSun Uni" } H3 { margin-bottom: 0.08in } H3.cjk { font-family: "AR PL ShanHeiSun Uni" } --> </style>

转载请保留作者信息：

作者：88250

Blog：http:/blog.csdn.net/DL88250

MSN & Gmail & QQ：[e-mail]

摘要

本文介绍了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规范是否可以考虑直接使用现有的好轮子---OSGi作为SCA容器实现的基础呢，在使用OSGi 的情况下，SCA容器就没必要费劲就考虑怎么样实现自己规范的模块化了，这个就有点象当年的Java Module System规范，除非SCA小组能够有突破性进展的实现规范模块化的方法，那另当别论。
使用OSGi的话自然的就给SCA带去了一个好处，那就 是动态性的支持上，这是OSGi的核心也是最大的优势，Peter在他最新的blog中也提及Module Layer是OSGi规范中最为关键的部分，正是因为Module Layer才使得OSGi其他部分得以搭建。
当然，基于OSGi去实现SCA容器必然会碰到这样那样的技术难题，这可以依靠OSGi框架的实现者们和SCA容器的实现者们来协作的解决，就像Spring and OSGi。
那 么对于OSGi而言呢，基于OSGi去实现SCA容器又会给OSGi带来什么好处呢，其实非常明显，在这样的情况下OSGi就真正的进入了企业应用领域， 真正的成为了以后企业应用领域的核心基础，所以我在之前的blog中说过，SCA非常象是OSGi在企业应用的延伸或扩展形成的规范。
当然，要做 到上面所说的，不仅仅是想就有用的，需要去努力做到，近期准备发封mail先试探着问问OSGi EEG们对于SCA有什么想法，是否可以考虑直接让SCA变成OSGi EEG的规范，同时让SCA规范制定小组纳入OSGi Core作为SCA容器实现的规范的部分。

ps：近期Spring and OSGi的进展非常可喜，现在Spring and OSGi的project已经提升为了正式的project，而且在提升之前也对外正式公布了Spring and OSGi的repository，Spring and OSGi project的网站地址位于：
http://www.springframework.org/osgi

三. OSGi与JSR 277的争论

JSR 277（Java 模块系统）与OSGi（JSR 291）的争论再次变得白热化，JSR 316（Java EE 6）的提交又一次引燃了关于OSGi与JSR 277互相重叠的争论。InfoQ整理总结了其中的若干观点和论据。

Peter Kriens写了一篇博客文章讨论Java EE 6中对Profile的使用，并展示了如何用组件结构来代替模块系统作为Java EE 6的基础。Kriens还质疑了Java EE 6规范中对JSR 277的使用，他说：

JSR 316仅仅在规范的需求部分，以一种相当间接的方式提到了JSR 277。大致上是说JSR 277正在制定中，他们将推迟任何决定，直到JSR 277完成。看上去颇有道理，因为从编号上看277比291更老也更成熟？但实际上，277仍然处在草案复审阶段，而291已经最终发布，因为291的基 础是从1999年发布至今，已经经过4个主要修订版的非常成熟的OSGi规范。那么，应该有别的理由不提JSR 291吧？也许277提供了291缺少的特性？嗯，没有。从JSR 277规范的需求看，谁也没法说它的目标比JSR 291/OSGi更加远大：没有动态、没有类空间一致性、没有卸载、没有包引用等等。277的初步草案仍然处在一种过于简单化的程度。即便是277唯一比291强的Repository，也仍然有许多晦涩不明之处。JSR 277最近开放了邮件列表， 从里面的讨论中可以看出，似乎他们仍然被一些基本的模块性问题所困扰。不过，幸运的是，JSR 277专家组已经承诺让277的模块系统与JSR 291/OSGi互操作。这就消除了选择OSGi的最后一丝风险，更不用提今天就可以在各种VM（从1.2到6，以及嵌入式设备）上运行OSGi的额外好 处，而JSR 277只能运行在2008年下半年才会发布Java 7上。那么，为什么JSR 316要停下来等？我们已经有一个完美的方案，而且JSR 277承诺将会兼容？

Alex Blewitt也质疑了Java EE 6选择JSR 277的决定：

提交的草案声称：

为了更好地支持这个平台在扩展性方面的目标，应该有一个更加宽泛的模块概念。这项工作正由“JSR 277——Java模块系统”展开，它的目标是Java SE 7。我们预期Java EE 7将建立在这项技术的基础上，因此我们将推迟任何可能与将来的版本冲突的技术规范。

也就是说，他们选择了JSR 277而非JSR 291，并且拒绝在JSR 277随Java 7发布之前考虑任何其它选择。

InfoQ也询问了Eric Newcomer是否认为SUN应该接受OSGi：

绝对应该，绝对合理。更重要的问题是关于Java的未来，关于SUN是会拥抱OSGi还是继续对抗，如果他们继续对抗OSGi，对Java又会有什么影响。根据我最近有限的OSGi经验来说，它在许多方面都给Java带来了显著的改进——模块性、版本、增强的类装载。

Sun 投票反对JSR 291，不过JSR 291仍然获得了通过，正式成为JSE的一部分。不过这已经表明了Sun的立场。JSR 277是由Sun提案的，内容是Java模块性，这看起来明显跟OSGi重叠。Sun有过很好的机会拥抱OSGi并以之为基础构造Java 7，不过，虽然没有正式的声明，但看上去他们更倾向于重复OSGi的工作而不是拥抱OSGi。

我期望Sun能尽快理性地对待OSGi。不过，也许Sun继续站在OSGi的对立面反而更好，因为至今OSGi都发展得很好。

Hani Suleiman，JSR 291专家组的成员之一，对这场争论有不同看法。在回答关于JSR 277和OSGi有什么共同基础时，他说：

[……]JSR-277（在某种程度上）是一个共同的基础。它从JDK这一面着手解决问题，这让OSGi和其他类似方案（Maven、Ivy等）的任务变得更加容易。组件包（Bundle）/模块成为JVM层次的一等公民。

除此之外，（OSGi或其它）框架可以按照自己的意思添加任何增值功能。277并没有限制。OSGi支持者们感到不高兴只是因为基础标准用的不是他们的实现，而且还考虑了很多其它方面的东西。

用Hibernate来打比方，请想象这样的情形：JBoss一直攻击JPA规范，说它是重新发明轮子，所有人都应该把Hibernate当作标准。这就是OSGi支持者们正在做的。

其他人，如Neil Bartlett，也就JSR 277专家组的讨论内容提出了他们的担心：

请看看JSR 277的专家组邮件列表，它已经向公众开放（虽然是只读的）。从这些讨论来看，很难认为他们有倾听两位OSGi专家（Glyn Normington和Richard Hall）的意见。在JSR 277草案的规范定义和应用举例中，有很多地方跟OSGi是不可调和的：Sun拒绝学习任何OSGi/JSR 291的经验。

OSGi支持者们并不是因为我们最中意的模块系统没被选中就大发牢骚。这太孩子气了。我们鼓噪是因为原则问题，JSR 277这个模块系统正在迈向失败！如果在JVM里绑死了一个残缺的模块系统，这会给整个Java社区造成巨大的破坏。

Chris Custine从另一个角度看这场争论的起源：

我认为Sun和OSGi的激烈冲突纯粹是关于控制权和许可证的政治斗争。根本和技术无关！Java社区的政治又一次无视了每个理智的人都具备的常识和逻辑。我一向非常期待Java能够再次复兴它在创新和进化上的能力，但正是这些东西让我担心……

Glyn Normington，JSR 277专家组成员和JSR 291的规范带头人，试图谨慎地表达他的观点。除了两者的特性对照，Normington还就争论中涉及的问题写了一篇详细的介绍。他解释说“这两项JSR的目标是非常不同的，虽然背后的概念很接近。JSR 277和294是在Java SE平台之中加入基本支持；而JSR 291是纯Java的，它建立在Java平台之上”。

Normington认为在JSR 277中重用OSGi并不容易，他也讨论并推翻了放弃JSR 277的想法，最后提出了他认为最合适的解决方案：

最佳方案很清楚：JSR 277应该接受JSR 291，为此应该在JSR 294里加强语言和VM上的支持，并且加入JSR 277的Repository架构。这样可以让JSR 277的进程提前数年，还保证了JSR 277和JSR 291之间完美的互操作性。

但要想实现这个最佳方案，需要Sun转一个180度的大弯。也许，只是也许，Sun为了保证Java的成功，终究会做这件事。也许，只是也许，将来Java社区可以回顾今天，并且模仿丘吉尔的话说：“在穷尽了所有选择之后，总是可以指望Sun做正确的事”。

社区里面对于什么是这个困境的最佳解决方案肯定也是争论不休——您的看法呢？

好了，看了以上这些，相信您对OSGi已经有了一定的了解了，那就让我们实践吧！

准备：

1. 下载NB6，安装JavaSE support module

2. 下载KF，KF——Knopflerfish的缩写，一个OSGi的RI（reference implementation）。建议下载代Sources的那个版本，默认安装。

开工：

1. 创建工程

打开NetBeans6 IDE，创建一个普通的Java App——FirstOSGi。把KF下的Sources拷贝过来（记得加入asm3.0的Jar）：

2. 编写manifest.mf

把工程View切换到Files，改写manifest.mf如下：

3. 编写Activator

记得要构建工程 :-)

4. 测试

打开KF控制中心：

daniel@daniel-laptop:~/Work/knopflerfish_osgi_2.0.4/knopflerfish.org/osgi$java-jarframework.jar

打开构建好的FirstOSGi.jar，运行！

总结

至此，我们的第一个基于OSGi的HelloWorld实现了，了解到了OSGi应用程序的生命周期，如何使用NetBeans6与KF进行OSGi应用 程序的实现。下一次，我们将结合一个具体的项目——StoneAgeDict（一个开放式、实时辞典）来进行实践，请大家多多关注哦:-)