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