去年我們組要開發一個新的產品，在討論產品架構路線的時候，美國的架構師向大家征集了架構設計思想（我推薦了SCSF），有一位工程師向他推薦了OSGi。以前我還沒有聽過OSGi這玩意，雖然我參加工作后，現學了Java和Flex，但非常菜。在工作之前我用了4年的.NET。接觸了OSGi后，發現它是一個面向Java的服務規范，還沒有一個像樣的面向.NET的框架（有個EgeyeAddIn，據說兼容OSGi，我看了源代碼了，覺得它離OSGi較遠http://www.codeplex.com/EgeyeAddIn）。隨著對其概念的模糊了解，我覺得這玩意不錯，于是我準備自己做個基于.NET的OSGi框架（因為我在業余的時候在設計一個UI框架，原先準備采用SCSF，接觸了OSGi后，我決定將二者合并，重新設計OSGi+CAB的框架）。于是，我在互聯網找了很多次關于OSGi的資料，但很失望，沒有得到多少需要的東西。因此，我只好自己翻譯了OSGi規范前6章，邊翻譯，邊理解（當我翻譯完第6章的時候，發現網上已經有OSGi規范中文版了，給自己省了點事），期間我翻譯了SCSF英文指南，看了EgeyeAddIn、SharpDeveloper Core和Eclipse OSGi的源代碼，最終設計了基于.NET的OSGi規范和OSGi.NET概要圖，目前OSGi.NET測試版已經完成，預計年底可以發布。因此，對OSGi和SOA有了更深一步的了解。

　　在我理解中（對于SOA，我不專業，如果有誤，大家批評），目前大部分應用的SOA中的S，已經不是傳統意義的Web Service或者遠程Service類似的Heavy Service，而更偏向于暴露出一個接口，向其它模塊提供通用功能的服務（或類）。在分層應用，上層類將調用下層的類，這種依賴是層與層之間的依賴，相比沒有分層的混沌狀態的類間依賴要好很多；在SOA應用，模塊間通過服務依賴，這種依賴是可以管理的，非常清晰，每一個模塊也很容易被重用。下圖是我理解的分層和SOA的比較。

　　OSGi規范是一個服務框架的規范，在OSGi中，（1）每一個模塊叫Bundle，即服務包，每個服務包向其它服務包暴露其服務，服務包間服務的引用是可以管理的；（2）每一個服務包類似一個模塊，其實更是一個插件，可以被動態的加載到OSGi框架，動態注冊、引用、回收和卸載服務，也可以被動態的卸載；（3）服務包在運行時的依賴是通過可管理的服務來體現，在設計時，從功能復用的角度，即一個服務包會使用另一個服務包的類，服務包之間在設計時有一種依賴，這種依賴在服務包清單配置文件中定義，由Export、Import、Require、DynamicImport配置節組成。Export即這個服務包暴露出的可被別的包使用的類型集合定義，Import是服務包引用其他服務包Export的定義，Require則是引用了另一個服務包的所有Export定義。因此，OSGi還定義了類型加載模型，用于實現一個服務包從OSGi系統加載其依賴的類型。

　　OSGi內核在實現上，有點復雜，在此不過說，估計關心的人會少一點，能把OSGi的SOA思想和應用用好就Very Good了。OSGi.NET是我們團隊利用業余時間開發的，從2008年10月份開始，借鑒了SharpDevelop、EgeyeAddin和Eclipse OSGi設計，用分層方式，劃分成配置成、解析元數據層、解析層、運行時加載層、Bundle層、Core層和Adapter層，當然最重要的是面向最終用戶的公共接口層了，第一個版本的設計是大部分兼容OSGi規范，把認為復雜的需求給去掉了，也簡化了Service的設計。由于接觸SOA時間比較晚，對SOA的理解沒有SOA專家體會的深，歡迎批評指正。

it知識庫：OSGi——面向服務架構規范簡述，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。