上周五部門開會討論新一代產品（基於.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服務(進程內）進行通信
謝謝大家的閱讀，麻煩大伙點一下推薦，再次謝謝大家。 ^_^