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