目前，關注OSGi的人變得越來越多，OSGi本身也早已從那個專注于嵌入式平臺的“小”角色轉變過來了，慢慢向企業級應用市場滲透。

從某種角度說，Eclipse可以說是OSGi在企業應用領域的試金石，2003年Eclipse3.0做了一次架構上的調整，繼續延用插件的架構思想，但是從3.0版之后，是基于OSGi的實現。也就是這一次的調整，推動了Eclipse的迅猛發展。

這是在桌面應用的成功示例，而OSGi的目標遠不止于此，以其優秀的類加載機制，可以說，只需對其進行擴展，那么就可以目標瞄準任何一個領域。談到企業應用，無可避免的要涉及Web應用，相信大多數人都在從事該領域的開發。OSGi R4版已明確提出了對Web的支持方式——當然，這種方式還是很有限的，這一點將在后面的文章中詳細說明。

鑒于此，很多開源框架都已經或正準備發布支持OSGi的版本，比如Spring DM、Struts1.8.1、CXF等等，基本上日常所用的開源框架都發布了基于OSGi版本。另外，有不少應用服務器也已經基于OSGi進行實現，比如WAS從6.1版就已經是基于OSGi的實現，而Spring也在2009年推出了Spring DM Server，可見OSGi的吸引力還是很大的。

那么這一切將會為以后的開發帶來什么影響呢？本文試圖從OSGi和構件化開發的角度認識一下該問題。

OSGi的類加載機制非常優秀，為每個運行于其中的bundle創建了獨立的類加載器環境，而運行于同一個OSGi框架內部的bundle之間不像Web服務器中的Web應用那樣絕緣，它們之間是可以進行包依賴的，當然OSGi也提供了服務注冊等相關機制，確保bundle之間的相互協作能力。而且OSGi支持bundle動態部署。所以，系統無需停機重啟，就可以實現其內部的動態更新。

構件化開發的概念已經提了很多年了，似乎一直缺乏一種有效的機制對其進行支持。構件化開發為系統開發帶來了很多好處，整個系統的開發可以按照模塊的方式進行劃分，從而按模塊進行開發；系統由各模塊之間拼裝而成，通過代碼一級的依賴或者服務依賴的方式；對于某個模塊進行更新，只要保持接口不變，則可以實現對外界無影響。

由于缺乏有效的底層支持，構件化開發方式一直沒有推行起來。由其對于Web應用而言，想要實現構件化開發，似乎更是無從談起。

OSGi的出現，讓這一事情有所轉機。傳統的Web應用開發過程中，可能大多數人的做法就是將一個大的Web應用按功能模塊進行劃分，通過包切分來實現模塊化開發，但是各模塊之間并沒有從物理上隔離，只是以一種組織方式上的約束，使其從表面看上去是分離的。對于這種方式，動態更新某個模塊也就無從談起了。

而如果將OSGi引入Web應用，每個模塊都對應于一個bundle，那么模塊與模塊之間則從物理上進行了隔離，能有效的將模塊內部實現對外隱藏。模塊之間的交互，可以通過接口的導出與引用來實現，對于未經導出的部分，對于其他模塊是不可見的。另外，由于OSGi支持bundle的熱部署，那就意味著，在當前Web應用未停機的情況下，可以對某個或某些模塊（對應OSGi中的bundle）進行動態更新，而不影響整個應用的正常運行。

這種從物理上的有效隔離的方式，為重用帶來了新的方式。以前代碼一級的重用，一般都通過Jar包的形式進行，而這種方式存在上述的一些缺點，即封裝性不夠。而通過基于OSGi的bundle的形式，則可以有效隱藏內部實現，從包一級進行隱藏（這一點個人覺得可以作為Java封裝性的一種擴展，以前的封裝只能做到類一級，不知道未來是否會被Java規范吸收）。

就這一點而言，OSGi對構件化開發進行了很好的支持，當然OSGi并不為此而生。

以上所說的構件依賴都是基于API一級的，那么當然，我們也可以將Web Service等類型服務封裝至構件當中，再結合ESB，是不是對SOA的一種更好實現呢！ESB的關注點在于服務，這是一種細粒度的，它并不考慮服務的封裝、重用等方面——這些方面都由設計人員去把握。而結合OSGi，當然還需要其他設施的支持，比如CXF已經發布了基于OSGi的實現，可以將服務封裝至一個bundle，以bundle為單元，向外界提供服務，這種服務即變成了一種粗粒度的——構件的特點之一。

綜上所述，我相信，OSGi的發展，將會為構件化的開發方式帶來福音。

引出話題：OSGi和SCA在很多方面有著異曲同工這妙，并且SCA的實現框架——Tuscany也對OSGi做了支持。這兩者有互補特性，有時間將對這兩者做一個對比研究。