OSGI

#1、模塊化、服務化（SOA） ##模塊化

模塊化是個通常概念，這一律念也適用於軟件開發，可讓軟件按模塊單獨開發，各模塊一般都用一個標準化的接口來進行通訊。實際上，除了規模大小有區別外，面嚮對象語言中對象之間的關注點分離與模塊化的概念基本一致。一般，把系統劃分外多個模塊有助於將耦合減至最低，讓代碼維護更加簡單。

Java語言並非按照模塊化思想設計的（除了package，按照Java語言規範introduction一 節的介紹，package相似於Modula-3模塊），可是在Java社區依然有不少實際存在的模塊。任何一個Java類庫實際上都是一個模塊，不管其 是Log4J、Hibernate仍是Tomcat。一般，開源和非開源的應用都會依賴於一個或多個外部類庫，而這種依賴關係又有可能傳遞到其餘類庫上。

構建一個模塊化系統其實是把系統劃分紅（有可能）可重用模塊的過程，並使模塊間耦合最小化。同時，其也是一個減小模塊需求耦合的過程：例如，Eclipse IDE許多plugin對GUI和非GUI組件（如jdt.ui和jdt.core）的依賴是分開的，這樣就能夠在IDE環境以外使用這些非GUI模塊（headless builds、分析及錯誤檢查等等）。

模塊化也可給項目管理帶來方便。若是一個模塊公佈的API可供其餘模塊預先使用，那麼各個模塊就能夠由不一樣的團隊分別開發。這在大型項目中一定會發生，各個項目子團隊能夠負責不一樣模塊的交付。

將一個應用程序模塊化，能夠幫助識別正在使用依賴類庫的哪一個版本，以便協調大型項目中的類庫依賴。

Java有一個很是好的底層特性，叫作ClassLoader， 它可讓運行時路徑分得更開。一般狀況下，全部類都是由系統ClassLoader裝載的；但是有些系統使用不一樣的ClassLoader將其運行時空間 進行了劃分。Tomacat(或者其餘Servlet引擎)就是一個很好的例子，每一個Web應用都有一個ClassLoader。這樣Web應用就沒必要去 管（不管有意與否）在同一JVM中其餘Web應用所定義的類。

Java領域存在許多模塊化系統和plugin體系。IDE是名氣最大的，IntelliJ、NetBeans和Eclipse都提供了其本身的 plugin系統做爲其定製途徑。並且，構建系統（Ant、Maven）甚至終端用戶應用（Lotus Notes、Mac AppleScript應用）都有可以擴展應用或系統核心功能的概念。

OSGi是Java領域裏無可辯駁的最成熟的模塊系統，它與Java幾乎是如影相隨，最先出現於JSR 8，可是最新規範是JSR 291。 OSGi在JAR的MANIFEST.MF文件中定義了額外的元數據，用來指明每一個包所要求的依賴。這就讓模塊可以（在運行時）檢查其依賴是否知足要求， 另外，可讓每一個模塊有本身的私有 classpath（由於每一個模塊都有一個ClassLoader）。這可讓dependency hell儘早被發現，可是不能徹底避免。和JDBC同樣，OSGi也是規範（目前是4.2版），有多個開源（及商業）實現。由於模塊不須要依賴任何OSGi的特定代碼，許多開源類庫如今都將其元信息嵌入到manifest中，以便OSGi運行時使用。有些程序包沒有這麼作，也能夠用bnd這樣的工具，它能夠處理一個已有的JAR文件併爲其產生合適的默認元信息。自2004年Eclipse 3.0 從專有plugin系統切換到OSGi以後，許多其餘專有內核系統（JBoss、WebSphere、Weblogic）也都隨之將其運行時轉向基於OSGi內核。

因爲編譯時和運行時路徑可能不一樣，有可能會產生不一致的類庫需求，從而致使依賴地獄。然 而，plugin API容許裝載多種代碼，但其必須遵循宿主的依賴處理規則，這又增長了發生不一致的可能性。爲了防止這種狀況出現，像OSGi這樣的運行時模塊化系統能夠 在決定應用是否能被正確啓動以前就校驗各項要求，而不是在運行時不知不覺發生錯誤。

##服務化（SOA）

服務是業務流程中的可重複任務。業務流程 由一組任務組成，開發人員聲明那些任務是服務。業務流程是這些服務的組合。面向服務是將業務做爲一組相聯繫的服務集成在一塊兒的方式。

SOA 是一種適合於企業 IT 體系結構的體系結構風格，利用了面向服務的原則來實現業務和支持業務的信息系統之間更爲緊密的關係。

SOA 治理框架和平臺應包括：
治理：方法和平臺；

方法：產生一個無縫地織入 SOA 生命週期各個階段的框架，並具備檢查點、檢查表、強制策略和質量門控，確保 SOA 以更低的成本產生業務敏捷性和靈活性。

平臺：治理框架經過軟件或硬件平臺實現自動化；

能力：集中的註冊中心和存儲庫，以查找和發佈與服務相關的構件和元數據。

目的：
1）查找正確的受權服務。
2）避免重複工做。
3）促進重用。
4）肯定服務在 SOA 生命週期中的當前狀態。
5）爲服務訂閱者提供可見性。
6）肯定相關服務和更改某個服務所形成的影響。
7）傳達對服務所作的更改。
8）用於聯繫和強制應用於某個服務的策略的機制。策略經過使用治理框架來定義。
9）具備生命週期感知性的可自定義系統，該系統在生命週期中發生階段更改時觸發驗證，以便可以自動化逐個階段的治理驗證。
10）在理想的狀況下，註冊中心應該針對 SOA 運行時進行優化，以便可以在運行時期間，使用存儲在註冊中心的元數據來經過動態路由充實內容。

#2、OSGI

Open  Services  Gateway iniPaPve—— 開放服務網關協議 ，是由OSGi  Allinance制定的Java動態模塊化規範。

OSGi規範和Servlet規範及EJB規範相似，該規範定義了兩種對象，一是容器對外提供的服務對象，另外一個是容器和您的應用程序之間必須遵照的契約，其中，服務對象是容器要實現的，經過這些容器，把應用程序劈分爲多個模塊單元，開發者能夠管理這些模塊單元之間的交叉依賴關係。OSGi標準規範了一系列經常使用的功能集合，例如：生命週期管理、安全日誌、配置文件、事件隊列、Web開發、JPA&JDBC等，大部分支持OSGi標準的框架都提供了這些服務，這樣一方面規範了項目的代碼結構，一方面節約了項目開發的時間。

OSGi框架提供了一個通用安全可管理的Java框架，可以支持可擴展可下載的應用（即bundles）的部署。OSGi框架是OSGi技術最基礎也是最核心的部分。OSGi框架分爲安全層、模塊層、生命週期層、服務層。

安全層： 基於Java2的安全機制增長了一些限制，而且彌補了Java標準的一些不足。

模塊層： 定義一個模塊化Java模型-Bundle，對Java部署模式的一些缺點進行了改進，並對bundle 之間包的共享有嚴格的規定。模塊層獨立於生命週期層和服務層，使用時能夠不須要生命週期層和服務層。生命週期層提供了對模塊層的bundle 進行管理的API，而服務層提供了bundle之間的通訊模型。

生命週期層： 爲bundle 提供了生命週期管理API，爲bundle提供了一個運行時模型，定義了一個bundle 如何啓動、中止、安裝和卸載，生命週期層也提供全面的事件API，容許bundle去控制和操做服務平臺。

服務層： 爲bundle開發者提供了一個動態、簡明且而且統一的編程模型，經過解耦服務標準（即Java接口）和它的實現，可以簡化服務bundle的開發和部署。這個模型容許bundle 開發者只使用他們本身的接口規範來綁定服務。框架經過使用服務層，爲系統提供了一種擴展機制，成爲hooks。

OSGI框架特色：

• 模塊化地開發
• 模塊化地部署
• 動態管理模塊

Bundle：
bundle是以jar包形式存在的一個模塊化物理單元，裏面包含了代碼，資源文件和元數據（metadata），而且jar包的物理邊界也同時是運行時邏輯模塊的封裝邊界。

一個更爲直觀的描述：在標準的jar包的manifest文件中添加一些bundle的模塊化特徵metadata，這個jar包就變成了一個bundle，bundle和普通jar包最大的區別就在於元數據。

• 在OSGi中Bundle不是一個虛擬的概念，而是一個實體；
• Bundle是一個普通的jar，只是其META-­‐INF中的manifest.mf中描述了一些標準的模塊的信息；
• OSGi的模塊劃分在原理上依賴於類加載機制；
• OSGi容器爲每一個bundle都建立了不一樣的ClassLoader；

Bundle交互方式：

• 以package 方式交互 ；經過Export-­‐Package對外提供packages，過Import-­‐Package使用其餘模塊的packages。
• 以服務的方式交互 ；底層的服務註冊和發現機制；

Bundle相關操做：

• install—— 安裝一個 bundle
• start —— 啓動 bundle
• stop—— 中止 bundle  
• uninstall—— 卸載 bundle
• update—— 更新

優點：

• 複雜性的下降：基於OSGi的組件模型bundle可以隱藏內部實現，bundle基於服務進行交互。
• 複用：不少第三方的組件能夠以bundle的形式進行復用。
• 簡單：核心的API總過包括不超過30個類和接口
• 小巧：OSGi R4框架的實現僅須要300KB的JAR file就足夠。在系統中引入OSGi幾乎沒有什麼開銷。
• 非侵入式：服務能夠以POJO的形式實現，不須要關注特定的接口。
• 切合真實運行環境：OSGi框架是動態的，bundle可以進行即時的更新，服務能夠根據須要動態增長或者刪除。
• 易於部署：OSGi定義了組件是如何安裝和管理的，標準化的管理API使得OSGi可以和現有和未來的各類系統有機的集成。
• 動態更新：這是OSGi被最常常提起的一個特性，即所謂的「熱插拔」特性，bundle可以動態的安裝、啓動、中止、更新和卸載，而整個系統無需重啓。
• 適配性：這主要得益於OSGi提供的服務機制、組件能夠動態的註冊、獲取和監聽服務，使得系統可以在OSGi環境調整本身的功能。
• 透明：提供了管理API來訪問內部狀態，所以一般無需去查看日誌，可以經過命令行進行調試。透明：提供了管理API來訪問內部狀態，所以一般無需去查看日誌，可以經過命令行進行調試。
• 版本化：bundle能夠版本化，多版本可以共存而不會影響系統功能，解決了JAR hell的問題。（這在開發時也提供了很大的幫助）。
• 快速：這得益於OSGi的類加載機制，和JAR包的線性加載不一樣，bundle委託式的類加載機制，使得類的加載無需進行搜索，這又能有效的加快系統的啓動速度。
• 懶加載：OSGi技術採用了不少懶加載機制。好比服務能夠被註冊，可是直到被使用時才建立。