WebX基于OSGi改造的可行性报告-OSGi技术介绍
From Tuscany中文社区
目录 |
[编辑] OSGi介绍
[编辑] 问题
软件复杂度以令人吃惊的速率增加。今天，复杂度大部分由以下原因导致：缩短的产品周期，大量增加的功能需求和同一产品大量变种（例如不同的硬件和OS）。这些趋势已经促使软件成本占据任何厂商开发代价的更大比重。
现今，软件开发很大部分由调整已有的功能适应新的环境这样的工作组成。在过去的20年里，大量的标准构造模块可以使用，并且在今天的产品中大量被使用；一个最佳的例子是开源软件的成功。然而，这些库使用并不是没有问题。集成很多不同的库是极具挑战性的，因为很多库已经很复杂，并且需要他们自己的库运行——即使这些功能 在这个产品中从来不使用。
这种趋势要求整个软件产品进行大量的测试过程。增加不同库的不同步更新，软件开发代价高昂的原因变得非常清楚了。
一个主要问题是现在的软件环境关注于写新的软件，而不是集成已存在软件到新的系统里。事实上，集成已存代码已经成为软件工程师工作的很大一部分。因此，标准化软件集成方面的工具是有必要的，从而使重用已有组件变得可靠和廉价。
[编辑] 解决方案
OSGi技术是面向Java的动态模型系统。OSGi服务平台向Java提供服务，这些服务使Java成为软件集成和软件开发的首选环境。Java提供在多个平台支持产品的可移植性。OSGi技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。这些组件能够组装进一个应用和部署中。
OSGi服务平台提供在多种网络设备上无需重启的动态改变构造的功能。为了最小化耦合度和促使这些耦合度可管理，OSGi技术提供一种面向服务的架构，它能使这些组件动态地发现对方。OSGi联盟已经开发了为例如象HTTP服务器、配置、日志、安全、用户管理、XML等很多公共功能标准组件接口。这些组件的兼容性插件实现可以从进行了不同优化和使用代价的不同计算机服务提供商得到。然而，服务接口能够基于专有权基础上开发。
因为OSGi技术为集成提供了预建立和预测试的组件子系统，所以OSGi技术使你从改善产品上市时间和降低开发成本上获益。因为这些组件能够动态发布到设备上，所以OSGi技术也能降低维护成本和拥有独一无二的新的配件市场机会。
[编辑] OSGi框架
OSGi规范的核心组件是OSGi框架。这个框架为应用程序（被叫做组件（bundle））提供了一个标准环境。整个框架可以划分为一些层次：
|
|
还有一个无处不在的安全系统渗透到所有层。
| L0层执行环境是Java环境的规范。Java 2配置和子规范，象J2SE，CDC，CLDC，MIDP等等，都是有效的执行环境。OSGi平台已经标准化了一个执行环境，它是基于基础轮廓和在一个执行环境上确定了最小需求的一个小一些的变种，该执行环境对OSGi组件是有用的。 |
| L1模块层定义类的装载策略。OSGi框架是一个强大的具有严格定义的类装载模型。它基于Java之上，但是增加了模块化。在 Java中，正常情况下有一个包含所有类和资源的类路径。OSGi模块层为一个模块增加了私有类同时有可控模块间链接。模块曾同安全架构完全集成，可以选择部署到部署封闭系统，防御系统，或者由厂商决定的完全由用户管理的系统。 |
| L2生命周期层增加了能够被动态安装、开启、关闭、更新和卸载的bundles。这些bundles依赖于于具有类装载功能的模块层，但是增加了在运行时管理这些模块的API。生命周期层引入了正常情况下不属于一个应用程序的动态性。扩展依赖机制用于确保环境的操作正确。 生命周期操作在安全架构保护之下，使其不受到病毒的攻击。 |
| L3层增加了服务注册。服务注册提供了一个面向bundles的考虑到动态性的协作模型。bundles能通过传统的类共享进行协作，但是类共享同动态安装和卸载代码不兼容。服务注册提供了一个在bundles间分享对象的完整模型。定义了大量的事件来处理服务的注册和删除。这些服务仅仅是能代表任何事物的Java对象。很多服务类似服务器对象，例如HTTP服务器，而另一些服务表示的是一个真实世界的对象，例如附近的一个蓝牙手机。这个服务模块提供了完整安全保障。该服务安全模块使用了一个很聪明的方式来保障bundles之间通信安全。 |
[编辑] OSGi的特点
- JRE版本无关性。虽然Java一直被人们认为是“Write Once，Run Anywhere”，但对于许多大型项目并非如此，常常因为不同JRE之间的一些小差别而花费巨大，被人们戏称为“Write Once，Debug Anywhere”。OSGi首先希望能消除这种无关性，因此它提供给人们一个比JRE更稳定的承诺。
- 嵌入式设备的开发平台。OSGi创立之初的方向是瞄准了J2ME，可以看到委员会成员多数都不是软件企业。倒是Moto和Nokia这类企业非常热心。
- 高于package的完整的组件形式，还包括自从有组件开发以来一直困扰人们的组件版本问题。（这个可不是jar包啊，jar包只是bundle的一种实现-方式。）
- 推迟发生的依赖关系。当组件A（例如含有菜单的窗体）依赖于组件B（例如菜单所表达的一个功能）时，在语言级上必须先有B再有A，但显示中往往是先有A再有-B，所以OSGi为它们提供一种运行时后绑定的机制。
- 新的软件架构。OSGi几乎每个成员都是其所在领域的TOP，这些领域也都是在未来的数十年中软件大行其到的地方，软件商们（比如IBM）希望这些领域的软-件架构能够统一一些，甚至是组件可以通用。
[编辑] 几个开源OSGi实现的介绍
[编辑] Apache Felix
Felix是一个社区成果来实现OSGi R4服务平台，它包含OSGi框架和标准服务，同样提供和支持其它有兴趣的OSGi相关的技术。最终的目标是提供一个完全兼容的OSGi框架和标准服务的实现，并支持围绕这个技术的一个社区。Felix当前实现了OSGi版本4规范的大部分，但是为了完全兼容附加的工作是必须的。尽管这样，Felix提供的OSGi框架功能是非常稳定的。项目网址为：http://felix.apache.org
[编辑] Eclipse Equinox
Equinox项目是Eclipse开源组织提供的OSGi框架的实现。Eclipse自3.0版本开始，其内核移植到OSGi框架上。通过OSGi框架强大的组件控制，交互和管理能力，再加上Eclipse插件的自有特点，Eclipse开源框架得到了跳跃式的发展。同时，OSGi规范得益于Eclipse IDE环境庞大的使用者，OSGi联盟也进入了快速发展时期。
Equinox实现了OSGi在J2ME、J2SE方面的应用的同时，也推动了OSGi在J2EE方面的应用。Equinox提供了一组基础的Bundle，使得使用JSP、Servlet和Struts等J2EE技术的Web应用项目可以运行于Equinox OSGi环境中。同样的，Equinox通过一组Bundle，可以将Equinox OSGi应用嵌入到现有的Web服务器（如Tomcat，Jetty等）和应用服务器（如Websphere，Weblogic等）中。
Equinox部署更新框架（Provisioning）。Eclipse提供为插件的分组，更新及远程维护提供了一套完善的机制。用户可以通过远程更新站点安装或升级所需功能的插件。为了适应OSGi环境的特点，Equinox项目组为基于OSGi的系统的部署更新提供了一套全新的框架，称为“equinox p2”。目前该框架还在第一个发布版本的最后阶段，该功能预计将在Eclipse 3.4版本中集成发布。
Equinox的最新研究方向：
- 资源管理（Resource Monitoring）：该方向致力于为基于OSGi的系统提供一个轻量级的资源监控管理基础框架，该框架基于JMX技术。目前该研究方向已经提供了一套可供展示的基本实现。
- 安全管理：该方向致力于将Java安全机制（JCA/JAAS框架）集成到Eclipse中。为Eclipse/Equinox环境提供诸如消息摘要，数字签名，密钥存储，证书存储等基础安全机制。此外，该方向还为Eclipse提供JAVA包签名，Bundle加载时的签名校验，代码权限等机制的实现。
- 面向方面的开发：该方向致力于解决在OSGi环境中面向方面编程的一些技术问题，如加载编排和模块化等。
因为Equinox的稳定性、大的社区支持和对JEE的很好的支持，我们后面的demo就是使用的Equinox。
[编辑] Knopflerfish
Makewave是Knopflerfish的创立者和管理者，一个开源的OSGi实现。Knopflerfish项目的目标是开发和发布关于OSGi技术的易于使用的开源代码、构件工具和应用。Gatespace Telematics是OSGi联盟的成员，拥有很多开发者来开发和维护Knopflerfish发行版。Knopflerfish专业版承诺给予那些把开源Knopferfish产品内嵌到商业产品和系统的公司以全力支持。Knopflerfish专业版2.0被OSGi联盟认证为支持OSGi R4。网址为：http://www.knopflerfish.org
[编辑] OSGi的典型应用介绍
OSGi为网络服务提供了一套标准的、面向组件的规范。而网络服务又是SOA(Service Oriented Architecture)的基础使用OSGI平台，就可以很轻松的管理软件组件的生命周期，这个组件是可以位于网络中的任何设备上，而且组件可以动态的安装、加载、升级和卸载，而不用终止和重启设备。这里的组件是指程序库或者是应用程序，它们又可以动态的使用别的库和程序。
其实OSGi原本是为了解决家庭网络或者嵌入式设备由于本身的限制(CPU、内存、带宽等)而出的一个解决方案，是一个轻量级的框架。但现在OSGi已经远远的超过了它的原来的的功能。OSGi已经应用于移动通讯，汽车，电信，嵌入设备，PC桌面和服务器等众多领域。由于它的开放和简单的风格，吸引越来越多的著名公司加入，使OSGi也愈加强大和开放。
[编辑] OSGi：Eclipse的根基
和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更好的发展成为支撑服务器端应用和企业应用的规范会起到很好的推动作用。
