13

私は OSGI の初心者であり、OSGI サービスとシングルトン パターンの作成の違いについて誰かが教えてくれるかどうか疑問に思っています。たとえば、coreを提供するバンドルとIService、これにアクセスする必要がある複数のバンドルがあるとします。できます：

  1. coreプラグインがアクセスできるバンドルにサービスを登録する
  2. サービスを提供するシングルトンクラスを提供する

OSGI サービスを使用するのは非常に面倒です。プラグインは（インターフェイスを取得するために）とにかくコアに依存する必要があるため、OSGI サービスを使用する利点は何ですか?

4

4 に答える 4

16

サービスは、独立したモジュール間の接続です。モジュールを（仕様パッケージとともに）サービスに依存させることで、モジュール間の結合を大幅に減らすことができ、モジュール性の利点の多くを提供できます。

シングルトンパターンは2つの異なる方法で使用されると思います。1つのオブジェクトを一連のユーザー間で共有するだけにするか（たとえば、ログサービス）、実際には1つのインスタンスしか持てない（たとえば、ハードウェアが1つしかない）。一般的に、エンタープライズソフトウェアの世界のほとんどの人が前者について話していると思います。ただし、経験によれば、プロジェクトが成長すると、シングルトンはシングルトンではなく共有オブジェクトになるか、少なくとも共有オブジェクトのように見えます。OSGiの優れた点は、両方をモデル化でき、「シングルトン」のクライアントがそれを認識せず、中央構成を必要としないことです。その理由は、OSGiが担当のモジュールに依存しているためです。サービスの登録は、サービスをリッスンしているのと同様に、ローカルでの決定です。

サービスの力はそのダイナミクスにはありません（ただし、特に開発中はクールです）。サービスの本質は、中央構成なしでモジュール内の完全なローカル制御を提供することです。これがどれほど強力であるかを理解したら、戻る方法はありません:-)

最後に、注釈付きのDSがあるので、OSGiサービスは面倒ではありません。サービスの登録は、Spring Bean、xml、中央構成を作成するよりもはるかに簡単になりました。

// A component registered as a ISingleton service
@Component
public class MyImpl implements ISingleton {
  void doSingle() { ... }
}

// A component that uses the ISingleton component
@Component
public class MyConsumer {

  @Reference
  void setISingleton(ISingleton is) { ... }
}

...そしてダイナミクスは主に無料で提供されます...

于 2012-09-28T06:34:40.003 に答える
7

簡単な答え: OSGi サービスの利点 (動的に管理されるサービスの実装やサービス検索など) を必要としない (または必要としない) 場合、OSGi サービスは必要ありません。

しかし、ここで考慮すべきことは、サービスが扱いにくいかどうかだけではありません。OSGi 自体は扱いにくいと考えられます。別のバンドルがそのクラスの実装を提供する必要がありますか? そうでないかもしれない。コア バンドルがシャットダウンしたり、必要に応じて実装を提供できなくなったりすることはありますか? 多分。

サービスが問題のクラスに適しているかどうかを判断するには、OSGi Alliance のWhat Is OSGi ページでサービスの具体的なメリットの概要を読んで ください。彼らは、シングルトン クラスがサービスよりも扱いにくくなる可能性について、非常に適切に説明しています。

幸運を。

于 2012-09-27T17:51:32.927 に答える
2

私のOSGi Threading Modelの poc は、すべてのサービスがサービス コンシューマのシングルトンであると私を信じる結果になりました。サービス オブジェクトが 1 つだけ osgi サービス レジストリに登録されるためです。(ただし、この動作をオーバーライドすることもできます)。したがって、プログラミングを考慮する限り、シングルトン クラスと OSGi サービスの動作は同じです。クラス レベルの変数は、さまざまなサービス コンシューマ コール間で共有されます。

OSGIサービスはSingleton ++だと思います

しかし、違いもあります。OSGi は、サービスごとに個別のクラスローダーを提供しますが、これはシングルトンでは不可能です。すべての {singleton} クラスは、単一のクラスローダーによってロードされます。シングルトンで同じ名前 (完全修飾名) を持つ 2 つのクラスを持つことはできませんが、OSGi では可能です。

特定の状況では、クラスを 1 回だけロードする必要があることを確認する必要があります (hibernate セッション ファクトリの作成、hdfc サービスの初期化、重い初期化である POJO の作成は 1 回だけ必要です)。Java EE シナリオを使用している場合、シングルトン クラスが 2 つの異なるクラスローダーによって 2 回ロードされることがあります。したがって、これは静的ブロックの 2 倍の実行になります。不要な仕事。このようなクラスローダの問題は、OSGi で簡単に処理できます (あなたは初心者なので、クラスローディング自体が今後数日のうちに問題になると思います)。

OSGi が提供するもう 1 つの優れた機能は、バンドルの更新です。シングルトン クラスのコードを変更したとします。次に、この更新されたクラスを実行中のアプリケーションにデプロイする必要があります。すべてのシングルトン クラス ローダーがシングルトンの新しいインスタンスを更新するように、基本的にシステムを再起動する必要があります。これは OSGi では必要ありません。バンドルを更新するだけです。

大規模なアプリケーション (エンタープライズ規模) 向けに設計する場合、または制限されたハードウェア容量 (メモリの制約が少なく、計算能力が低い) 向けにコードを設計する必要がある場合は、OSGi を使用することをお勧めします。終了します。他のすべての場合、通常の Java コーディングは完全に機能します。

于 2012-09-28T05:29:52.307 に答える
1

サービスのライフ サイクル (サービスの新しいバージョンをデプロイする、複数のバージョンを同時に実行するなど) を管理できますが、JVM を再起動しないとシングルトンのライフ サイクルを管理できません (再起動しても、1 つのバージョンしか利用できません)。任意の時点)。

于 2012-09-27T17:42:54.590 に答える