天天看點

《OSGi官方文檔》使用OSGi的好處

開發者:

對于今天的大型分布式系統osgi提供了一個和小型、嵌入式應用一樣的子產品化的架構來減少系統複雜性。從内部和現成的子產品來建構系統可以顯著的減少開發和維護的成本。osgi程式設計模型就是實作元件為基礎的系統。

業務:

osgi的子產品化和動态子產品降低在網絡工作環境下的多裝置內建的操作成本,減少應用的開發、維護和遠端服務管理的成本。osgi 如此成功的關鍵原因在于它提供了一個非常成熟的元件系統,他可以工作在數量驚人的環境中。osgi 的元件系統實際已經被用來建構像ides(eclipse)、應用伺服器(glassfish, ibm websphere, oracle/bea weblogic, jonas, jboss)、應用架構(spring, guice)、工業自動化、家庭網關、手機等高複雜應用。

是以,osgi的元件系統究竟能給你帶來什麼好處呢?

1、減少複雜性

利用osgi技術進行開發意味着軟體包的開發:osgi元件、軟體包和子產品。它們隐藏它們的内部實作,通過已經定義好的服務來和其他包進行通信,隐藏内部實作意味這以後可以自由更改實作。這樣不僅減少了bug的數量,而且使得包的開發更為簡單,因為可以隻需要實作已經定義好的一定數量的功能接口即可。

2、複用

osgi的元件子產品使得它在應用中可以非常簡單的使用其他第三方元件。已經有很多的開源項目都是通過osgi來釋出他們的jar包,而且商業庫也開始使用現成的包。

3、現實情況

osgi是一個動态架構。他可以更新正在運作的子產品和服務。那些曾經的java開發者認為這個特性是有問題的,而且并沒有看到這個特性的好處。然而,事實表明,真實的世界是高動态化的,并且有很多錯綜的服務以完美的比對真實世界的場景。例如,在網絡環境中模拟一個裝置的服務,如果該裝置被發現,服務就去注冊,如果裝置掉線,服務就取消注冊。現實世界中有很多場景都和動态服務模型相比對。應用是以在他們所屬的領域裡可以強有力的複用注冊中心(注冊,擷取,具有展現力的過濾語言清單,等待服務的出現或消失)。這不僅可以儲存正在實作的代碼,而且還對全局提供了可見性、調試工具和更多的功能而不是需要實作過時的問題,在這樣的動态環境下寫代碼聽起來似乎是個噩夢,但是幸運的是,它有主要的支援類和架構,如果不是這樣,那将非常痛苦。

4、開發簡單

osgi 技術并不是元件化的一個标準,它也指定了元件是如果安裝和管理的,這個api已經被很多挺管理代理的子產品所使用。這種管理代理可以和指令行已經簡單,例如tr-6g管理協定驅動,oma dm協定驅動,amazon ec2的計算接口、ibm tivoli 的管理系統等。标準化管理api很容易在現有和未來的系統中內建osgi技術。

5、動态更新

osgi 元件子產品是一個動态的子產品,子產品可以在不需要停止整個系統的情況下被安裝、啟動、停止、更新和解除安裝。許多的java 開發者不相信它的這種做法是可靠的,是以自覺的在生産環境下不這樣使用。然而,使用這種方法一段時間後,許多人開始意識到它确實可以工作和減少部署的重要性。

6、自适應

osgi的元件模型設計原則是允許元件的混合和比對。這需要指定元件的依賴性,也需要元件在一個并不總是可用的可選的依賴環境中。osgi的服務注冊是一個可以注冊、擷取和偵聽服務的動态注冊的軟體包。這種動态服務子產品允許軟體包找出系統上可用的功能,并調整它們能提供的功能,這些可以使得代碼更為靈活和更好的适應變化。

7、透明性

軟體包和服務在osgi環境中是最進階的。管理api不但提供了對軟體包内部狀态的通路而且也也提供了如何去和其他包做對接。例如,大多數架構提供了一個指令行的視窗來展示内部狀态;也有部分應用為了調試一個确切的問題而被停止,或者引入軟體診斷包。osgi 的應用可以在一個指令行視窗下進行調試,而不用盯着百萬行的日志輸出和很長的重新開機時間。

8、版本控制

osgi技術解決了jar的痛苦。jar 包帶來的問題是,a庫依賴的版本=2的b庫,但是c庫又依賴版本=3的b庫,在标準的java中,你是非常不幸的。在osgi的環境中,所有的軟體包都被非常仔細的設定版本,隻有這些包在相同的類空間下它們才會被連接配接在一起協同工作。這種方式就允許軟體包a和軟體包c都和它們各自的庫一起工作.雖然不建議在這種版本的問題下來設計系統,但是在某些情況下它依然是非常有用的。

9、簡單

使用osgi是非常的簡單的,它不但依賴管理、配置和動态性都非常強大,而且osgi的代碼也和傳統的java代碼完全相似。有很多簡單的注解可以讓程式在用運作期間知道一個特殊的類是如何使用動态性、配置和對其他服務的依賴。預設情況向是完全是以了動态性和osgi的其他的特性,簡單的子產品會逐漸使用一些進階特性。

10、體積小

第4版osgi架構的jar檔案大約隻有300kb的大小。隻包含osgi 就實作了很多功能的應用來說已經非常的小了.osgi 可以運作在很多種類的裝置上:從很小、小裝置再到大型機器,它僅僅需要一個最低配的java虛拟機來運作。

11、快速

osgi的一個主要功能就是從軟體包裡加載類。在傳統的java程式中,jar包是清晰可見的,并線性的排列。搜尋一個類需要周遊整個清單(通常時間會很久)。相比之下,osgi軟體包之間的預依賴可以準确的知道是哪個軟體包提供的類,通過減少搜尋是啟動速度提高的一個重要因素。

12、懶加載

懶加載是軟體中一個很好的點,osgi技術有很多的機制來保證隻有當類真正需要的時候才開始加載他們。例如,軟體包以餓漢的方式啟動,但是當其他的包在使用它們的時候它們也能以配置的方式啟動。當服務被使用的時候它們才會被注冊。為了允許各種懶加載的場景,以使得它們可以節省運作時的巨大成本,osgi的規範已經被優化過很多次了。

13、安全

java的底層有一個非常強大的細粒度的安全模型,但是它在實踐中卻非常難配置,結果就是大多數安全的java應用都以二進制的選項運作:其喪失安全性或者安全性能有限。osgi的安全模型利用細粒度的安全模型,但是通過它提高了可用性

通過軟體包的開發人員以一種簡單的審計方式來指定安全請求的細節,同時環境的操作者也對其完全負責來提高其可用性(以及加強原始模型)。

14、非獨占性

許多應用架構運作時需要獨占整個vm,且每個虛拟機上僅僅允許允許一個應用的執行個體。這時就展現出了osgi規範的靈活性,它甚至可以在j2ee的應用伺服器中運作。很多開發者都想運作osgi,但是他們的公司并不允許他們部署通常的jar包。是以,這些開發者可以将某個osgi架構包括在war檔案中,并将軟體包從檔案系統或通過網絡裝載到應用伺服器中來運作。osgi非常的靈活,這使得一個應用伺服器上就可以容易地作為多個osgi架構的宿主。

15、非侵入

在一個osgi的環境中,不同軟體包均有自己的環境設定,不同應用實際是都可以使用虛拟機提供的所有設施,osgi對此并無任何限制。osgi的最佳實踐就是編寫pojo(plain old java objects),并且由于這個原因,osgi服務并不需要任何特殊的接口,甚至一個java的string對象也可以充當一個osgi服務。這個政策使得應用程式的代碼可以更容易地移植到其他環境。

16、可以四處運作

當然,這裡有所依賴。java的最初目的是能夠四處運作。顯然,由于不同環境中的java虛拟機(java vm)實作存在差異,在任何地方都能運作所有的代碼并不可能。例如,手機中的虛拟機就不太可能與ibm大型機中運作的銀行應用支援相同的類庫(libraries)。要具備四處運作的能力,必須考慮兩個問題。一是osgi api應該使用能在所有環境中都有效的類;二是如果bundle包含了在某個執行環境中無效的代碼,那麼這個bundle就不能在該環境中啟動。在osgi規範中,這兩個問題都得到了解決。

17、廣泛使用

雖然最初起始于嵌入式家用自動化市場,但從1998年起,osgi規範已被擴充并應用于多個業務領域:汽車、移動技術、工業自動化、網關/路由、專用小交換機、固定電話等等。從2003年起,廣泛流行的eclipse統一開發環境開始采用osgi技術運作,并提供擴充,以支援bundle開發。最近幾年,企業開發者也開始采用osgi規範。不僅eclipse的開發者發現了osgi技術的威力,并且由于spring framework為osgi創造了一種特殊的擴充,使得這種技術進一步得到廣泛流行。現在,你可以在ibm websphere、springsource dm server、oracle(以前的bea) weblogic、sun的glashfish和redhat的jboss中都能找到osgi技術的蹤影。

18、核心公司支援

在osgi的成員中,集中了大量不同領域的大型計算機公司,包括oracle、ibm、samsung、nokia、progress、motorola、ntt、siemens、hitachi、deutsche telekom、redhat和ericsson等

osgi 規範開始于1988年,它開始被寄予家庭自動化的市場,嘗試解決怎樣建構獨立應用之外的元件。在過去的十年中,軟體由于開源項目的爆發而發生了巨大的變化。十年以前,一個應用是由許多寫代碼的人在一起開發的。而今天,大多數的軟體是有大量的開源建構組成的,而它們有嘗嘗是一些不在一起工作的人設計的,這和osgi所有解決的問題有點相像。許多開源工程更關注實際中的問題,減少對底層軟體的問題的擔憂,也為了使它在其他工程使用更簡單,是以它們也采用了osgi的規範,而且這是大勢所趨。

如果你是在java開發軟體,osgi技術應該是一個合乎邏輯的下一步,因為它解決了許多你可能不知道可以解決的問題。 osgi技術的優勢如此之多,如果你使用java,那麼osgi 應該在你的工具箱中。