隨著OSGi近兩年的迅猛發(fā)展，尤其是Java企業(yè)應(yīng)用領(lǐng)域廠商對(duì)OSGi的認(rèn)同，大家對(duì)于OSGi的新版規(guī)范的關(guān)注遠(yuǎn)遠(yuǎn)超過了之前的幾個(gè)版本，近來OSGi終于是放出了傳聞已久的R 4.2的Early Draft，其實(shí)從Early Draft來看，我覺得完全可以認(rèn)為不僅僅是一個(gè)小版本的升級(jí)了，甚至可以認(rèn)為是R5了，因?yàn)镽 4.2增強(qiáng)的東西還是非常多的，其中就包括了大家期待已久的RFC119，不過沒看到傳說中的RFC66，有一丁點(diǎn)的失望，不過相信后面的Draft中應(yīng)該會(huì)加上，:)，這樣看來，R5更是值得期待了，讓我們先來一起品嘗一下4.2 Early Draft這道大餐。
OSGi R 4.2 Early Draft中包括了這些方面：
1、RFC 120 Security Enhancements
這個(gè)部分是由BEA的人主導(dǎo)的，從規(guī)范來看，Bea自己新版的Weblogic中肯定是已經(jīng)實(shí)現(xiàn)了規(guī)范的。
個(gè)人對(duì)于OSGi Bundle這塊的安全控制的增強(qiáng)不是很感興趣，在這里就簡(jiǎn)單說下這次規(guī)范增強(qiáng)的目標(biāo)，BEA在使用OSGi做了新版的Weblogic后，碰到一個(gè)需求，就是Weblogic應(yīng)該控制自己的package是不應(yīng)該被其他部署在weblogic中的應(yīng)用操作的，那這在以前OSGi的規(guī)范中是支持不了的，因此提出了對(duì)原來安全規(guī)范的增強(qiáng)，規(guī)范中講了具體做，不過因?yàn)樽约翰桓信d趣，也就沒仔細(xì)看了，感興趣的同學(xué)可以去下載看看。
2、RFC 121 Bundle Tracker
這個(gè)部分是由IBM的BJ Hargrave主導(dǎo)的，從名字相信大家就能猜出作用了，在OSGI R4中有Service Tracker，可以跟蹤OSGi Service的變化狀況，但在實(shí)際的使用過程中，確實(shí)會(huì)出現(xiàn)有需求是要跟蹤Bundle的生命周期的變化的，這個(gè)我記得之前有個(gè)同學(xué)也和我提及過這點(diǎn)，我記得當(dāng)時(shí)我給了他一個(gè)借用OSGi Service來實(shí)現(xiàn)的方案，現(xiàn)在有了這個(gè)規(guī)范后大家以后就可以直接使用了。
Bundle Tracker的用法和Service Tracker基本完全一樣，所以無需多講。
3、RFC 125 Bundle License
:(，又是一個(gè)不感興趣的增強(qiáng)，這個(gè)部分由OSGi著名人物：Peter Kriens主導(dǎo)，目標(biāo)是為了能夠在Bundle的header信息中增加License信息，以便在安裝Bundle時(shí)就能夠知道這個(gè)Bundle是什么License機(jī)制的，例如LGPL、Apache等。
做法就是在MANIFEST.MF中增加了一個(gè)Bundle-License的項(xiàng)。
4、RFC 126 Service Registry Hooks
這個(gè)部分由IBM的BJ Hargrave主導(dǎo)，這個(gè)部分推出的目的是為了能夠監(jiān)聽指定Bundle中Service的變化情況，和以前的ServiceListener還是稍有差別，ServiceListener中只是監(jiān)聽Service，而沒法知道是哪個(gè)Bundle中的Service。
以后要監(jiān)聽指定Bundle中的Service的變化，只要直接調(diào)用OSGi提供的PublishHook、FindHook、BindHook和EventHook就可以了。
5、RFC 128 Accessing Exit Values from Applications
這個(gè)部分由IBM的Thomas Watson主導(dǎo)，這個(gè)部分是為了增加新的OSGi Service：Application Admin Service而提出的，作用是用來得到應(yīng)用的exit Value，就像我們?cè)谡{(diào)用native command的時(shí)候，通過Process可以取到command的exit value一樣。
6、RFC 129 Initial Provisioning Update
這個(gè)部分由Peter Kriens主導(dǎo)，看起來好像是為了實(shí)現(xiàn)加載不同類型的資源的，不感興趣，所以沒仔細(xì)看。
7、RFC 132 Command Line Interface and Launching
這個(gè)部分由Peter Kriens主導(dǎo)，這塊成規(guī)范了，也不知道算好事還是壞事，個(gè)人覺得利弊都有吧，好處是以后不用管什么OSGi實(shí)現(xiàn)的Console都敲同樣的命令了，不像現(xiàn)在Equinox和Felix console的命令就不同，壞處是如果有規(guī)范中不支持的命令的需求就不好玩了，難道做的像unix shell那么強(qiáng)大？
...從規(guī)范來看真的是，這個(gè)OSGi Console可真的強(qiáng)大無比了，支持piping、scripting、后臺(tái)運(yùn)行；支持多種方式連console，最重要的是，支持很容易擴(kuò)展自己的命令；另外，在規(guī)范中還增加了OSGi Framework的啟動(dòng)、停止、重啟腳本支持的規(guī)范，這倒是不錯(cuò)，以后可以寫個(gè)groovy什么的來啟動(dòng)Framework，指定需要加載的bundle什么的。
這個(gè)規(guī)范還是有點(diǎn)意思的，至少實(shí)現(xiàn)了這個(gè)規(guī)范的Console出來后還是很爽的，比現(xiàn)在的好用很多了，而且功能也強(qiáng)大多了。
8、RFC 134 Declarative Services Update
這個(gè)部分由BJ Hargrave主導(dǎo)，只是對(duì)之前DS的一點(diǎn)小升級(jí)：
允許自定義activate方法和deactive方法，其中activate方法的參數(shù)必須是ComponentContext或BundleContext，兩個(gè)都存在也可以，而deactive方法的參數(shù)必須是int/Integer或ComponentContext或BundleContext，或三者的任意組合，其中int是指deactive的原因，這點(diǎn)確實(shí)比以前好，可以知道原因了。
Service-Component屬性值支持通配符了，這點(diǎn)真的太好了，我想用過Service-Component來指定加載component文件的同學(xué)都深有感觸吧，以后就可以這么寫了 Service-Component: OSGi-INF/*.xml
Component配置中name屬性變?yōu)榭蛇x項(xiàng)；
XML Scheme namespaces改變?yōu)椋篽ttp://www.osgi.org/xmlns/scr/v1.1.0。
-----------------------------------------華麗的分隔線-----------------------------------------
說完上面這八點(diǎn)后，必須劃一條華麗的分隔線出來了，為什么呢，因?yàn)橐韵碌娜c(diǎn)是OSGi規(guī)范中里程碑式的動(dòng)作，也算是EEG的動(dòng)作終于要開始見成效了，以下三個(gè)規(guī)范是OSGi以往完全不存在的，也是為了企業(yè)應(yīng)用而增加的，這樣OSGi能夠更好的被使用到企業(yè)應(yīng)用中了。
1、RFC 98 Transactions in OSGi
這個(gè)部分主要由Peter Kriens和Pavlin Dobrev主導(dǎo)，所以這不是EEG的工作體現(xiàn)，這個(gè)部分是企業(yè)應(yīng)用領(lǐng)域的同學(xué)們期待了很久的，不過最后的解決方案貌似會(huì)讓大家有些失望，最后的解決方案是使用JTA來進(jìn)行實(shí)現(xiàn)。
傳說中的更強(qiáng)的版本需要等待EEG提交到OSGi R5中。
2、RFC 119 Distributed OSGi
這個(gè)部分主要由IONA的Eric Newcomer和David Bosschaert主導(dǎo)，這個(gè)部分我期待已久，IONA作為基于OSGi實(shí)現(xiàn)分布式應(yīng)用的先行者，確實(shí)有資格來做這塊的規(guī)范。
這個(gè)規(guī)范的目標(biāo)是：
部署在JVM中的OSGi Bundle可以調(diào)用其他本地或遠(yuǎn)程JVM中的OSGi Service；
部署在JVM中的OSGi Bundle可以調(diào)用其他本地或遠(yuǎn)程中非OSGi容器中的Service；
其他程序可以調(diào)用JVM中的OSGi Service；
說實(shí)話，對(duì)于規(guī)范中提出的做法，我持保留意見，規(guī)范中的做法是增加一個(gè)Distribution Software，由這個(gè)Distribution Software來負(fù)責(zé)對(duì)外提供各種各樣的訪問OSGi Service的方法，例如RMI、SOAP等等，另外，增加一個(gè)Discovery service，負(fù)責(zé)到指定的地址上去尋找OSGi Service。
看過規(guī)范后，發(fā)現(xiàn)和自己想象的還是有一定的差距的，不過也是，分布式OSGi要做成規(guī)范我覺得還是比較困難的，畢竟分布式后各家公司關(guān)注的點(diǎn)就不同了，所以我還是認(rèn)為Single JVM使用OSGi，然后分布式就各家根據(jù)各自的需求去實(shí)現(xiàn)，貌似這也是為什么SOA要落地做實(shí)現(xiàn)規(guī)范很難的原因，只能是架構(gòu)層次的指導(dǎo)，其實(shí)我是比較希望OSGi規(guī)范中能增加一個(gè)OSGi本地方式提供給其他程序調(diào)用的方法，例如讓我可以在webwork中調(diào)用（就像spring的ApplicationContext一樣）、spring中調(diào)用，當(dāng)然，自己做也可以做到，只是如果能被列入規(guī)范就更好了，不過仍然非常希望這個(gè)規(guī)范能幫助部分人，至少這樣使用OSGi的人還是會(huì)再度增加。
3、RFC 124 A Component Model for OSGi
這個(gè)部分由SpringSource的CTO：Adrian Colyer主導(dǎo)，真沒想到這個(gè)會(huì)被列入OSGi規(guī)范，因?yàn)橛X得OSGi的Service-Oriented Component Model已經(jīng)夠強(qiáng)了，那么來看看這個(gè)規(guī)范到底做了些什么吧。
這個(gè)規(guī)范其實(shí)就是Spring-DM的規(guī)范，因?yàn)閷?duì)Spring-DM還算熟悉，所以也只是粗略的看了下規(guī)范，不想在這里多講，而且不可否認(rèn)，Spring-DM給OSGi進(jìn)入企業(yè)應(yīng)用領(lǐng)域確實(shí)帶來了很多的好處，只是我覺得這個(gè)規(guī)范的標(biāo)題起的有點(diǎn)大了，好像是給OSGi新提出來的一樣，:(。
享受完這道大餐后，應(yīng)該說或多或少還是有些失望吧，畢竟最關(guān)注的兩個(gè)規(guī)范：RFC 66，沒出現(xiàn)；RFC 119，一般般，其他的規(guī)范嘛，更多的是一種錦上添花，:)，不過仍然是進(jìn)步，所以還是值得期待的，想想Console、Bundle Tracker、DS Update，也滿足了，:)
ps：在最新OSGi官方的blog上，Peter相當(dāng)興奮的寫到了一件事情，是關(guān)于各家Application Servers廠商都公開發(fā)布新聞稿，說明其AS是運(yùn)行在OSGi或兼容OSGi的，其中包括有：IBM、Oracle weblogic、Paremus、Prosyst、JBoss、SpringSource、Sun Glassfish，同時(shí)Oracle和SAP都宣布將采用OSGi作為其下一代AS的基礎(chǔ)，雖然這些廠商用OSGi來做AS已經(jīng)是很早以前就公開的事了，不過第一次這么多廠商一起來發(fā)布新聞稿來講這件事情還真的挺壯觀的，也說明了OSGi真的成為了AS界事實(shí)的工業(yè)標(biāo)準(zhǔn)了。
OSGi R 4.2 Draft下載地址：
http://www.osgi.org/download/osgi-4.2-early-draft.pdf
讓Peter興奮的那篇文章，文章里面還有各家廠商闡述采用OSGi的理由以及對(duì)OSGi的評(píng)價(jià)：
http://www.earthtimes.org/articles/show/world-leading-enterprise-application-server-providers,541827.shtml