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