[整理] OSGI与Eclipse3

本文摘自: http://blog.oicp.net/?play=reply&id=79
        OSGi，我真正关注到这个词汇是在上周的Bea User Group交流会上，一个台湾人做了相关演讲，实际上OSGi只是一个商业规范，没想到被Eclipse应用。
        Eclipse3.0平台与Eclipse2.1平台的一个重要的区别就是,Eclipse3.0平台建立在一个Java框架上,即OSGi服务平台.OSGi的采用,使Eclipse走上了完全动态平台的发展道路.从Eclipse 3.0 M5开始，runtime采用OSGI标准，但仍然兼容现有的Extension机制。
        OSGi 即 Open Services Gateway Initiative，起源於1999 年三月，是由一些家用閘道器相關產業廠商所組合而成的組織，目前約有八十餘家廠商加入。包括了 IBM、Sun、BMW、Motorola、Nortel、Nokia、 Philips、Panasonic、Sony、Toshiba、Echelon 等。目前最新的標準是OSGi Specification 3.0。
        當初制定OSGi 標準的最主要的目的，是要為遠端的服務提供者 (Service Provider) 與本地端的設備 (Device) 之間提供完整的點對點服務傳送解決方案。因此，OSGi 定義了一個開放性的平台，使得遠端軟體服務供應商所提供的應用程式 及加值服務，能視使用者需求，隨時下載至靠近用戶的閘道器 (Gateway) 上，並且自動安裝執行，而這裡所指的閘道器通常是連接家庭網路(Home Network)、辦公室網路 (Office Network) 與廣域網路間的一個裝置，如機上盒 (Set-top Box;STB)、ADSL數據機、纜線數據機 (Cable Modem)、住宅區閘道器 (Residential Gateway)等。透過這個開放性的平台，不同廠商所開發出的服務軟體及設備都能互相溝通及搭配使用。
        在 OSGi 網站上的 FAQ 中，指出 OSGi 應用方向包括：
Services in the Home:
Communication
Information/entertainment
Safety and security monitoring
Energy management and metering
Appliance diagnostics and servicing
Telemedicine and healthcare monitoring
Services in the Car:
Navigation
Emergency assistance
Mobile commerce
Information/entertainment
Vehicle diagnostics
Location-based services
Again, we see java succeeded in J2ME. We can see many big-name companies in the OSGi member name list which include many companies come from many industries.
        最近 OSGi 在軟體業最為人雀躍的發展，莫過於 Eclpise Java IDE 支援 OSGi 標準。這是一個有趣的現象，本來是設計給其他產業的運用，卻在軟體業也有不凡的表現。這也讓我想起 Java 的發展歷史，本來也是為了 embedded 系統而設計，卻意外的在 internet 竄起的年代獲得各方的矚目，更在 enterprise application 中立於不敗之地...
        OSGi 採用Micro-Kernel (根据那个台湾人的说法，是从Linux操作系统的微核心衍生过来的)的架構，可以提供無限延伸的功能。OSGi 的 Bundles 線上更新功能、以及應用程式之微量記憶體執行能力，都是開發應用程式的利基。
        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来抗衡。
        Eclipse3.0平台是建立在OSGi(Open Services Gateway Initiative)服务平台基础之上的,所以有必要先介绍一下OSGi框架. 
        OSGi框架
        OSGi框架是一个通用,安全,可管理的Java框架,它支持被称为"bundle"的可扩展和可下载的服务应用的部署.与OSGi兼容的设备可以下载和安装基于OSGi标准的bundle,并且还可以删除不再需要的bundle.另外,已安装的bundle可以注册一组服务(service),这些服务可以在OSGi框架的严格控制下被其他bundle共享.
        OSGi框架以一种动态和可升级的方式管理哪些处于OSGi环境中的bundle的安装和更新,还管理bundle和服务(service)的依赖关系.
        Bundle
        在OSGi服务平台中,bundle是部署的Java应用的唯一实体.一个bundle由Java类和其它资源组成,它们提供功能给终端用户,提供服务组件(serveices)给其它的bundle.
        Bundle是作为JAR文件被部署的.可以说,一个bundle就是一个JAR文件,它包括:
        1> 容纳了实现零个或多个服务的资源.这些资源可以是Java类文件,也可以是其它数据文件如HTML文件,图标文件等.
        2> 容纳了一个manifest文件.该文件描述了JAR文件的内容和与bundle相关的配置信息.
        3> 陈述了对其他资源如Java中的包(package)的依赖关系.
        4> 指明bundle中的一个Java类作为Bundle Activator接口的实现类.OSGi框架必须实例化该类并调用start和stop方法来启动和停止bundle.
         MANIFEST.MF文件
         每一个bundle都有一个描述其自身信息的MANIFEST.MF文件,该文件位于JAR文件中的META-INF目录下.
         我们知道,在生成普通的Java JAR文件时都会要求指定一个MANIFEST.MF文件与该JAR文件关联在一起.MANIFEST.MF文件的内容格式可能如下:
         Manifest-Version: 1.0 
         Ant-Version: Apache Ant 1.5.3 
         Created-By: 1.4.2_04-b05 (Sun Microsystems Inc.) 
         在OSGi框架中,每一个bundle的MANIFEST.MF文件除了可以包括上述内容外,还定义了自己的OSGi          MANIFEST内容格式,例如: 
         Manifest-Version: 1.0 
         Ant-Version: Apache Ant 1.5.3 
         Created-By: 1.4.2_04-b05 (Sun Microsystems Inc.) 
         Bundle-Activator: test.osgi.exam2.Activator 
         Export-Package: test.osgi.exam2.service 
         Bundle-Name: English dictionary 
         Bundle-Description: A bundle that registers an English dictionary service 
         Bundle-Version: 1.0.0 
         上例中显示的是一组MANIFEST头(header)/值(value)对,如Bundle-Activator头(header)的值为test.osgi.exam2.Activator. 
         在OSGi框架定义了一组标准的MANIFEST头(header),每一个header都有其特定的含义.上例中定义的Bundle-Activator头信息的值test.osgi.exam2.Activator表示用来启动和停止"English dictionary" Bundle的类名. Export-Package头信息的值test.osgi.exam2.service表示可以被导出的包名,即test.osgi.exam2.service包可以被其它Bundle导入并使用其中提供的服务(service). 
         Bundle的受控状态 
         一个Bundle可能处在下面的状态之中: 
         ■ 已安装(installed) 
         在OSGi框架安装Bundle时,将解析该Bundle的本地代码的依赖关系.如果失败,该Bundle将不会被安装.一旦Bundle被安装,OSGi框架将可对该Bundle的整个生命周期(如起动,停止,更新,卸载)进行控制. 
         ■ 已解析(resolved) 
         当OSGi框架成功地解析Bundle的本地代码的依赖关系时,该Bundle就进入解析状态.这些依赖关系包括: 
         1> Bundle的MANIFEST.MF文件中,MANIFEST头Bundle-Classpath定义的类路径依赖关系. 
         2> Bundle的MANIFEST.MF文件中,MANIFEST头Export-Package和Import-Package定义的依赖关系. 
         ■ 起动(starting) 
         一旦Bundle被起动,该Bundle的状态就被设置为ACTIVE,并一直持续到该Bundle被停止.在起动前,MANIFEST.MF文件中MANIFEST头Bundle-Activator定义的类将被实例化,该类实例的start方法被调用以起动Bundle. 
         ■ 停止(stopping) 
         一旦Bundle被停止,该Bundle的状态就被设置为RESOLVED.在停止前,上文中提到的Bundle-Activator类定义的stop方法被调用以停止Bundle. 
         ■ 激活(active) 
         已经被激活的Bundle可以进行自身状态的更新.在任何时候,OSGi框架只能满足一个Bundle的唯一版本可用.Bundle的更新操作支持该Bundle移植到一个高版本或向后兼容的版本. 
         ■ 已卸载(uninstalled) 
         在卸载前,上文中提到的Bundle-Activator类定义的uninstall方法被调用以卸载Bundle,该方法将使OSGi框架提醒其他Bundle它正在进行卸载操作,并设置该Bundle的状态为UNINSTALL.如果该Bundle与其他Bundle存在关系,如它导出一些被其他Bundle使用的包(即该Bundle的MANIFEST文件中定义了Export-Package值),OSGi框架在没有被重启的情况下将继续确保这些包仍可用.如果该Bundle与其他Bundle没有关系,OSGi框架将恢复到该Bundle被安装前的状态. 
         下面的Bundle状态图描述了Bundle的受控状态. 
         类装载(Class Loading) 
         Bundle就是一个JAR文件,OSGi框架所面临的首要问题就是,怎样去获取随时可能被"扔进"框架中的Bundle内的类文件和其它资源. 
         对于每一个已安装或已解析的Bundle,OSGi框架都会建立该Bundle的Classloader.这个Classloader还被建立在下面图3所示的委托模型中. 
         其中: 
         1> Bootstrap类装载器装载Java核心API中的类. 
         2> SystemClassLoader类装载器可以是系统类路径类装载器和标准扩展类装载器,还可以是其他用户自定义类装载器,装载系统CLASSPATH上的类或Java扩展路径上的类或用户指定的类. 
         3> BundleClassLoader类装载器装载该Bundle的MANIFEST文件中Bundle-ClassPath头所指定的类文件.如果该Bundle需要导入其它Bundle中导出的包,那么这些Bundle的类装载器的实例也要被建立在如图3所示的委托模型中,并为该Bundle提供它所需的类.
上文中只是对OSGi框架进行了简短地介绍,关于它的详细信息请参照: http://www.osgi.org 
         Eclipse3.0插件和OSGi Bundle 
         OSGi服务平台规范是一个开放的架构,用户可以根据自己的需要来实现这个规范.Eclipse3.0就提供了该规范的一个实现. 
         我们知道,在OSGi中基本的模块单元是Bundle,在Eclipse中则是插件(plug-in).在Eclipse2.1中,插件往往表现为plugins目录下的一个文件夹.例如如下的目录结构:
  + D:/eclipse
    + plugins
      + eclipseme
        + docs
        + icons
        + lib
        - about.html
        - CHANGES.txt
        - CREDITS.txt
        - eclipseme.jar
        - JETTY-LICENSE.html
        - LICENSE.txt
        - plugin.properties
        - plugin.xml
        - README.txt
        - toc.xml
      + org.apache.ant_1.5.3 
         上述eclipseme插件提供了Eclipse2.1平台和J2ME的集成.在每一个Eclipse2.1插件中,都包含一个plugin.xml文件,其中描述了插件名,版本号,需要的JAR包和插件要使用的扩展点等等. 
         ■ plugin.xml  插件清单文件 
         ■ plugin.properties  容纳被plugin.xml引用的字符串. 
         ■   about.html  证书信息 
         ■   *.jar  插件需要的类文件 
         ■   lib  容纳第三方JAR包 
         ■   icons  容纳icon文件,通常是GIF格式 
         ■   docs  容纳文档文件,通常是HTML格式 
         ■   toc.xml  文档结构清单文件 
         ■   (other files) 
         在Eclipse3.0中,插件不仅表现为plugins目录下的一个文件夹,还包括一个MF文件.这个MF文件可以位于该插件文件夹下.也可位于configuration/org.eclipse.osgi/manifests目录下.如:
例1:
  + D:/eclipse
    + configuration
      + org.eclipse.osgi
        + manifests
          - eclipseme_0.1.0.MF
例2:
  + D:/eclipse
    + plugins
      + org.eclipse.osgi_3.0.0
        + META-INF
          - MANIFEST.MF 
         在Eclipse3.0中,插件也可被称为Bundle.Bundle的类文件和资源文件就是插件文件夹下的JAR文件和其他资源文件,Bundle的MANIFEST文件就是上文中提到的MF文件. 
         Eclipse的插件信息是被配置在plugin.xml中的.OSGi Bundle信息是被配置在MANIFEST.MF文件中的.下面就说说它们的联系. 
         plugin.xml包括三个部分的信息. 
         1>   插件基本信息.如插件名,插件ID号,插件版本号,插件提供者名和插件类的全限定名. 
         2>   插件的依赖关系和插件的运行库. 
         3>   插件的扩展和扩展点. 
         在Eclipse3.0中,前两部分的信息可以被配置在MANIFEST.MF文件中.如Eclipse3.0中的runtime插件.考虑到与Eclipse以前版本的兼容,plugin.xml文件仍然支持对上三部分信息的配置格式.但是,Eclipse3.0平台运行在处理插件信息时,它认为插件是一个Bundle外加上扩展和扩展点. 
         Eclipse2.1的平台运行内核缓存所有插件的注册信息在Registry API中,所有这些信息是从.registry文件中或解析所有的plugin.xml文件(安装新插件的情况下)获取的.在Eclipse3.0中,Registry API已经不被建议使用,对所有插件的注册信息的缓存已被重构为两部分,一是Bundle数据,另外是ExtensionRegistry API,它们分别从.bundledata或.state文件和.registry.X文件中获取.这三个文件是Eclipse生成的,它们的数据来源是各个插件的plugin.xml和MANIFEST.MF文件.当平台安装新的插件时,它们都将被重新生成.之所以从它们中而不是直接解析plugin.xml和MANIFEST.MF文件,是要Eclipse起动更快. 
         在Eclipse3.0中,有些插件文件夹下并没有MANIFEST.MF文件,这是为了兼容Eclipse以前版本的插件.对于每一个已被Eclipse3.0安装(installed)的插件(Bundle),系统都会生成一个MF文件在configuration/org.eclipse.osgi/manifests目录下(已经有MANIFEST.MF文件的插件除外).被生成的MF文件内容只是该插件的plugin.xml文件中扩展点外的部分数据. 
         文章相关引用地址： 
         http://blog.sina.com.tw/archive.php?blog_id=2439&md=entry&id=2797 
         http://zzz8067.blogchina.com/blog/article_78895.319320.html