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為網絡服務提供了一套標準的, 面向組件的規范. 而網絡服務又是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和JSR291http://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 JavaTM and associated native components in the J2METM 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)。不過我認為重點是： - 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 在 Server 端發揮作用osgi是對j2se的增強，可以作為j2ee的基礎。jboss之所以在jcp投osgi的反對票，是因為jboss的核心（新項目名為microcontainer）實際上與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 中的應用。。。
|