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