OSGI框架的功能和设计思
生活随笔
收集整理的這篇文章主要介紹了
OSGI框架的功能和设计思
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
支持模塊化的動態(tài)部署?
基于 OSGi 而構建的系統(tǒng)可以以模塊化的方式(例如 jar 文件等)動態(tài)地部署至框架中,從而增加、擴展或改變系統(tǒng)的功能。 要以模塊化的方式部署到 OSGi 中,必須遵循 OSGi 的規(guī)范要求,那就是將工程創(chuàng)建為符合規(guī)范的 Bundle? ?工程(就是 Eclipse? ?中的插件工程) ,或者使用工具將工程打包成符合規(guī)范的 Jar 文件。
支持模塊化的封裝和交互?
OSGi 支持模塊化的部署,因此可以將系統(tǒng)按照模塊或其他方式劃分為不同的 Java 工程,這和以往做 Java 系統(tǒng)時邏輯上的模塊化是有很大不同的,這樣做就使得模塊從物理級別上隔離了,也就不可能從這個模塊直接調用另外模塊的接口或類了。根據 OSGi? ?規(guī)范,每個工程可通過聲明Export-Package? ?對外提供訪問此工程中的類和接口, 也可通過將要對外提供的功能聲明為 OSGi? ?的服務實現面向接口、面向服務式的設計。?
基于 OSGi 的 Event 服務也是實現模塊交互的一種可選方法,模塊對外發(fā)布事件,訂閱了此事件的模塊就會相應地接收到消息,從而做出處理。?
支持模塊的動態(tài)配置?
OSGi? ?通過提供 Configuration Admin 服務來實現模塊的動態(tài)配置和統(tǒng)一管理,基于此服務各模塊的配置可在運行期間進行增加、修改和刪除,所有對于模塊配置的管理統(tǒng)一調用 Configuration Admin 服務接口來實現。?
支持模塊的動態(tài)擴展?
基于 OSGi? ?提供的面向服務的組件模型的設計方法,以及 OSGi? ?實現框架提供的擴展點方法可實現模塊的動態(tài)擴展。那么,要使用 OSGi? ?框架提供的這些基本功能,在設計系統(tǒng)時就要遵循 OSGi? ?框架的設計思想。
模塊化的設計?
模塊化的設計已經是大家在做系統(tǒng)設計時遵循的基本設計原則,但只有基于 OSGi 來做模塊化的時候才會真正體驗到何謂模塊化,因為 OSGi 中的模塊化是物理隔離的,而不基于 OSGi 的話很難做到物理隔離方式的模塊化實現,也就很難使系統(tǒng)真正做到模塊化,通常切換到基于 OSGi 后就會發(fā)現以前的模塊化設計做得還是很不足。
?
基于 OSGi 進行模塊化設計和傳統(tǒng)的模塊設計并沒有多大的差別,均為定義模塊的范圍、模塊對外提供的服務和所依賴的服務,相信大家在這點上很容易適應,在 OSGi 中只是更為規(guī)范,更為遵循面向服務的設計思想。?
在 OSGi 中模塊由一個或多個 Bundle 構成,模塊之間的交互通過 Import-Package、Export-Package及 OSGi Service的方式實現。?
面向服務的組件模型的設計?
面向服務的組件模型(Service-Oriented Component Model)的設計思想是 OSGi 的核心設計思想, OSGi 推崇系統(tǒng)采用 Bundle 的方式來劃分, Bundle 由多個 Component (組件) 來實現, Component通過對外提供服務接口和引用其他 Bundle 的服務接口來實現 Component 間的交互。?
從這個核心的設計思想上可以看出,基于 OSGi? ?實現的系統(tǒng)自然就是符合 SOA? ?體系架構的。在 OSGi 中 Component 以 POJO 的方式編寫,通過 DI 的方式注入其所引用的服務,以一個標準格式的 XML 描述 Component 引用服務的方式、對外提供的服務及服務的屬性。?
動態(tài)化的設計
?
動態(tài)化的設計是指系統(tǒng)中所有的模塊均須支持動態(tài)的插拔和修改, 系統(tǒng)的模塊要遵循對具體實現的零依賴和配置的統(tǒng)一維護(基于 Configuration Admin 服務) ,在設計時要記住的是所依賴的 OSGi服務或 Bundle 都是有可能動態(tài)卸載或安裝的。對于模塊的動態(tài)插拔和修改,OSGi? ?框架本身提供了支持,模塊可通過 OSGi? ?的 Console(命令行 Console、Web console? ?等)安裝、更新、卸載、啟動、停止相應的 Bundle。?
為保持系統(tǒng)的動態(tài)性,在設計時要遵循的原則是不要靜態(tài)化地依賴任何服務,避免服務不可用時
造成系統(tǒng)的崩潰,從而保證系統(tǒng)的“即插即用,即刪即無” 。?
可擴展的設計?
OSGi? ?在設計時提倡采用可擴展式的設計,即可通過系統(tǒng)中預設的擴展點來擴充系統(tǒng)的功能,有兩種方式來實現。
引用服務的方式,通過在組件中允許引用服務接口的多個實現來實現組件功能的不斷擴展,例如 A 組件的作用為顯示菜單,它通過引用菜單服務接口來獲取系統(tǒng)中所有的菜單服務,此時系統(tǒng)中有兩個實現此服務的組件,分別為文件菜單組件和編輯菜單組件,那么 A 組件相應地就會顯示出文件菜單和編輯菜單,而當從系統(tǒng)中刪除編輯菜單的組件時,A 組件顯示的菜單就只剩文件菜單了,若此時再部署一個實現菜單服務接口的視圖菜單組件模塊到系統(tǒng)中,那么顯示出來的菜單則會為文件、視圖。
定義擴展點的方式,按照 Eclipse? ?推薦的擴展點插件的標準格式定義 Bundle? ?中的擴展點,其他要擴展的 Bundle? ?可通過實現相應的擴展點來擴展該 Bundle 的功能。? ?系統(tǒng)對于可擴展性的需求很大程度會影響到 Bundle? ?的劃分和設計,這要結合實際情況來進行設計。
基于 OSGi 而構建的系統(tǒng)可以以模塊化的方式(例如 jar 文件等)動態(tài)地部署至框架中,從而增加、擴展或改變系統(tǒng)的功能。 要以模塊化的方式部署到 OSGi 中,必須遵循 OSGi 的規(guī)范要求,那就是將工程創(chuàng)建為符合規(guī)范的 Bundle? ?工程(就是 Eclipse? ?中的插件工程) ,或者使用工具將工程打包成符合規(guī)范的 Jar 文件。
支持模塊化的封裝和交互?
OSGi 支持模塊化的部署,因此可以將系統(tǒng)按照模塊或其他方式劃分為不同的 Java 工程,這和以往做 Java 系統(tǒng)時邏輯上的模塊化是有很大不同的,這樣做就使得模塊從物理級別上隔離了,也就不可能從這個模塊直接調用另外模塊的接口或類了。根據 OSGi? ?規(guī)范,每個工程可通過聲明Export-Package? ?對外提供訪問此工程中的類和接口, 也可通過將要對外提供的功能聲明為 OSGi? ?的服務實現面向接口、面向服務式的設計。?
基于 OSGi 的 Event 服務也是實現模塊交互的一種可選方法,模塊對外發(fā)布事件,訂閱了此事件的模塊就會相應地接收到消息,從而做出處理。?
支持模塊的動態(tài)配置?
OSGi? ?通過提供 Configuration Admin 服務來實現模塊的動態(tài)配置和統(tǒng)一管理,基于此服務各模塊的配置可在運行期間進行增加、修改和刪除,所有對于模塊配置的管理統(tǒng)一調用 Configuration Admin 服務接口來實現。?
支持模塊的動態(tài)擴展?
基于 OSGi? ?提供的面向服務的組件模型的設計方法,以及 OSGi? ?實現框架提供的擴展點方法可實現模塊的動態(tài)擴展。那么,要使用 OSGi? ?框架提供的這些基本功能,在設計系統(tǒng)時就要遵循 OSGi? ?框架的設計思想。
模塊化的設計?
模塊化的設計已經是大家在做系統(tǒng)設計時遵循的基本設計原則,但只有基于 OSGi 來做模塊化的時候才會真正體驗到何謂模塊化,因為 OSGi 中的模塊化是物理隔離的,而不基于 OSGi 的話很難做到物理隔離方式的模塊化實現,也就很難使系統(tǒng)真正做到模塊化,通常切換到基于 OSGi 后就會發(fā)現以前的模塊化設計做得還是很不足。
?
基于 OSGi 進行模塊化設計和傳統(tǒng)的模塊設計并沒有多大的差別,均為定義模塊的范圍、模塊對外提供的服務和所依賴的服務,相信大家在這點上很容易適應,在 OSGi 中只是更為規(guī)范,更為遵循面向服務的設計思想。?
在 OSGi 中模塊由一個或多個 Bundle 構成,模塊之間的交互通過 Import-Package、Export-Package及 OSGi Service的方式實現。?
面向服務的組件模型的設計?
面向服務的組件模型(Service-Oriented Component Model)的設計思想是 OSGi 的核心設計思想, OSGi 推崇系統(tǒng)采用 Bundle 的方式來劃分, Bundle 由多個 Component (組件) 來實現, Component通過對外提供服務接口和引用其他 Bundle 的服務接口來實現 Component 間的交互。?
從這個核心的設計思想上可以看出,基于 OSGi? ?實現的系統(tǒng)自然就是符合 SOA? ?體系架構的。在 OSGi 中 Component 以 POJO 的方式編寫,通過 DI 的方式注入其所引用的服務,以一個標準格式的 XML 描述 Component 引用服務的方式、對外提供的服務及服務的屬性。?
動態(tài)化的設計
?
動態(tài)化的設計是指系統(tǒng)中所有的模塊均須支持動態(tài)的插拔和修改, 系統(tǒng)的模塊要遵循對具體實現的零依賴和配置的統(tǒng)一維護(基于 Configuration Admin 服務) ,在設計時要記住的是所依賴的 OSGi服務或 Bundle 都是有可能動態(tài)卸載或安裝的。對于模塊的動態(tài)插拔和修改,OSGi? ?框架本身提供了支持,模塊可通過 OSGi? ?的 Console(命令行 Console、Web console? ?等)安裝、更新、卸載、啟動、停止相應的 Bundle。?
為保持系統(tǒng)的動態(tài)性,在設計時要遵循的原則是不要靜態(tài)化地依賴任何服務,避免服務不可用時
造成系統(tǒng)的崩潰,從而保證系統(tǒng)的“即插即用,即刪即無” 。?
可擴展的設計?
OSGi? ?在設計時提倡采用可擴展式的設計,即可通過系統(tǒng)中預設的擴展點來擴充系統(tǒng)的功能,有兩種方式來實現。
引用服務的方式,通過在組件中允許引用服務接口的多個實現來實現組件功能的不斷擴展,例如 A 組件的作用為顯示菜單,它通過引用菜單服務接口來獲取系統(tǒng)中所有的菜單服務,此時系統(tǒng)中有兩個實現此服務的組件,分別為文件菜單組件和編輯菜單組件,那么 A 組件相應地就會顯示出文件菜單和編輯菜單,而當從系統(tǒng)中刪除編輯菜單的組件時,A 組件顯示的菜單就只剩文件菜單了,若此時再部署一個實現菜單服務接口的視圖菜單組件模塊到系統(tǒng)中,那么顯示出來的菜單則會為文件、視圖。
定義擴展點的方式,按照 Eclipse? ?推薦的擴展點插件的標準格式定義 Bundle? ?中的擴展點,其他要擴展的 Bundle? ?可通過實現相應的擴展點來擴展該 Bundle 的功能。? ?系統(tǒng)對于可擴展性的需求很大程度會影響到 Bundle? ?的劃分和設計,這要結合實際情況來進行設計。
總結
以上是生活随笔為你收集整理的OSGI框架的功能和设计思的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: C# 命令行编译器详解
- 下一篇: android 插件化 模块化开发(ap