OSGiアプリケーション設計 - 私はサービスフレームワークを悪用していますか？

Question

私たちが開発しようとしているアプリケーションでは、データプロバイダコンポーネントを実装するための共通インタフェースがあり、これらのプロバイダをサービスとして利用しています。

私の同僚の一人は、これらの実装を追跡できるサービス（現在利用可能なサービスの数は、ゲッターを介してコードベースの他の部分で利用可能にするサービス）を作成する方が良いかもしれないと示唆しました。実装バンドルのアクティベータを使用して登録/登録解除します。

これは一般的には機能しますが、これは最初はサービスレイヤーによって提供されているものとほぼ同じです。私には、機能が重複しているように感じられます。

あなたはどう思いますか？

Answer 1

これは機能を複製することになります。実際に他のサービスを管理するサービスがサービスレジストリになります。

データプロバイダに依存するサービスは、サービスマネージャにも依存し、必要な実際のサービスを得るための検索ができるようになりました。

実際に必要なコードに実際に必要とされる依存性を注入するほうが簡単です。仕様に定義されている機能に基づいてこの機能を提供する多くのツール（DS、Spring DM、Blueprint ...）があります。つまり、サービスレジストリです。

更新：動的ロードを行う場合、OSGiはすでにこの目的のためにServiceListenerを提供しており、消費者はこの性質を認識して適切にコーディングする必要があります。上記のツールは、これらのケースも処理します。

Answer 2

あなたは次のようにページをチェックすることができます：http：//www.ibm.com/developerworks/websphere/techjournal/1007_charters/1007_charters.html

が

Answer 3

ご利用の場合はあなたのためにそれを助け願っていますサービスレジストリの主要なOSGiユースケースの1つ。サービスレジストリは、主に、結合されていないモジュール間でインスタンスを共有する必要のあるこの種のアプリケーションを対象としていました。あなたが得るサービスレジストリ使用

：あなたがいない夫婦のOSGi APIへ

総合馬術

できるようにする宣言型サービスや青写真のような

1. ツールをイントロスペクション
2. 同時実行
3. 任意のモジュールできます中央構成の変更を必要とせずにプールに貢献する
4. 強力なfi LTER（DSで設定ランタイム）
5. 標準化された既存のシェルと
6. Debuggability
のOSGiの主な目的は、常に、例えば他の人が使用するためのサービスを貢献する独立したモジュール、されてい

黒板プログラミングモデル。これにより、非常に洗練されたピア・ツー・ピア・デカップリング・プログラミング・モデルが提供されます。クラスローディング戦争全体が常にこの側面を覆しています。