2011-12-23 73 views
3

我對OSGi以及與此相關的一切都很陌生。Java/OSGi將現有應用程序修改爲OSGi服務

跳轉到問題:我有一個服務器類來保存監聽器列表,監聽器可以通過一個方法註冊它們(register(this)),該方法將監聽器放入上述列表中(所有監聽器都實現服務器類當然偵聽器接口):

public void register(ServerListener listener) { 
    if(theListeners == null) 
     theListeners = new ArrayList<ServerListener>(); 

    theListeners.add(listener); 
} 

這就是ServerListener接口:

public interface ServerListener { 
    public void update(JsonObject data); 
} 

現在,服務器級通過提供從時新數據的聽衆時間方法。

public void updateListeners() { 
    new Thread() { 
     public void run() { 
      for(ServerListener l : theListeners) { 
       l.update(jsonObject); 
      } 
     } 
    }.start(); 
} 

現在,我想將服務器類修改爲OSGi框架(Knopflerfish)中的服務包。我對此一點都不熟悉。我想嘗試只是爲了好玩,但現在我做這件事的方式是行不通的,聽衆實際上並不知道他們應該實現ServerListener界面。所以服務器不能通過接口註冊它們。

事情是,我想服務器推送數據,而不是客戶端拉(根據我的理解,這會更容易)。有人(誰理解我可憐的解釋)能指出我朝着正確的方向嗎?

+0

「實際聽衆不知道他們應該實現ServerListener接口「。那你怎麼稱呼他們? – Thilo 2011-12-23 09:33:43

+0

在當前實現的監聽器中實現接口,工作。如果現在另一位開發人員想要從服務器獲取數據,他應該以某種方式實現serverlistener接口(對嗎?),但是應該在哪裏指定/放置該接口?在服務器捆綁中並不適合這種情況。我是否需要類似於核心包的東西,其中指定了這種通用接口和類?但無論如何,新客戶端也無法訪問另一個包中指定的接口,對嗎? – nyyrikki 2011-12-23 09:40:19

回答

6

'OSGi-centric'方法是使用稱爲白板模式的模式,而不是像使用普通Java那樣的偵聽器模式。您的監聽器不需要向服務器類註冊,而是使用OSGi服務註冊表註冊爲服務。這意味着框架負責處理註冊,取消註冊和離開的聽衆。

有在這裏白板模式的免費白皮書:http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf,而且我們也得到了在行動(http://www.manning.com/cummins企業OSGi的第5章的它的討論。

可能需要一段時間才能讓您的頭部纏繞在偵聽器模式中,因爲它是您的提供服務的偵聽器,而您的「服務器」會消耗服務,而這種服務首先會倒退。一旦你習慣了它,但它的工作非常好。您的服務器使用實現ServiceListener接口的所有服務,並根據需要將數據推送給它們。

最好不要直接使用OSGi API來註冊和使用服務 - 使用聲明性服務(SCR)或藍圖來依賴注入OSGi服務。這些允許您使用XML元數據文件或註釋來註冊和使用服務。

(作爲其它所建議的,使用一個封裝級的依賴關係爲ServerListener接口應該允許它由服務器和偵聽束都被導入,無論哪個束出口包。)

4

你有多個這裏的問題:

  1. 您需要公開其他對象的服務(服務器類)與
  2. 有興趣的對象來註冊需要找到服務,以註冊自己
  3. 的其他對象需要實現一個特定的接口這個工作

一般情況下,試圖改造現有的代碼到OSGi可以是痛苦的,除非你已經有一個模塊化架構。

監聽器接口可以存在於服務器包中,或者你可以把它放在一個單獨的API /合同包中 - 兩者都是有效的設計。

從你如何描述問題中,你聽起來好像不知道OSGi中可以擁有的不同類型的依賴關係。

來自傳統的Java開發,大多數開發人員將開始'我的依賴基於JAR' - 這不是最好的模型。

OSGi提供包級別的依賴關係。通過這種方式,只要某些bundle提供了所需的包,那麼bundle就不關心哪個bundle/JAR提供了依賴關係。

因此,如果您爲偵聽器接口使用了包級依賴項,那麼實現無需關心它是來自服務器包還是合約/ API包。

作爲最後一點,您的設計將服務器與偵聽器緊密結合在一起。如果聽衆失敗會發生什麼?或掛? Pub/sub是這種通信的更好模型。

*編輯*

和冬青的回答再次讓我想起了白板模式 - 絕對是個好主意。

相關問題