Spring Source dmサーバー固有のImport-BundleとOSGiのRequire-Bundleの違いは何ですか?
プロジェクトでImport-BundleとRequire-Bundleのどちらを使用するか混乱しています。
3 に答える
Import-Bundle は Require-Bundle に似ており、そのバンドルの依存関係を含め、他のバンドルへの完全な依存関係を作成します。オブジェクト指向プログラミングでよく知られている、悪名高い「大きな泥の玉」の問題を引き起こしているため、この推移性は良くありません。
OO では、インターフェイスを使用してこのもつれを解決する方法を見つけました。インターフェイスは実装を仕様から分離します。OSGi は、サービス コントラクトのより高次の概念ではありますが、同様に構築されています。これらのコントラクト (インターフェイス、アクセス許可、ヘルパー クラス) はパッケージに格納されます。コントラクト ベースのプログラミングでは、実装ではなくコントラクトに依存します。したがって、OSGi バンドルはパッケージに依存する必要があります。パッケージはコントラクトを表すからです。
Import-Package <=> interface
Import-Bundle/Require-Bundle <=> implementation class
Import-Bundle は OSGi ではなく、独自の Spring 拡張機能です。これは Require-Bundle のよりクリーンな形式です。いくつかの Eclipse のユース ケースをサポートするには、不潔さが必要でした。コンポーネントからシステムを構築する場合、Require-Bundle/Import-Bundle は根本的に壊れているため、OSGi はこのヘッダーを採用しないことにしました。
理想的には、代わりに Import-Package を使用するようにしてください。これにより、バンドルが互いに依存しなくなります。また、バンドルの一部のみに依存していることを示すこともできます。これは、バージョン管理にも重要です。OSGi では、バンドルのバージョンに関係なく、エクスポートされたパッケージのバージョンを定義できます。そのため、API のバージョンが実際に変更された場合にのみ変更するようにすることができます。これにより、アプリをより管理しやすくすることができます。
ここSpringSourceで説明されています
要約すると、Import-Bundle は特定のバンドルのエクスポートされたすべてのパッケージをインポートし、展開時にそれを解決しますが、Require-Bundle は実際にはそのタイプのバンドルを必要とし、その関係は実行時にそのまま維持されます。
通常、それらはほとんど同じように動作します。たとえば、次の場合は異なる場合があります。
「分割パッケージ」があります: 複数のバンドルに存在するパッケージ。Require-Bundle でのみ表現できる Import-Package / Import-Bundle との依存関係が「失われる」可能性があります (可能な場合は分割パッケージを避ける必要があることに注意してください) 。
Bundle->Package の解決は、そのバンドルを展開するときだと思います。エクスポートされたバンドルを含むバンドルを、エクスポートが異なるバージョンに再デプロイすると、バンドルは気付かないと思います。正直なところ、これについてはよくわかりません。
全体として、本当に必要な場合は、OSGi 標準の Import-Package または Require-Bundle に固執することをお勧めします。ヘッダーはもう少し増えますが、長期的には非常に多くのオプションが得られます。