OSGi 4.2將于8月發(fā)布 新版特性預(yù)覽
將于今年8月底發(fā)布的OSGi 4.2具有很多新特性，其中一些特性已經(jīng)被Equinox（Eclipse背后的OSGi引擎）實現(xiàn)。
以下是OSGi 4.2核心的新特性：
◆標準的啟動框架，這會簡化OSGi系統(tǒng)的啟動過程而不管底層的實現(xiàn)如何（比如說可以通過變換類路徑用Felix替換掉Equinox）。
◆Service Hooks，憑借它OSGi bundle能夠攔截并過濾去往其他bundle的服務(wù)（這么做能夠進行安全檢查，諸如此類）。
◆Bundle tracker，它可以在bundle啟動和停止時對其進行監(jiān)控。
◆增強的安全機制，這樣不管是肯定還是否定的許可都可以對授權(quán)機制進行定制。
◆標準的Bundle-License頭，這樣bundle就可以定義其協(xié)議需求以達到管理的目的。
OSGi綱要涵蓋了可能會出現(xiàn)的其他服務(wù)，它規(guī)定下一個發(fā)布要遵循著核心，但還會包括：
◆信息初始化，初始化信息可以存儲在bundle的清單中。
◆聲明式服務(wù)，現(xiàn)在BND已經(jīng)支持聲明式服務(wù)了，同時消除了某些限制。
◆遠程服務(wù)，之前發(fā)布的OSGi（即RFC 119）通過遠程技術(shù)將不同VM之間的OSGi服務(wù)連接器來。Bundle的外部配置可以定義服務(wù)的連接方式。不像RMI那樣，這些服務(wù)無需checked exception（很明顯，如果發(fā)生了通信錯誤則會拋出RuntimeException）。這已被Eclipse的ECF及Felix CXF實現(xiàn)了。
◆Blueprint extender提供了一個配置驅(qū)動的服務(wù)模型（類似于聲明式服務(wù)）但卻基于Spring模式。未來，服務(wù)可以在啟動時實例化并綁定到代理上，之后還可以進行改變。
Enterprise OSGi服務(wù)也不甘寂寞，它將含有一個基于OSGi的Transaction API（基于JTA），通過OSGi服務(wù)提供JDBC與JNDI，同時還會借助于JMX管理OSGi系統(tǒng)。Enterprise OSGi的一個難題就是Web容器，容器應(yīng)該可以將WAR安裝到運行著的OSGi系統(tǒng)中，正如Spring DM Server那樣。
還有幾個試驗性質(zhì)的服務(wù)（并沒有定義在規(guī)范中），例如創(chuàng)建嵌套框架的能力（OSGi引擎可以在其上實例化另一個OSGi引擎來運行應(yīng)用）以及TSL——一種基于shell的腳本語言，用于與OSGi服務(wù)進行交互并支持運行時命令。后者的目標是實現(xiàn)一個標準的shell以控制任意的OSGi引擎而不是針對特定系統(tǒng)的特定shell。像POSH和Pax-Shell這樣的系統(tǒng)已經(jīng)開始使用TSL了。
OSGi中那些試驗性服務(wù)的試驗手段與JCP中定義的那些試驗性系統(tǒng)是有很大區(qū)別的，相對于花費很長時間來定義規(guī)范，然后再獲得其工作方式的反饋信息，RFC采取了不同的策略：首先提供臨時性的細節(jié)描述，然后采取多個實現(xiàn)（Felix、Knopflerfish及Equinox等等）來獲得其反饋信息，接下來根據(jù)反饋來精華規(guī)范直到其穩(wěn)定為止而不是發(fā)布某些不確定的東西（與Java的發(fā)布形成了鮮明的對比）。在發(fā)布最終規(guī)范前有機會進行試驗并獲得反饋信息意味著未來的變化不太可能對最終規(guī)范造成嚴重影響。
該演講的一些結(jié)論與JSR 294的結(jié)果不謀而合。目前已經(jīng)合并了很多需求和實現(xiàn)，由于JavaC處理元模塊系統(tǒng)方式的原因，有人提出改變Java中可視化（visibility）的工作方式（包括新引入的模塊keyword）。大家就元模塊的含義與keyword展開了激烈的討論。Sun工程師及Felix提交者Richard Hall說到：
就我來說，我很理解Peter的擔(dān)憂：我們定義的東西含義太不明晰了，這最終會毀掉Java的愿景：“編寫一次，到處運行”。定義東西時如果能具體一些就好了。
幸好JSR 294還有時間進行完善；最近關(guān)于JSR 294的眾多評論表明大家都希望能有一個解決這些問題的合理方案。
【編輯推薦】
