Sky's blog

   
1) Service Listener

    這是OSGI中原生的service依賴管理機制，是最簡單直接的方式，其基本原理非常簡單，標準的注冊/查找：
   
    1. 被依賴的bundle通過BundleContext.registerService()方法注冊服務到系統中
    2. 使用依賴的bundle在start時通過BundleContext的getServiceReferences()/getService()來查找依賴的service
    3. 使用依賴bundle通過BundleContext.addServiceListener()來分別注冊ServiceListener
    4. 在被依賴的bundle/service狀態發生變化時, 使用依賴bundle通過ServiceListener的serviceChanged()得到通知并作出調整。

    在這種方法中，使用依賴的Service必須進行大量的編碼工作來完成對依賴的service的關系管理，需要處理瑣碎細節如各個Service的運行時狀態變化。為了減少工作量，OSGI設計了ServiceTracker來簡化對依賴service的編碼工作，即ServiceTracker將負責處理上述步驟中的2/3/4。

    經過ServiceTracker優化后的Service Listener機制，還是存在一些缺點：
   
    1. 編碼量還是不小，尤其對于依賴較多的場景

    2. Activator 還是太復雜了，盡管已經很努力的試圖簡化
        對于一些業務邏輯簡單的service，如果依賴的service比較多，那么Activator的邏輯和代碼實現遠比service本身的邏輯和實現要復雜，這違背了我們使用框架簡化開發的初衷。

    3. Activator對測試不利
        這個是Activator的復雜性造成的，由于Activator中存在大量的依賴處理邏輯，理所當然的會增加測試的復雜性。

    總結說，Service Listener 機制下，管理service依賴對于開發者來說完全是個重體力活: 很重要，經常要做，容易出現錯誤, 出錯時不容易測試。而且，這些工作都不是service 業務邏輯的組成部分，不能帶來直接收益。簡言之，吃力不討好，一不小心就搬石頭砸自己的腳。

    更重要的，從分工的角度上將，開發人員應該將更多的精力投入與應用的邏輯，而不是OSGI的底層實現機制。因此，從2000之后，就陸續有人開始考慮對此改進。

2) Service binder

    Service binder OSGI針對這個問題的一個嘗試，基本出發點非常明確：希望找到一個通用的方法來簡化OSGI下的動態service依賴管理.

    最初開始這個工作的是兩位大牛，Richard S. Hall和Humberto，大概在2002年的時候開發完成。

    看我們看Service binder是怎么做的，基本步驟為：

    1. 提供一個org.apache.felix.servicebinder.GenericActivator;
        現在bundle的Activator只要簡單的繼承GenericActivator就可以了，所有的代碼實現在GenericActivator提供，減少代碼的目標順利達成。這個可以說足夠簡單到沒有辦法再簡單了。
    2. 通過metadata.xml 來實現service的依賴注入

    3. 具體的service的實現類基本就是一個干凈的POJO了
        當然還是需要實現bind-method/unbind-method 兩個方法，好在這個是通過metadata.xml來做映射，不是另外提供接口定義，因此勉強避開了"侵入"的問題。

    Service binder 機制在減少Activator方面成效顯著，但是引入的metadata.xml文件似乎又帶來了新的問題，xml配置文件的可維護性個人感覺值得懷疑。用過EJB的同學都明白，EJB的部署文件有多令人煩惱。

    當然Service binder 的思路非常的正確：通過引入了自動化的service依賴關系管理，簡化開發，允許開發人員可以集中精力在service的實現上，而不是疲于處理依賴關系管理。

    Service binder的實現似乎并沒有被推廣開，因為很快OSGI就在2004年的OSGI R4規范中引入了Declarative Services。因此Felix也就終止了對Service binder的后續支持。

       
3) Dependency Manager

    繼Service binder之后，Felix又提供了名為Dependency Manager 的service依賴管理方式，對比Service binder，個人感覺這個Dependency Manager 只是針對Service binder的一個改進：將metadata.xml 文件取消，由新引入的DependencyManager來實現metadata.xml 文件的功能。原來在metadata.xml 文件中的配置轉變為在Activator中通過代碼調用DependencyManager來實現.

    Dependency Manager其實現的方式為：

    1. 提供org.apache.felix.dependencymanager.DependencyActivatorBase
        bundle的Activator需要繼承DependencyActivatorBase，并實現DependencyActivatorBase要求的init()/destroy()方法
    2. 在init()中，可以通過DependencyManager 對象來注冊服務，并注明依賴。

    3. 具體的Service類可以是POJO，DependencyManager 通過反射來注入依賴的service。

    Felix 官方給出了一個Dependency Manager的使用示例
http://felix.apache.org/site/dependency-manager-usage.html
    從示例上看，對service的依賴管理已經簡化了許多。

    這里還有一個05年的介紹Dependency Manager的 presentation：
http://felix.apache.org/site/presentations.data/DependencyManagement.pdf

4) Declarative Services

    2004年發布的OSGi的4.0版本中，加入了Declarative Services，據說是從Service Binder進化而來。

    Declarative Services的實現方式和Service Binder的確非常相似：

    1. 同樣是需要一個xml文件來配置
        在 bundle manifest中增加Service-Component 的header
        提供的功能和Service Binder很類似，配置方法也很接近。

    2. 同樣的提供bind/unbind 方法的配置
        對于每個依賴的service，都可以在配置文件中通過指定bind/unbind 方法來處理依賴的狀態變化。

    此外，Declarative Services 提供兩個特殊的lifecircle方法：
        protected void activate(ComponentContext context)
            protected void deactivate(ComponentContext context)
    如果service實現類提供了這兩個方法，則Declarative Services 會自動識別并調用這兩個方法。注意這兩個方法沒有接口定義進行強約束，只是一個約定而已，估計是為了避免OSGI對service的侵入。

    Declarative Services 是OSGI規范的一部分，因此Declarative Services的支持自然是各個OSGI實現都提供的。

    從功能上將，Declarative Services 基本已經不錯了，但是大牛們的腳步并未就此停住。

5) iPOJO

    2005年，Richard 開始考慮使用字節碼生成技術來進行創建組合服務的改進，另外一個牛人Peter Kriens也同樣的工作并實現了一個原型。
    2006年，Clement Escoffier 和 Richard 開始開發iPOJO，合并了Peter Kriens之前的工作內容，這就是iPOJO的由來。

    對于iPOJO的定義，Felix的iPOJO頁面有如下說明：iPOJO是一個服務器組件運行時，目標在于簡化OSGI應用開發。原生支持所有的OSGI活力。給予POJO的概念，應用邏輯開發簡單。非功能性的屬性在運行時被注入到組件中。

    同樣看看Felix對iPOJO優點的說明：
   
    1. 組件被作為POJO開發，不需要其他任何東西
    2. 組件模塊是可擴展的，因此可以自由的適應需要
    3. 標準組件模型管理service 供應和service 依賴，所以可以要求其他任何OSGI服務來創建組合服務，
    4. iPOJO管理組件實例的生命周期和環境動態
    5. iPOJO提供一個強力的組合系統來創建高度動態的應用
    6. iPOJO支持注解，xml或者基于Java的API來定義組件

    可以看到iPOJO的功能遠比之前的幾個解決方案要強大，除了支持Declarative Services已經實現的功能外，還提供了強大的注解支持，而且實現了組合系統，這些對于開發大型的復雜應用時非常有用的。

    Richard 在他的presentation談到iPOJO 的設計思路：

    1. Make things simple / 讓事情簡單
    2. Follow POJO philosophy / 遵循POJO的哲學
    3. Employ byte code manipulation techniques / 使用字節碼操縱技術
    4. Be as lazy as possible / 盡可能的偷懶

    目前的iPOJO還在繼續發展中，最新的一個版本iPOJO 1.6.0在2010-04-25發布。