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