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