OSGi誕生初期，其目的主要是能夠靈活方便并遠程管理互聯的網絡嵌入設備，OSGi聯盟上對于OSGi service platform有這樣一句解釋：The OSGi service platform delivers an open, common architecture for service providers, developers, software vendors, gateway operators and equipment vendors to develop, deploy and manage services in a coordinated fashion.（OSGi service platform是一個開放并且提供通用接口標準的體系框架，基于這個體系框架，服務提供商，程序開發人員，軟件提供商，服務網管運營商，設備提供商能夠協調地聯合起來開發，部署以及管理向用戶提供的各種服務）。隨著OSGi的發展，逐漸被引入到企業應用領域。

目前，OSGi規范的最新版本為R4.2，有關該規范的詳細情況請閱讀OSGi實戰的第7節——深入OSGi。OSGi框架主要分為四部分：運行環境（executionenvironment）、模塊（Modules）、生命周期管理（Life Cycle）、服務注冊（Service Registry）。運行在OSGi環境中的是一個個的Bundle，也就是Modules的具體實現。

對于每個bundle，都有各自的ClassLoader，在這一點上和傳統的Web應用有相似之處，在傳統的Web應用開發完成之后，都會將其部署在Tomcat、Jboss等服務器上，這些Web應用都有著各自的ClassLoader環境，而兩者之間的區別在于，傳統的Web應用無法做到資源的共享，因為它們是完全獨立、隔離的。OSGi框架為bundle之間的協作提供了底層支持，通過在bundle的MANIFEST.MF文件中Import-Package、Export-Package等項，bundle之間就能相互共享資源及服務，在以后的博文中，我將給出一個具體的示例。

由于OSGi具有良好的模塊化結構，我個人認為這將為將來的軟件開發方式帶來很大的沖擊，將更進一步推進模塊化開發。目前Web應用的開發一般采用SSH框架，將整個應用大致分為Web（負責前臺展現）、Service（負責業務邏輯處理）、DAO（負責數據持久化）、Domain（全局實體類）幾個模塊，而發布的時候，將被一起打成WAR包，部署至服務器上。如果采取bundle的形式，每個模塊可以做為獨立的bundle進行開發和部署，bundle之間的協作可以通過上述的方式進行，而這樣帶來的好處就是，一旦需要對某個模塊進行更改，在保證依賴接口不變的前提下，就可以單獨更改相應的bundle，再進行熱部署即可，這樣一來，好處是顯而易見的，有效的分離了各個模塊，減少了維護成本。

由于采用bundle的形式，也增強了模塊的復用性。這也是得益于OSGi良好的模塊化方式。

另外一個很重要的點就是OSGi具備熱拔插特性，bundle的安裝、啟動、停止、卸載都可以在運行時指定，并且可以隨時更改。這樣一來，我們就可以做到無需重啟整個應用，而只對需要更改的部分進行升級或打補丁即可。Bundl的狀態圖轉換如下圖所示：

圖 1 OSGi bundle狀態轉換圖

以上將OSGi的一些基本的，但也是很重要的東西大概介紹了一下，在以后的博文中逐步深入吧。以上都是關于OSGi原理性的東西，那么實現該規范的有哪些產品呢？最有名的應該要數Eclipse的Equinox框架了，在網上查資料見有人說過，Eclipse3.0的那一次升級把自身的構架做了一次非常大的調整，其主要原因就是采用了OSGi框架，更好的支持了Eclipse的插件體系。另外還有Felix、knopflerfish等。

不過話說回來，盡管OSGi有很多好處，但是現在主要還是應用在服務器端，如現在的應用服務器基本上都采用OSGi的框架，而真正的應用市場仍處理起步階段，這和OSGi的生態環境還不成熟，可喜的是Spring推出了其Spring DM和SpringSource DM Server，前者能夠很方便發布和引用服務，并且與Spring Framework平臺相融合，將OSGi的bundle context與Spring applicationContext融合在一起，大大方便了OSGi的應用。后者是OSGi bundle的運行環境，是一個將Equinox和Tomcat融合在一起的服務器。在以后的博文中將詳細介紹這些內容。