19

依存関係にアレルギーがある人として、組み込みの Java 6 http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.htmlの代わりにいつ OSGi のようなものを使用しますかプラグイン jar をドロップするだけです)。

（参考までに、これはscalaアプリにあり、どんな提案も受け付けています。ServiceLoaderは私が望むものにかなり近いです）。

4

2 に答える 2

18

ほとんどがニーズに合っている場合ServiceLoaderは、クラスパス上のファイルの存在を介してサービスの検出を探していることを意味します。これは、OSGi が提供するもののほんの一部です。

OSGi を使用すると、アプリケーションの実行中にバンドルを動的にインストールし、サービスをアドバタイズし、アドバタイズを取り消し、バンドルをアンインストールできます。さらに、サービスの消費者として、述語クエリのフィルタリングを使用してサービスを熱心に検索し、提供されたサービス プロバイダーがいつ出入りするかを検出できます。これらのバンドルはクラスパス上にある必要はなく、さまざまな形式で提供できます。Jarファイルと「展開されたディレクトリ」は、私が覚えている2つです。

対照的に、ServiceLoaderが行うことは 1 つだけです。それは、検出可能なファクトリを公開することです。通常は、指定された文字セット名をCharsetDecoder. このようなプロバイダーからサービスを取得してリリースするための正式なプロトコルはありません。OSGi は、サービスへのコンシューマーのバインドとバインド解除を形式化します。コンシューマーは、新しいプロバイダーがオンラインになったときに通知を受け取ることができ、プロバイダーは、コンシューマーがサービス インスタンスを取得して解放したときに通知を受け取ることができます。このライフサイクル制御がサービスにとって重要であり、OSGi を忘れる場合は、これを自分で構築する必要があります。ServiceLoaderそこまで行きません。

あるいは、熱心にサービスを検索して使用するのではなく、より受動的で宣言的なアプローチを取り、OSGi 依存関係マネージャーの 1 つに、指定されたニーズと利用可能なサービス プロバイダーを一致させることができます。選択できる依存関係マネージャーは多数あります。Spring Dynamic Modulesは、最も有能なモジュールの 1 つです。

OSGi は、他にも多くの「ミドルウェア」機能を提供します。あなたの質問は主に を選択することで見逃してしまうものに焦点を当てているため、ここでそれらを売り込むつもりはありませんServiceLoader。

于 2009-12-24T23:30:52.837 に答える
5

seh が指摘するように、単純なサービス ディスカバリだけに関心がある場合、ServiceLoader はコンシューマをプロバイダから切り離すための軽量な方法です。ただし、サービスを一緒に構成する際の支援は提供しません。

たとえば、サービス A がサービス B を使用する必要があるとします。これは「サービスの依存関係」です...しかし、B が利用できない場合、A はどうすればよいでしょうか? OSGi では、依存関係が必須であると仮定して、B が利用できない場合は A も利用できないように手配できます。オプションの依存関係もサポートできます。一方、ServiceLoader を使用する場合、サービス A は、それを囲む JAR がクラスパス上にある限り、その可用性を制御できません。したがって、必要な「バックエンド」サービスがない場合でも、その機能を提供する必要があります。

ServiceLoader で留意すべきもう 1 つのことは、ルックアップ メカニズムを抽象化することです。パブリッシュ メカニズムは非常に優れており、クリーンで宣言的です。しかし、ルックアップ (java.util.ServiceLoader 経由) は地獄のように醜く、グローバルな可視性を持たない環境 (OSGi や Java EE など) にコードを配置するとひどく壊れるクラスパス スキャナーとして実装されます。あなたのコードがそれに絡まってしまうと、後で OSGi で実行するのに苦労することになります。時が来たら置き換えることができる抽象化を書く方が良いです。

于 2010-07-28T19:32:11.413 に答える