從新詮釋的OSGi規範

　　上週五部門開會討論新一代產品（基於.net Winform）的設計規範，從設計規範慢慢討論到體系結構等架構存在的問題，諸如菜單、工具條、狀態條、界面佈局等不能實現配置化和自動化，子系統之間擁有強依賴，甚至產生強依賴等等，最後我提出經過OSGi 框架來解決界面和模塊之間的問題，並立下軍令狀一週內把核心框架Beta搭建完畢，第二週進行一次培訓。

      基於項目的特色，結合貞寶兄的OSGi.Net 和Mono.Addins 進行了從新詮釋，在兩天半的時間裏經過Mono.Addins  和NLite 的依賴注入容器相結合實現了詮釋後的OSGi規範，再這裏首先感謝貞寶兄在OSGi規範的佈道和推廣工做，其次要感謝Mono.Addins 強大的擴展功能 ，起到了事半功倍的效果，若是沒有它的存在我就不敢誇海口了，呵呵。在用Mono.Addins 框架來實現OSGi 規範時也遇到一些問題，發現Mono.Addins 的擴展過於強依賴，不能獲取插件擴展的原始元數據再這一點貞寶兄的OSGi.net 實現的就好多了，徹底開放給使用者。有時間了自行實現一個，這是後話，其實在09年已經開發了Mbs 框架，裏面其實包含了OSGI 的不少東東，可是不標準。

      下面是詮釋後的OSGi 規範（備註該規範僅僅使用在公司項目中）概要介紹，裏面有不少值得商榷的地方，歡迎指正。

1          插件(Bundle)

插件是一個提供特定功能的獨立的子系統。

插件是獨立的可部署單元

插件能夠向其它插件提供擴展點，其它插件能夠擴展該插件

插件不能夠向其它插件提供服務。

插件提供的功能經過其類型空間來體現。

插件是由addin.xml清單文件、本地程序集(*)、資源和其它文件組成

插件具有獨立性、 隔離性和徹底可複用的特性，並具備獨立的類型空間。

2          插件運行時（BundleRuntime)

插件運行時是全部插件的運行容器。

BundleRuntime是一個單件的實例，當建立後，您能夠經過BundleRuntime.Instance來獲取這個實例。 主程序必須提供建立並啓動插件運行時的功能

3          插件擴展機制

插件能夠在啓動時動態的實現對其它插件的擴展而且暴露出擴展點供其它插件來擴展，當插件中止時，這種擴展會動態的卸載。

插件間的擴展沒有任何的耦合，即這種擴展機制能夠確保插件間沒有任何的依賴，達到絕對的複用。

插件的擴展機制是經過清單文件的ExtensionPoint節點和Extension節點來定義的。插件經過ExtensionPoint 節點向其它插件暴露擴展點。這個節點包含一個Path屬性，即擴展點的標識。 插件經過Extension節點定義一個其它插件擴展點的擴展，它經過Path屬性來指定對應的擴展點，並利用該節點下定義子節點，這些子節點就是一個擴展的詳細信息。

插件的擴展機制經常用在菜單、工具條、狀態條、UI界面的動態組合上，固然也能夠用在其它場景中。

4          服務管理機制

服務由服務契約和具體實現組成。

服務是指輕量級服務，

服務契約是暴露方法的接口，

服務實現則是實現指定接口的類型。

服務引入，使得咱們可將接口與實現分離，並在須要的時候選擇特定的實現。

服務的生命週期擁有兩種類型：單利、瞬時，默認註冊在服務容器中的服務是瞬時的

服務只能駐留在服務容器-IBundleContext.Container中

插件具備獨立的服務容器，所以插件內的全部服務之間是能夠通訊的，可是插件間的服務是不可以直接通訊的，除了根插件以外

面向服務的編程模型：「註冊-發現-綁定-卸載」，經過服務容器-IBundleContext.Container對象來進行的中相關的方法來使用的

服務具備動態性，通常狀況下，它在插件啓動時註冊到平臺，在插件中止時從平臺中卸載

5          插件依賴機制

一個進程只有一個根插件，全部的其它插件都依賴根插件，其它插件能夠共享根插件中資源、類型空間、服務

一個插件能夠依賴多個其它插件（根插件除外），其它插件只能依賴該插件的擴展點、資源、類型空間，不能依賴服務

6          插件間的通訊

任何插件均可以和根插件經過服務進行通訊，反之根插件和其它任何插件都不能經過服務進行通訊

插件間不能直接經過服務進行通訊

插件間能夠經過輕量級的消息總線通訊（進程內消息總線）

插件間能夠經過重量級的消息總系通訊（Socket）

插件間能夠經過重量級分佈式服務進行通訊（Remoting、WebService、WCF、REST)

插件間能夠經過輕量級REST服務(進程內）進行通訊

 

    謝謝你們的閱讀，麻煩大夥點一下推薦，再次謝謝你們。 ^_^