大家都知道Eclipse是一個典型的插件系統，而從3.0起其插件體系架構就重構為基于OSGI規范來實現的，從這也可以看出osgi必然與Plugin Architecture是有很多的關聯性的，在這里就來說說自己對Osgi R3與Plugin Architecture的關聯。
首先還是來說說作為一個Plugin Architecture應該提供哪些功能：
1、插件的定義。
2、插件的加載。(文件、URL等形式)
3、插件的生命周期管理。(安裝、卸載、啟動、停止、更新)
4、插件間的交互機制。
5、插件的擴展。
從非功能性角度來講，作為Plugin Architecture應該對原有的非Plugin Architecture的系統的改造不能造成過大的侵入性，還有就是Plugin的管理以及易開發，其次作為Plugin Architecture，其最大的優點莫過于可以保證系統構成了一個平穩的結構體系，所有的交互、擴展都通過Plugin來進行，并同時保證各個Plugin的獨立性，使得系統基于一種拼裝式的結構(松耦合)，每個Plugin對于外部而言都是一個黑盒，那么就要相應的告訴外部這個黑盒所能提供的功能，調用的方式等。
現在來說說OSGI，Osgi規范于1999年開始制定，目前版本是R4，OSGI之前主要用于網絡設備的服務架構體系，那是一個典型的松耦合的服務架構體系，在被eclipse引入作為其插件體系架構后OSGI也被業界所關注，R4更是吸取了Eclipse的很多優點修訂而成，相對于上面的功能點來說說OSGI對應的規范點：
1、插件的定義。
OSGI規范中將插件稱為Bundle，Bundle作為整個插件的生命周期管理對象，負責插件的啟動和停止動作，通過Meta-inf/mainfest.mf來描述Bundle，主要描述Bundle的名稱、廠商、版本、對外暴露的包、對外暴露的服務、依賴的插件、引用的包、動態引用的包等，具體可參考OSGI R4中Framework Specification Chapter，插件可通過Bundle對象獲取插件的定義信息。
2、插件的加載。(文件、URL等形式)
OSGI規范中定義通過BundleContext來完成Bundle的加載工作，每個Bundle擁有獨立的classloader以及BundleContext。
3、插件的生命周期管理。
OSGI規范中定義通過BundleContext對Bundle進行生命周期的管理，或通過Bundle本身對象來進行。
4、插件間的交互機制。
OSGI規范中定義通過插件的定義中定義所需依賴的插件以及所需引用的包來實現插件的交互機制。
5、插件的開發。
OSGI規范中定義一個新的插件的開發需要的是構成其BundleActivator對象以及完成插件定義的描述。
6、插件所暴露的功能。
OSGI規范中定義通過在插件定義文件中描述插件所暴露對外的服務來說明插件對外所暴露的功能以及允許外部對此插件引用的包。
對于插件如何擴展OSGI規范中提及的是在修改插件后插件的自動更新以及熱加載來實現，而不是象Eclipse的擴展點機制。
根據上面我們可以看出OSGI規范確實非常適用于Plugin Architecture，對應點基本都存在，不過上面只是簡單的描述，具體的大家可參看OSGI R4，除了對于Framework的定義，OSGI R4中還定義了一些常用的服務的規范(如log、configuration、security等)，而且有Eclipse作為其R4的RI，Eclipse則使得插件的管理、 擴展以及易開發得到了保證，在管理上Eclipse上提供了管理的平臺，在擴展上eclipse上提供了擴展點機制，在易開發上eclipse提供了ide，使得插件的代碼開發、定義描述、調試甚至部署都變得非常的簡單，而且eclipse會根據插件定義文件中需引用的包以及依賴的插件而自動的構造相應的classloader而無需去引用那些lib，這保證了插件的獨立性(設計時)，呵呵，但大家是不是有發現什么不足點呢？
個人覺得OSGI規范中的不足點是插件的管理機制的定義，插件的管理機制上我覺得可以參考JMX增加一個Connector or Protocol layer plugin，^_^
插件的擴展機制由eclipse彌補了，其他的還真想不出什么不足點了。
突然開始覺得osgi比jmx+ioc實現的plugin architecture更為的好，以前覺得osgi沒有jmx+ioc好的原因在于osgi對于插件的獨立性保持的不夠，意思就是在插件對于外部或其他插件作為黑盒而言，沒有明確插件功能的描述以及調用方式的描述，這個怪自己之前對osgi規范看的不夠仔細，其實就是service，而在獨立性方面以前是想著在代碼中如果要直接調用其他插件的service，那豈不是要引用那個插件的包，而這個問題在eclipse ide中是解決了的，只需要在定義文件中定義所依賴的插件即可，而不需要引用那個包，那么這樣獨立性的問題自然也解決了，還有一個是管理性，在這方面仍然是jmx更為強，不過完全可以在osgi中增加一個admin plugin的實現，吸取jmx在這方面的優點，呵呵，而相比之下現在變成了jmx+ioc并沒有一個規范式的體系架構，實現起來只能是各按各的想法，而osgi的話畢竟是個規范，加上已經有eclipse這個現成的，何必再去發明輪子呢，^_^，也許某一天plugin architecture也會被列入jsr規范之中的。