OSGI 學習筆記之一 初識

OSGI - (Open Service Gateway Initiative) OSGI 定義了一個動態模型系統，協助你更好地管理你的代碼結構，管理代碼生命週期，和代碼模組之間的相互合作（鬆散的）。

模組性-代碼被分為清晰的功能塊，功能塊之間有清晰的介面互動。

大家自然會想到物件導向已經具有模組的概念了。但是還是有局限性：

1.低層級的可見度控制。只能對方法，類，包進行控制。但這些都是代碼層級的，不是業務層級的。

有時候將介面和實現定義在不同的包裡邊，這樣比較符合代碼模組邏輯，但是大家一定有體會，實現的類一般回多暴漏一些方法，來進行一個配置等介面沒有要求的方法。

這些多餘的方法並不受介面的約束。第三方使用者可能會使用，就會有變更不一致的問題。

還有一種可能就是定義和實現在一個包裡，這樣可以只對外暴漏介面規定的方法，但是導致代碼結構混亂。

然後我們在另一個package

2.易於出錯的class path

class path在一定程度上阻礙了java的模組化。因為class path對jar的版本沒有概念，它只返回它找到的第一個版本。

3.缺乏部署和管理的支援

OSGI 的架構：

OSGI service platform包括 OSGI framework 和 standard services兩個部分。framework是這個系統的運行時環境，提供OSGI的準系統，而standard services提供一些可重用的通用功能比如Logging和Preferences。

OSGI標準包括三個層，從下到上依次為Module，lifecycle，service

Module 層，封裝和共用代碼

lifecycle層，運行時的module管理和提供對OGSI底層服務調用的介面。

service層，提供容器來管理module，並且協調module之間的互動。

下邊具體說一下每個層：

MODULE 層

這一層定義了OSGI的模組的概念，叫做bundle，這是幾個jar和一個額外的metadata。一個bundle包含了你的class檔案和他們需要的資源。bundle比普通的jar更強大，因為你可以顯式的指定bundle裡包含的哪個package是可以對外可見的。也可以顯示的指定哪個外部的package是這個bundle需要的。這種顯示的定義一個bundle的import和export的package，這樣OSGI framwork可以幫我們來檢查他們的一致性。

LIFECYCLE層

lifecycle層定義了bundle是如何動態被安裝和管理的。

對外而言lifecycle層提供了讓你可以動態安裝卸載，更新，啟動，停止的功能。

對內而言lifecycle層讓bundle可以擷取執行時的上下文，這樣bundle可以和OSGI framework去互動，

SERVICE 層

 Service層是介面和實現分離的，service可以隨時註冊和取消。這樣提高了程式的靈活性。

說了這麼多，我們到底該怎麼用OSGI來編寫我們自己的程式呢？

1.把你的程式設計成介面-實現的結構。

2.實現這些介面，和這些介面的使用者。

3.把服務提供者和客戶封裝到不同的jar裡，給每個jar加上合適的metadata。

4.開啟OSGI framework。

5.安裝和啟動你的jar。