2011-12-23 9 views
3

OSGiとそれに近いものは全く新しくなっています。問題への既存のアプリケーションをOSGiサービスに変更するJava/OSGi

ジャンプ:私はリスナーのリストを保持し、サーバ・クラスを持って、リスナーが言及したリストの上にあることにリスナーを置く方法(register(this))を介してtheirselvesを登録することができます(すべてのリスナーは、サーバ・クラスを実装します当然のリスナーインタフェース):

ServerListenerインタフェースです
public void register(ServerListener listener) { 
    if(theListeners == null) 
     theListeners = new ArrayList<ServerListener>(); 

    theListeners.add(listener); 
} 

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

+0

では、リスナーがインターフェイスを実装しています。クライアントの実装を持つ別の開発者がサーバーからデータを取得したい場合は、serverlistenerインターフェイスを何らかの形で実装する必要があります(正しいのですが)。サーバーバンドル内には適切な場所がありません。この種の一般的なインターフェースとクラスが指定されているコアバンドルのようなものが必要ですか?しかし、とにかく、新しいクライアントは別のバンドルで指定されたインタフェースにもアクセスできませんでした。 – nyyrikki

答えて

6

OSGi中心のアプローチは、プレーナーJavaの場合のようにリスナーパターンではなく、ホワイトボードパターンと呼ばれるパターンを使用することです。リスナーは、サーバークラスに登録する代わりに、OSGiサービスレジストリにサービスとして登録します。つまり、フレームワークは、登録、登録解除、および去るリスナーの処理を担当します。 http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf、そして我々はまた、アクション(http://www.manning.com/cummins)でエンタープライズOSGiの第5章での議論を持っている:

あり、ここでホワイトボードパターン上の空きホワイトペーパーです。

サービスを提供するリスナーであるためリスナーパターンを頭で囲むのに時間がかかることがあります。サービスを消費する「サーバー」は、最初は後方に感じます。あなたがそれに慣れれば、それは本当にうまくいく。サーバーはServiceListenerインターフェイスを実装するすべてのサービスを使用し、必要に応じてデータをプッシュします。

サービスの登録と使用に直接OSGi APIを使用しないことをお勧めします.OSGiサービスの依存性注入については、宣言型サービス(SCR)または青写真のいずれかを使用してください。これらを使用すると、サービスをXMLメタデータファイルまたは注釈で登録および使用できます。 (他はServerListenerインターフェイスのためのパッケージレベルの依存関係は関係なく、パッケージをエクスポートしたバンドル、それはサーバーとリスナーバンドルの両方でインポートできるようにするべきではありません使用して、提案してきたように。)

4

あなたが持っている複数の問題:あなたは

  • 興味があるオブジェクトを登録するには、他のオブジェクトのためのサービス(サーバ・クラス)を公開する必要が

    1. は、自分自身を登録するためにサービスを見つける必要がありますこれは一般的に

    を動作させるため

  • 他の目的は、あなたがない限り痛みを伴うことができたOSGiに既存のコードを改造しようとすると、特定のインターフェイスを実装する必要がありますすでにモジュラーアーキテクチャを採用しています。

    リスナーインターフェイスはサーバーバンドルに置くことも、別のAPI /契約バンドルに入れることもできます。どちらも有効なデザインです。

    OSGiで可能な依存関係の種類がわからないような問題がどのように記述されているのでしょうか。

    伝統的なJava開発から来ているほとんどの開発者は、「私の依存関係はJARに基づいています」から始まります。これは最善のモデルではありません。

    OSGiはパッケージレベルの依存関係を提供します。この方法では、あるバンドルが必要なパッケージを提供している限り、バンドルはどのバンドル/ JARが依存関係を提供しても気にしません。

    リスナーインタフェースにパッケージレベルの依存関係を使用した場合、実装はサーババンドルまたはコントラクト/ APIバンドルからのものであるかどうかを気にする必要はありません。

    最終的に、デザインはサーバーをリスナーに密接に結合します。リスナーが失敗した場合はどうなりますか?またはハングアップしますか?パブ/サブは、このタイプの通信のためのより良いモデルです。

    *編集*

    そしてホリーの答えは、ホワイトボードパターンで再び私を思い出した - 間違いなく良いアイデア。

  • 関連する問題