作者 林昊 發(fā)布于 2009年10月16日 上午5時47分
- 社區(qū)
- Architecture,
- Java
- 主題
- 開放源代碼,
- 應(yīng)用服務(wù)器,
- 平臺,
- 企業(yè)架構(gòu)
- 標(biāo)簽
- OSGi,
- 圖書
OSGi 在Java業(yè)界正是風(fēng)生水起。幾乎所有的JEE Server,比如IBM Websphere、Oracle Weblogic和Sun glassfish,都采用了OSGi作為基礎(chǔ)平臺,甚至推崇實用主義的SpringSource也挾Spring DM之勢,推出了基于OSGi的應(yīng)用服務(wù)器——Spring DM Server。山雨欲來風(fēng)滿樓,乘著這股東風(fēng),在BlueDavy發(fā)布了《OSGi實戰(zhàn)》以及《OSGi進(jìn)階》之后,國內(nèi)第一本OSGi的專業(yè)書—— 《OSGi原理與最佳實踐》剛剛面世。InfoQ中文站精選了其中的兩章,特做成迷你書,供各位讀者免費下載。
免費下載迷你書
如果你喜歡本書,請通過購買原版《OSGi原理與最佳實踐》支持出版商和InfoQ中文站。
點擊這里: 免費下載這本書(PDF) 。
迷你書目錄
前言
目錄
第1章 OSGi框架簡介
1.1 Equinox
1.1.1 簡介
1.1.2 環(huán)境搭建
1.1.3 HelloWorld
1.1.4 開發(fā)傳統(tǒng)類型的應(yīng)用
1.1.5 從外部啟動Equinox
1.2 Felix
1.2.1 簡介
1.2.2 環(huán)境搭建
1.2.3 應(yīng)用部署
1.2.4 在Eclipse中調(diào)試Felix
1.3 SpringDM
1.3.1 簡介
1.3.2 環(huán)境搭建
1.3.3 HelloWorld
1.3.4 Web版HelloWorld
第2章 基于SpringDM實現(xiàn)Petstore
2.1 即插即用的Petstore
2.2 新一代Petstore的實現(xiàn)
2.2.1 環(huán)境準(zhǔn)備
2.2.2 Utils模塊
2.2.3 Bootstrap模塊
2.2.4 ProductDal模塊
2.2.5 ShoppingCartDal模塊
2.2.6 ProductList模塊
2.2.7 ShoppingCast模塊
2.2.8 ProductManagement模塊
2.3 部署
2.4 Petstore的擴(kuò)展
BlueDavy《OSGi原理與最佳實踐》采訪
InfoQ中文站就這次出版邀請BlueDavy對OSGi的近況、在具體項目上應(yīng)用OSGi應(yīng)該注意的問題和解決方法,以及如何在OSGi開發(fā)過程中結(jié)合使用敏捷實踐的問題進(jìn)行了一番訪談。
InfoQ:自從你上一次發(fā)布<OSGi進(jìn)階>后,OSGi聯(lián)盟最近有什么新進(jìn)展?OSGi社區(qū)發(fā)展如何?
BlueDavy:OSGi聯(lián)盟目前正在制定4.2的規(guī)范,并已發(fā)布公開草稿版本。在草稿版本中,我很欣慰的看到了OSGi聯(lián)盟對 OSGi所做出的眾多改進(jìn),包括了OSGi使用者們期待已久的對于Declarative Services的細(xì)節(jié)改進(jìn),并將其版本定為1.1,目前Equinox也已推出1.1版本Declarative Service的實現(xiàn);除了對DS的改進(jìn)外,在Core部分也可以看到提出了Framework Lunch這樣的新規(guī)范部分,這對于按照標(biāo)準(zhǔn)使用OSGi和嵌入OSGi至其他容器提供了很大的幫助。除了以上這些外,還有其他很多的改進(jìn),在《OSGi 原理與最佳實踐》一書中對OSGi R4.2的公眾草稿版做了更多詳細(xì)的分析。
但由于公布的公眾草稿版本并不涉及企業(yè)應(yīng)用領(lǐng)域,也就是EEG小組的工作,因此盡管大家期待的RFC 119: Distributed OSGi以及RFC 66: OSGi web container出現(xiàn)在了Early Draft中,但并沒有出現(xiàn)在公眾草稿版中,這兩個最受大家關(guān)注的規(guī)范內(nèi)容應(yīng)該會被列入EEG出版的規(guī)范中。
對于社區(qū)這一塊,OSGi盡管已經(jīng)發(fā)展這么多年了,到目前為止確實仍然沒有非常成熟的社區(qū),但其相關(guān)的maillist,例如equinox maillist、OSGi-Dev maillist以及Spring-DM maillist都相當(dāng)?shù)幕钴S,業(yè)界的OSGi的使用者們根據(jù)自己的經(jīng)驗提出了不少OSGi的最佳實踐,其中Bea的最佳實踐總結(jié)以及Peter和BJ Hargrave在2007 JavaOne做的OSGi最佳實踐總結(jié)給大家提供了很大的幫助。
InfoQ:相信很多人都想在真實項目中使用OSGi。請問如果要基于OSGi開發(fā)新系統(tǒng)時需要注意什么問題?如何設(shè)計系統(tǒng)的架構(gòu)才能充分利用OSGi的好處?
BlueDavy:基于OSGi開發(fā)新系統(tǒng)時最值得注意的問題就是如何合理地劃分模塊的粒度,以及遵循OSGi框架的實現(xiàn)方式來構(gòu)建真正的模塊化、動態(tài)化的系統(tǒng)。
由于OSGi的強項在于模塊化以及動態(tài)化,如果想在系統(tǒng)中充分發(fā)揮這兩個優(yōu)勢,一方面是要讓系統(tǒng)真正的模塊化,把握好每個模塊需要對外提供的功能,充分合理地使用OSGi提供的模塊化交互的方式,例如import-package以及OSGi。
Service另一方面則是要讓系統(tǒng)真正的動態(tài)化,這包括了基于OSGi框架支持的Bundle生命周期管理以及服務(wù)組件生命周期管理合理構(gòu)建動態(tài) 化的模塊,同時也需要合理處理動態(tài)化時所帶來的影響,例如引用的服務(wù)的注銷、對象狀態(tài)的保留與恢復(fù)等。在《OSGi原理與最佳實踐》一書中提供了一些構(gòu)建 模塊化和動態(tài)化系統(tǒng)的實踐建議以及為什么要如此做的分析。
InfoQ:我們也看到在現(xiàn)實中存在著大量的遺留項目。那么,對于把傳統(tǒng)的遺留系統(tǒng)改造成基于OSGi的架構(gòu),一般需要注意什么問題?
BlueDavy:突出的問題一般是模塊ClassLoader隔離后帶來的問題,對于OSGi的入門者來 說,ClassNotFoundException或者ClassCastException這類異常會成為常見的現(xiàn)象,這就要求使用者能夠?qū)? ClassLoader以及OSGi模塊隔離和交互這兩方面的知識有充分的掌握,就如BEA的microServices的開發(fā)者們總結(jié)的一樣:當(dāng)你不使 用OSGi來構(gòu)建模塊化系統(tǒng)時,你根本就不知道什么是真正的模塊化系統(tǒng),他們在移植原有的BEA的產(chǎn)品到OSGi上時花了一年多的時間,這也意味著要將傳 統(tǒng)系統(tǒng)改造為OSGi架構(gòu)確實有不小的難度,無論是OSGi知識方面的學(xué)習(xí)還是設(shè)計思想方面的轉(zhuǎn)變。
InfoQ:Oracle收購了Sun,這兩家公司勢必要在很多方面整合,比如雙方對OSGi的態(tài)度。我們知道,雖然有很多JEE Server都選擇架構(gòu)在OSGi之上,但是Oracle Fushion 11G里面卻沒有采用OSGi,請問你認(rèn)為Oracle收購Sun對OSGi會產(chǎn)生什么影響?
BlueDavy:從我2005年接觸OSGi而言,對OSGi的前景一直非常的看好,也許在2005、2006年時OSGi的前景 看似一片迷茫,但進(jìn)入2008、2009后,無論從Java主流應(yīng)用服務(wù)器都基于OSGi來看,還是從Java將從語言級提供對模塊化的支持來 看,OSGi已經(jīng)逐步的得到認(rèn)可并成為事實性標(biāo)準(zhǔn)。
Oracle在很久之前就開始關(guān)注OSGi,并且Oracle也是OSGi聯(lián)盟的成員之一,盡管Oracle Fushion 11G沒有采用OSGi,但我認(rèn)為這并不表示Oracle否定OSGi,或者不愿意采用OSGi,也許Oracle只是認(rèn)為目前采用OSGi會對其原有積 累的技術(shù)產(chǎn)生不小的沖擊,畢竟BEA為了移植到OSGi花了一年多的時間,從另外的角度來看,提供模塊化的支持已經(jīng)成為Java語言發(fā)展的必然,OSGi 是目前僅有的已投入實際商業(yè)產(chǎn)品使用的模塊化規(guī)范,另一方面從OSGi對JSR277產(chǎn)生的影響來看,可見OSGi在Java模塊化規(guī)范方面的領(lǐng)先地位, 因此也許不久后我們就能看到Oracle對OSGi的態(tài)度,相信很大概會是好消息。
InfoQ:應(yīng)用系統(tǒng)開發(fā)引入OSGi之后,又如何應(yīng)用TDD、自動構(gòu)建等敏捷實踐?
BlueDavy:OSGi Service為POJO方式,再加上OSGi和Spring一樣支持方法方式的依賴注入,因此對于依賴關(guān)系不復(fù)雜的OSGi Service的TDD和自動構(gòu)建沒有問題。
對于依賴狀況復(fù)雜的而言,在Spring中多數(shù)仍然會采用配置文件編寫依賴注入關(guān)系,啟動Spring容器,獲取相應(yīng)的bean進(jìn)行測試的方式。在 這種情況下,目前OSGi容器的支持則不是很好,較Spring容器的單元測試而言復(fù)雜很多。一方面是由于OSGi采用的為Bundle部署機制,這就要 求在測試時將所有需要依賴的Bundle部署至OSGi容器中,在目前的情況下這需要通過編寫程序來安裝。這個狀況等到OBR進(jìn)入使用階段后會好很多,原 因在于通 過OBR可以很容易的自動安裝所需依賴的Bundle;另外一方面則是由于OSGi并不直接提供在外部獲取OSGi Service的方法,就像Spring可以通過ApplicationContext來獲取Bean。但是,也不是沒有辦法,如何在外部獲取OSGi Service的方法在《OSGi原理與最佳實踐》一書中有進(jìn)行講解。除了書中講解的方法外,在OSGi R4.2中新提供的Framework launch也將有助于在OSGi容器外部獲取OSGi Service。
鑒于上面的兩個原因,在目前的情況下只能自行實現(xiàn)一個單元測試框架,OSGi China User Group最近會公布一個OSGi單元測試框架以方便大家對OSGi程序進(jìn)行TDD和自動構(gòu)建。