OSGi是Open Service Gateway Initiative的簡(jiǎn)稱，該組織建立于1999年，是一個(gè)非贏利機(jī)構(gòu)，旨在建立一個(gè)開放的服務(wù)規(guī)范，為通過(guò)網(wǎng)絡(luò)向設(shè)備提供服務(wù)建立開放的標(biāo)準(zhǔn)。
OSGI 規(guī)范包括了構(gòu)建開放的可交付網(wǎng)絡(luò)服務(wù)的各方面，OSGI規(guī)范又包括了以下子規(guī)范：
◆ Framework規(guī)范(OSGI核心，提供一個(gè)安全的可管理的Java Framework來(lái)部署可擴(kuò)展的Java服務(wù)。)
◆ Package Admin Service規(guī)范（來(lái)管理不同的Bundle之間的引用關(guān)系。當(dāng)Bundle更新或者反安裝時(shí)判斷是否有其他的服務(wù)正在使用當(dāng)前的Bundle）
◆ Start Level規(guī)范(定義了啟動(dòng)和停止一個(gè)OSGi Service Platform時(shí)，不同的Bundles的啟動(dòng)或者停止的先后順序)
◆ Permission Admin Service規(guī)范（Bundle是否許可執(zhí)行另外的Bundle的代碼）
◆ URL Handlers Service規(guī)范(怎樣注冊(cè)URL Schema，如何將java.io.InputStream對(duì)象轉(zhuǎn)換為特定的Java對(duì)象)
◆Log Service規(guī)范
◆Configuration Admin Service規(guī)范
◆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規(guī)范的核心組成部分。它提供了一個(gè)通用的、安全可管理的Java framework。通過(guò)這個(gè)Framework可以支持一種叫做bundles的Service application的部署和擴(kuò)展。
OSGI兼容設(shè)備可以下載并且安裝OSGI bundles，也可一當(dāng)他們不再需要的時(shí)候刪除。bundles安裝后會(huì)注冊(cè)一定數(shù)量的Services,并被由同一個(gè)Framework下的其他bundles使用。
在一個(gè)動(dòng)態(tài)擴(kuò)展的的 OSGI環(huán)境中，Framework管理bundles的安裝和更新。同時(shí)也管理bundles和Services之間的依賴關(guān)系。
Framework提供給bundle開發(fā)者必須的資源來(lái)在Java平臺(tái)上開發(fā)，為開發(fā)的bundles提供了代碼動(dòng)態(tài)加載的功能, 也使得開發(fā)者開發(fā)、部署一個(gè)大規(guī)模的Services變的很容易。
其次，Framework為Java bundle開發(fā)者提供了簡(jiǎn)明一致的編程模型。簡(jiǎn)化了開發(fā)部署的復(fù)雜性。這個(gè)編程模型允許開發(fā)者將自己的接口規(guī)范綁定到OSGI環(huán)境中的Service。 Theselection of a specific implementation, optimized for a specific needor from a specific vendor, can thus be deferred to run-time.
一個(gè)一致的編程模型幫助開發(fā)者可以應(yīng)付一些可估計(jì)的危急錯(cuò)誤。Framework將會(huì)運(yùn)行在不同的硬件環(huán)境上，但一致的接口確保軟件組建可以運(yùn)行在一致的服務(wù)接口上。
The Bundle Object
對(duì)于每一個(gè)安裝在OSGI Service Platform的bundle都有一個(gè)與之關(guān)聯(lián)的bundle object。一個(gè)bundle對(duì)象用來(lái)管理bundle的生命周期。這項(xiàng)工作通常由Management Agent來(lái)做。
Bundle State
bundle有以下狀態(tài);
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 orhas 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.
1、JRE版本無(wú)關(guān)性。雖然Java一直被人們認(rèn)為是“Write Once, Run Anywhere”，但對(duì)于許多大型項(xiàng)目并非如此，常常因?yàn)椴煌?/font>JRE之間的一些小差別而花費(fèi)巨大，被人們戲稱為“Write Once，Debug Anywhere”。OSGi首先希望能消除這種無(wú)關(guān)性，因此它提供給人們一個(gè)比JRE更穩(wěn)定的承諾。
2、嵌入式設(shè)備的開發(fā)平臺(tái)。OSGi創(chuàng)立之初的方向是瞄準(zhǔn)了J2ME，可以看到委員會(huì)成員多數(shù)都不是軟件企業(yè)。倒是Moto和Nokia這類企業(yè)非常熱心。
3、高于package的完整的組件形式，還包括自從有組件開發(fā)以來(lái)一直困擾人們的組件版本問題。（這個(gè)可不是jar包啊，jar包只是bundle的一種實(shí)現(xiàn)-方式。）
4、推遲發(fā)生的依賴關(guān)系。當(dāng)組件A（例如含有菜單的窗體）依賴于組件B（例如菜單所表達(dá)的一個(gè)功能）時(shí)，在語(yǔ)言級(jí)上必須先有B再有A，但顯示中往往是先有A再有-B，所以OSGi為它們提供一種運(yùn)行時(shí)后綁定的機(jī)制。
5、新的軟件架構(gòu)。OSGi幾乎每個(gè)成員都是其所在領(lǐng)域的TOP，這些領(lǐng)域也都是在未來(lái)的數(shù)十年中軟件大行其到的地方，軟件商們（比如IBM）希望這些領(lǐng)域的軟-件架構(gòu)能夠統(tǒng)一一些，甚至是組件可以通用。
OSGi為網(wǎng)絡(luò)服務(wù)提供了一套標(biāo)準(zhǔn)的, 面向組件的規(guī)范. 而網(wǎng)絡(luò)服務(wù)又是SOA(Service Oriented Architecture)的基礎(chǔ). 使用OSGI平臺(tái), 就可以很輕松的管理軟件組件的生命周期, 這組件是可以位于網(wǎng)絡(luò)中的任何設(shè)備上, 而且組件可以動(dòng)態(tài)的安裝, 加載, 升級(jí)和卸載, 而不用終止和重啟設(shè)備. 這里的組件是指程序庫(kù)或者是應(yīng)用程序, 它們又可以動(dòng)態(tài)的使用別的庫(kù)和程序。
其實(shí)OSGi原本是為了解決家庭網(wǎng)絡(luò)或者嵌入式設(shè)備由于本身的限制(CPU, 內(nèi)存, 帶寬等)而出的一個(gè)解決方案, 是一個(gè)輕量級(jí)的框架. 但現(xiàn)在OSGi已經(jīng)遠(yuǎn)遠(yuǎn)的超過(guò)了它的原來(lái)的的功能. OSGi已經(jīng)應(yīng)用于移動(dòng)通訊, 汽車, 電信, 嵌入設(shè)備, PC桌面和服務(wù)器等眾多領(lǐng)域. 由于它的開放和簡(jiǎn)單的風(fēng)格, 吸引越來(lái)越多的著名公司加入, 使OSGi也愈加強(qiáng)大和開放。
我不了解OSGi在其他領(lǐng)域的應(yīng)用, 只是由于要使用Eclipse, 所以也只對(duì)OSGi在PC桌面方面的應(yīng)用做了些熟悉和了解. 和OSGi一樣, Eclipse也是個(gè)開放的平臺(tái), 它的基礎(chǔ)就是OSGi服務(wù)平臺(tái)(Services Platform), 架構(gòu)在OSGi上的Eclipse具有融合其他應(yīng)用和組件的能力, 使不同的組件能夠運(yùn)行在一個(gè)JVM(Java Virtual Machine)上, 使它們之間能夠協(xié)同工作, 占用較少得內(nèi)存和CPU時(shí)間, 而且能夠由平臺(tái)管理組件的全生命周期的活動(dòng), 可以說(shuō)一切都在控制之中。
在OSGi中, 每個(gè)具體的組件都要繼承于Bundle, Bundle是個(gè)接口, 定義了安裝, 升級(jí), 卸載, 啟動(dòng), 停止等操作. 其實(shí), 在Eclipse中, 插件(即上面所說(shuō)的組件)并不是從Bundle繼承的, 而是從另外一個(gè)重要接口BundleActivator繼承的. 后者只有兩個(gè)接口函數(shù)-Start和Stop. 從它的名稱就可以看出, 它其實(shí)是一個(gè)控制Bundle的類. 在Eclipse中有大量這樣的應(yīng)用, 一個(gè)類負(fù)責(zé)提供接口滿足不同的需要, 而有另外一個(gè)類負(fù)責(zé)操作這個(gè)類. 比如IWorkbench和WorkbenchAdvisor, IWorkbenchWindow和WorkbenchWindowAdvisor等, 這樣可以避免客戶直接和核心類打交道, 也減輕了客戶的負(fù)擔(dān)。
在Eclipse中, 組件都是以Plugin形式存在的, 幾乎每個(gè)組件都要有一個(gè)類實(shí)現(xiàn)(繼承)Plugin類(也有例外), 一般都是由Plugin來(lái)控制服務(wù)的加載和卸載, 因?yàn)?/font>Plugin繼承于BundleActivor. 除了Bundle, BundleActivor外, OSGi也提供了BundleEvent, BundleListner等接口. 這些比較簡(jiǎn)單。
另外一個(gè)重要的接口是BundleContext, 該接口提供了一個(gè)Bundle所需要的上下文環(huán)境, 一個(gè)Bundle對(duì)應(yīng)一個(gè)BundleContext, 當(dāng)Bundle停止(Stop)時(shí), 它也就銷毀了. BundleContext提供注冊(cè)服務(wù)工廠(ServiceFactory)的接口, Bundle可以注冊(cè)一些服務(wù)工廠接口, 這樣其他的Bundle就可以通過(guò)實(shí)現(xiàn)這些接口達(dá)到擴(kuò)展的目的. 在Eclipse中對(duì)應(yīng)的概念是”擴(kuò)展點(diǎn)(IExtensionPoint)”和”擴(kuò)展(IExtension)”. Bundle之間的交互是非常重要的, 利用這種技術(shù), 就可以將很大的項(xiàng)目分成多個(gè)Bundle, 然后搭積木就可以了。
eclipse 3.0并沒有用OSGI替換掉原來(lái)的PlugIn機(jī)制。它只是做了與標(biāo)準(zhǔn)兼容的工作：給用戶提供了一系列的API來(lái)訪問，在這個(gè)過(guò)程中，就必須要做一些改 變(比如plugin registry和loading機(jī)制)來(lái)同OSGI標(biāo)準(zhǔn)完全兼容。最初的Plugin核心只支持靜態(tài)的擴(kuò)展，就是說(shuō)，如果要改變一個(gè)已經(jīng)存在的Plug 就必須重啟core,也就是要退出Eclipse并重啟。
有很多人問Eclipse為什么要兼容OSGI規(guī)范而不是其他的規(guī)范呢?
在Eclipse被捐贈(zèng)出來(lái)以前，Eclipse由OTI來(lái)開發(fā)，其目標(biāo)是開發(fā)一個(gè)嵌入式Java軟件的開發(fā)平臺(tái)?；ヂ?lián)網(wǎng)上現(xiàn)在仍然由很多的連接指向 Visual Age Micro Edition (VAME). 這也是SWT被構(gòu)思的一個(gè)原因，他們想將SWT使用在嵌入式設(shè)備中的用戶界面。這種淵源關(guān)系解釋了當(dāng)時(shí)為什么選擇OSGI規(guī)范。
另外一個(gè)原因是除了OSGI沒有其他的規(guī)范。OSGI規(guī)范在輕量級(jí)服務(wù)架構(gòu)應(yīng)用方面被廣泛的支持。而且OSGI被好多電信業(yè)的知名公司和一些其他行業(yè)的知名公司所支持。他們需要使用OSGI來(lái)同Sun的J2ME來(lái)抗衡。
BMW汽車的應(yīng)用控制系統(tǒng)采用OSGI作為其底層架構(gòu)，估計(jì)這一定程度上顛覆了很多人對(duì)于Java的認(rèn)識(shí)，很多人都認(rèn)為基于java的系統(tǒng)低效，不可能用 于汽車這樣的應(yīng)用控制系統(tǒng)上，在EclipseCon 2006會(huì)議上BMW采用OSGI得到了證實(shí)，估計(jì)是猜想會(huì)被很多人懷疑，演講者在PPT上講了下BMW汽車的應(yīng)用控制系統(tǒng)，這套系統(tǒng)主要用來(lái)控制汽車上 的音箱、燈光等等設(shè)備，總共由1000多個(gè)Bundle構(gòu)成，但BMW汽車的應(yīng)用控制系統(tǒng)啟動(dòng)時(shí)間卻只需要3.5秒，是不是很令人驚訝呢，這也從很大程度 上反應(yīng)了采用OSGI的系統(tǒng)的效率并不會(huì)低。
這兩個(gè)非常成功的案例向大家證明了基于OSGI開發(fā)系統(tǒng)的可行性，同時(shí)這個(gè)兩個(gè)成功案 例的足夠的知名性以及優(yōu)秀的使用、技術(shù)效果也為OSGI的推廣鋪設(shè)了不錯(cuò)的基礎(chǔ)，到目前為止，關(guān)于OSGI被商業(yè)領(lǐng)域（例如IBM P5服務(wù)器系列、Websphere V6.1、Lotus Sametime、Adobe CS2等）、知名開源軟件領(lǐng)域（例如Apache等）采用的消息已經(jīng)是不斷的傳出，可以看出OSGI在服務(wù)器端應(yīng)用、企業(yè)應(yīng)用中已經(jīng)開始廣泛流行了，而這 對(duì)于OSGI更好的發(fā)展成為支撐服務(wù)器端應(yīng)用和企業(yè)應(yīng)用的規(guī)范會(huì)起到很好的推動(dòng)作用。
JMX 本來(lái)設(shè)計(jì)的用途就只為了管理，我們不該把他拿來(lái) (over use) 作為開發(fā)應(yīng)用程序的組件 (那是 EJB 或 JavaBeans 該做的事)。但 OSGi 卻可以!
JMX 多數(shù)用于 server 系統(tǒng)中，而 OSGi 卻不限于所開發(fā)的應(yīng)用程序。你可以用它開發(fā) embedded 系統(tǒng)、desktop 程序，甚至是 server 程序。
OSGi 不但提供了與 JMX 相似的容器管理能力，甚至它本身就是一套精密的 Framework。OSGi 采用Micro-Kernel 的架構(gòu)，可以提供無(wú)限延伸的功能。OSGi 的 Bundles 在線更新功能、以及應(yīng)用程序之微量?jī)?nèi)存執(zhí)行能力，都是開發(fā)應(yīng)用程序的利基。
行 文至此，又覺得 OSGi 與 JCA、JNDI 都有一些功能重迭及互補(bǔ)之處。只是 JMX、JCA、EJB、JNDI都經(jīng) JCP 標(biāo)準(zhǔn)，都屬于 J2EE 家族成員，但 OSGi 過(guò)去屈居于 Embedded System，聲名就不若前述標(biāo)準(zhǔn)響亮...。我覺得這完全是兩種思維模式：J2EE 的思維是 build on large scale，OSGi 的思維是 build on dynamic scale。OSGi 以小搏大。
為什么要用osgi，我認(rèn)為主要是因?yàn)?/font>java至今沒有出 現(xiàn)一個(gè)方便易用的組件配置模型。過(guò)去，JMX、ClassLoader、reflect都似乎可以做這個(gè)事情。但是，JMX太麻煩了，況且原本為J2EE 準(zhǔn)備的JMX，確實(shí)不太易用，走專用的協(xié)議，需要專門的客戶端，需要adapter來(lái)訪問等等....
而ClassLoader，單獨(dú)用ClassLoader，需要自己在其上構(gòu)建一層包裝，否則用起來(lái)很麻煩。Reflect的配置方式和ClassLoader一樣的問題 。
但是，所有java的組件配置方式，包括使用classloader的osgi在內(nèi)共有的一個(gè)問題就是，被替換組件的回收時(shí)間無(wú)法控制。
OSGi和SCA到底能有什么關(guān)系呢，確實(shí)，至少?gòu)默F(xiàn)有的OSGi規(guī)范以及SCA規(guī)范分別來(lái)看，兩者沒有直接的關(guān)聯(lián)，由于OSGi規(guī)范是對(duì)于嵌入式領(lǐng)域的 軟件而制定的，其特別注重軟件的動(dòng)態(tài)性的支持，而SCA規(guī)范是對(duì)于企業(yè)應(yīng)用領(lǐng)域的軟件而制定的，并且是基于SOA的，其特別注重對(duì)于企業(yè)應(yīng)用而言的基礎(chǔ)設(shè) 施的實(shí)現(xiàn)，同時(shí)又盡量的去屏蔽對(duì)于SCA容器使用者而言SOA帶來(lái)的技術(shù)實(shí)現(xiàn)細(xì)節(jié)的難度；但根據(jù)OSGi規(guī)范以及SCA規(guī)范，同時(shí)又能發(fā)現(xiàn)兩者有個(gè)共同希 望解決的問題，那就是規(guī)范的模塊化，這是OSGi規(guī)范和SCA規(guī)范中的一個(gè)共同目標(biāo)。
在規(guī)范的模塊化上無(wú)疑OSGi占據(jù)了優(yōu)勢(shì)，OSGi規(guī)范詳細(xì) 的定義了作為OSGi框架應(yīng)該如何去實(shí)現(xiàn)以支撐規(guī)范的模塊化，同時(shí)也定義了應(yīng)該如何規(guī)范的來(lái)建設(shè)模塊，而在SCA規(guī)范中只定義了如何規(guī)范的來(lái)建設(shè)模塊，并 未定義如何規(guī)范的來(lái)實(shí)現(xiàn)SCA容器，既然是這樣，SCA規(guī)范是否可以考慮直接使用現(xiàn)有的好輪子---OSGi作為SCA容器實(shí)現(xiàn)的基礎(chǔ)呢，在使用OSGi 的情況下，SCA容器就沒必要費(fèi)勁就考慮怎么樣實(shí)現(xiàn)自己規(guī)范的模塊化了，這個(gè)就有點(diǎn)象當(dāng)年的Java Module System規(guī)范，除非SCA小組能夠有突破性進(jìn)展的實(shí)現(xiàn)規(guī)范模塊化的方法，那另當(dāng)別論。
使用OSGi的話自然的就給SCA帶去了一個(gè)好處，那就 是動(dòng)態(tài)性的支持上，這是OSGi的核心也是最大的優(yōu)勢(shì)，Peter在他最新的blog中也提及Module Layer是OSGi規(guī)范中最為關(guān)鍵的部分，正是因?yàn)?/font>Module Layer才使得OSGi其他部分得以搭建。
當(dāng)然，基于OSGi去實(shí)現(xiàn)SCA容器必然會(huì)碰到這樣那樣的技術(shù)難題，這可以依靠OSGi框架的實(shí)現(xiàn)者們和SCA容器的實(shí)現(xiàn)者們來(lái)協(xié)作的解決，就像Spring and OSGi。
那 么對(duì)于OSGi而言呢，基于OSGi去實(shí)現(xiàn)SCA容器又會(huì)給OSGi帶來(lái)什么好處呢，其實(shí)非常明顯，在這樣的情況下OSGi就真正的進(jìn)入了企業(yè)應(yīng)用領(lǐng)域， 真正的成為了以后企業(yè)應(yīng)用領(lǐng)域的核心基礎(chǔ)，所以我在之前的blog中說(shuō)過(guò)，SCA非常象是OSGi在企業(yè)應(yīng)用的延伸或擴(kuò)展形成的規(guī)范。
當(dāng)然，要做 到上面所說(shuō)的，不僅僅是想就有用的，需要去努力做到，近期準(zhǔn)備發(fā)封mail先試探著問問OSGi EEG們對(duì)于SCA有什么想法，是否可以考慮直接讓SCA變成OSGi EEG的規(guī)范，同時(shí)讓SCA規(guī)范制定小組納入OSGi Core作為SCA容器實(shí)現(xiàn)的規(guī)范的部分。
ps：近期Spring and OSGi的進(jìn)展非?？上玻F(xiàn)在Spring and OSGi的project已經(jīng)提升為了正式的project，而且在提升之前也對(duì)外正式公布了Spring and OSGi的repository，Spring and OSGi project的網(wǎng)站地址位于：
http://www.springframework.org/osgi
JSR 277（Java 模塊系統(tǒng)）與OSGi（JSR 291）的爭(zhēng)論再次變得白熱化，JSR 316（Java EE 6）的提交又一次引燃了關(guān)于OSGi與JSR 277互相重疊的爭(zhēng)論。InfoQ整理總結(jié)了其中的若干觀點(diǎn)和論據(jù)。
Peter Kriens寫了一篇博客文章討論Java EE 6中對(duì)Profile的使用，并展示了如何用組件結(jié)構(gòu)來(lái)代替模塊系統(tǒng)作為Java EE 6的基礎(chǔ)。Kriens還質(zhì)疑了Java EE 6規(guī)范中對(duì)JSR 277的使用，他說(shuō)：
JSR 316僅僅在規(guī)范的需求部分，以一種相當(dāng)間接的方式提到了JSR 277。大致上是說(shuō)JSR 277正在制定中，他們將推遲任何決定，直到JSR 277完成?？瓷先ヮH有道理，因?yàn)閺木幪?hào)上看277比291更老也更成熟？但實(shí)際上，277仍然處在草案復(fù)審階段，而291已經(jīng)最終發(fā)布，因?yàn)?/font>291的基 礎(chǔ)是從1999年發(fā)布至今，已經(jīng)經(jīng)過(guò)4個(gè)主要修訂版的非常成熟的OSGi規(guī)范。那么，應(yīng)該有別的理由不提JSR 291吧？也許277提供了291缺少的特性？嗯，沒有。從JSR 277規(guī)范的需求看，誰(shuí)也沒法說(shuō)它的目標(biāo)比JSR 291/OSGi更加遠(yuǎn)大：沒有動(dòng)態(tài)、沒有類空間一致性、沒有卸載、沒有包引用等等。277的初步草案仍然處在一種過(guò)于簡(jiǎn)單化的程度。即便是277唯一比291強(qiáng)的Repository，也仍然有許多晦澀不明之處。JSR 277最近開放了郵件列表， 從里面的討論中可以看出，似乎他們?nèi)匀槐灰恍┗镜哪K性問題所困擾。不過(guò)，幸運(yùn)的是，JSR 277專家組已經(jīng)承諾讓277的模塊系統(tǒng)與JSR 291/OSGi互操作。這就消除了選擇OSGi的最后一絲風(fēng)險(xiǎn)，更不用提今天就可以在各種VM（從1.2到6，以及嵌入式設(shè)備）上運(yùn)行OSGi的額外好 處，而JSR 277只能運(yùn)行在2008年下半年才會(huì)發(fā)布Java 7上。那么，為什么JSR 316要停下來(lái)等？我們已經(jīng)有一個(gè)完美的方案，而且JSR 277承諾將會(huì)兼容？
Alex Blewitt也質(zhì)疑了Java EE 6選擇JSR 277的決定：
提交的草案聲稱：
為了更好地支持這個(gè)平臺(tái)在擴(kuò)展性方面的目標(biāo)，應(yīng)該有一個(gè)更加寬泛的模塊概念。這項(xiàng)工作正由“JSR 277——Java模塊系統(tǒng)”展開，它的目標(biāo)是Java SE 7。我們預(yù)期Java EE 7將建立在這項(xiàng)技術(shù)的基礎(chǔ)上，因此我們將推遲任何可能與將來(lái)的版本沖突的技術(shù)規(guī)范。
也就是說(shuō)，他們選擇了JSR 277而非JSR 291，并且拒絕在JSR 277隨Java 7發(fā)布之前考慮任何其它選擇。
InfoQ也詢問了Eric Newcomer是否認(rèn)為SUN應(yīng)該接受OSGi：
絕對(duì)應(yīng)該，絕對(duì)合理。更重要的問題是關(guān)于Java的未來(lái)，關(guān)于SUN是會(huì)擁抱OSGi還是繼續(xù)對(duì)抗，如果他們繼續(xù)對(duì)抗OSGi，對(duì)Java又會(huì)有什么影響。根據(jù)我最近有限的OSGi經(jīng)驗(yàn)來(lái)說(shuō)，它在許多方面都給Java帶來(lái)了顯著的改進(jìn)——模塊性、版本、增強(qiáng)的類裝載。
Sun 投票反對(duì)JSR 291，不過(guò)JSR 291仍然獲得了通過(guò)，正式成為JSE的一部分。不過(guò)這已經(jīng)表明了Sun的立場(chǎng)。JSR 277是由Sun提案的，內(nèi)容是Java模塊性，這看起來(lái)明顯跟OSGi重疊。Sun有過(guò)很好的機(jī)會(huì)擁抱OSGi并以之為基礎(chǔ)構(gòu)造Java 7，不過(guò)，雖然沒有正式的聲明，但看上去他們更傾向于重復(fù)OSGi的工作而不是擁抱OSGi。
我期望Sun能盡快理性地對(duì)待OSGi。不過(guò)，也許Sun繼續(xù)站在OSGi的對(duì)立面反而更好，因?yàn)橹两?/font>OSGi都發(fā)展得很好。
Hani Suleiman，JSR 291專家組的成員之一，對(duì)這場(chǎng)爭(zhēng)論有不同看法。在回答關(guān)于JSR 277和OSGi有什么共同基礎(chǔ)時(shí)，他說(shuō)：
[……]JSR-277（在某種程度上）是一個(gè)共同的基礎(chǔ)。它從JDK這一面著手解決問題，這讓OSGi和其他類似方案（Maven、Ivy等）的任務(wù)變得更加容易。組件包（Bundle）/模塊成為JVM層次的一等公民。
除此之外，（OSGi或其它）框架可以按照自己的意思添加任何增值功能。277并沒有限制。OSGi支持者們感到不高興只是因?yàn)榛A(chǔ)標(biāo)準(zhǔn)用的不是他們的實(shí)現(xiàn)，而且還考慮了很多其它方面的東西。
用Hibernate來(lái)打比方，請(qǐng)想象這樣的情形：JBoss一直攻擊JPA規(guī)范，說(shuō)它是重新發(fā)明輪子，所有人都應(yīng)該把Hibernate當(dāng)作標(biāo)準(zhǔn)。這就是OSGi支持者們正在做的。
其他人，如Neil Bartlett，也就JSR 277專家組的討論內(nèi)容提出了他們的擔(dān)心：
請(qǐng)看看JSR 277的專家組郵件列表，它已經(jīng)向公眾開放（雖然是只讀的）。從這些討論來(lái)看，很難認(rèn)為他們有傾聽兩位OSGi專家（Glyn Normington和Richard Hall）的意見。在JSR 277草案的規(guī)范定義和應(yīng)用舉例中，有很多地方跟OSGi是不可調(diào)和的：Sun拒絕學(xué)習(xí)任何OSGi/JSR 291的經(jīng)驗(yàn)。
OSGi支持者們并不是因?yàn)槲覀冏钪幸獾哪K系統(tǒng)沒被選中就大發(fā)牢騷。這太孩子氣了。我們鼓噪是因?yàn)樵瓌t問題，JSR 277這個(gè)模塊系統(tǒng)正在邁向失??！如果在JVM里綁死了一個(gè)殘缺的模塊系統(tǒng)，這會(huì)給整個(gè)Java社區(qū)造成巨大的破壞。
Chris Custine從另一個(gè)角度看這場(chǎng)爭(zhēng)論的起源：
我認(rèn)為Sun和OSGi的激烈沖突純粹是關(guān)于控制權(quán)和許可證的政治斗爭(zhēng)。根本和技術(shù)無(wú)關(guān)！Java社區(qū)的政治又一次無(wú)視了每個(gè)理智的人都具備的常識(shí)和邏輯。我一向非常期待Java能夠再次復(fù)興它在創(chuàng)新和進(jìn)化上的能力，但正是這些東西讓我擔(dān)心……
Glyn Normington，JSR 277專家組成員和JSR 291的規(guī)范帶頭人，試圖謹(jǐn)慎地表達(dá)他的觀點(diǎn)。除了兩者的特性對(duì)照，Normington還就爭(zhēng)論中涉及的問題寫了一篇詳細(xì)的介紹。他解釋說(shuō)“這兩項(xiàng)JSR的目標(biāo)是非常不同的，雖然背后的概念很接近。JSR 277和294是在Java SE平臺(tái)之中加入基本支持；而JSR 291是純Java的，它建立在Java平臺(tái)之上”。
Normington認(rèn)為在JSR 277中重用OSGi并不容易，他也討論并推翻了放棄JSR 277的想法，最后提出了他認(rèn)為最合適的解決方案：
最佳方案很清楚：JSR 277應(yīng)該接受JSR 291，為此應(yīng)該在JSR 294里加強(qiáng)語(yǔ)言和VM上的支持，并且加入JSR 277的Repository架構(gòu)。這樣可以讓JSR 277的進(jìn)程提前數(shù)年，還保證了JSR 277和JSR 291之間完美的互操作性。
但要想實(shí)現(xiàn)這個(gè)最佳方案，需要Sun轉(zhuǎn)一個(gè)180度的大彎。也許，只是也許，Sun為了保證Java的成功，終究會(huì)做這件事。也許，只是也許，將來(lái)Java社區(qū)可以回顧今天，并且模仿丘吉爾的話說(shuō)：“在窮盡了所有選擇之后，總是可以指望Sun做正確的事”。
社區(qū)里面對(duì)于什么是這個(gè)困境的最佳解決方案肯定也是爭(zhēng)論不休——您的看法呢？
聯(lián)系客服
