私は現在、OSGiフレームワークで働いていますが、私は私には100％明確ではないいくつかの概念について質問があります。私はそれのために自分を探していますが、私は明らかにそれを説明してまともな答えを見つけることができませんでした。
慣れるヘッダの束彼のマニフェストヘッダ2であるImport-PackageとExport-Package。名前がすべてを物語っ：特定のパッケージの需要や、特定のパッケージの提供を。そのパッケージを取得（またはそのパッケージを与える）するためには、完全なバンドルは、フレームワークにインストールする必要がありますインポートが必要とされています。
しかし、その後、私たちはの一部を取得Requirements-Capabilitiesモデル。これは実質的に同じ行うことができますImport-Packageし、Export-Packageヘッダを。ヘッダは、このためにもありますRequirements-Capabilityモデル：Require-CapabilityとProvide-Capability。再び何かを要求ための何かを提供するためのこれらのスタンド。
私は知っているRequirements-Capabilityモデルが唯一のOSGi仕様（S）の開発中に、後に導入されました。まさにそれが発表されたものを年バージョンでは見つけることができません。
だが、
なぜこれが仕様に追加されましたか？私はそれがより多く提供しているか見ていないもの
Import/Export-packageすでに提供：他のパッケージ/バンドルの作成依存関係？誰かが私に概念のこれら2組の間の差（プロのとCONの）でより良い理解を与えることができますか？
私たちは1998年にOSGiの使用を開始すると我々はいくつかの明確な要件を持っていたが、もちろん、それから出てくるだろうかの無いクリアな視界。パッケージ：だから我々は、明示的に私たちが持っていた要件や能力をモデル化するために始めました。インポートパッケージは、機能を必要とし、その機能は、エクスポート・パッケージで提供されています。
2003年にEclipseはOSGiの使用を開始したかったが、彼らは別のバンドルを必要とする機能を必要とし、それらはすべて自分のパッケージをエクスポートおよびインポートのアイデアのようにしませんでした。実際には、その時点で彼らは、パッケージの利点を見ることができませんでした。それらを満たすために、我々は、追加およびフラグメント・ホスト・バンドル要求（とても良いではないことが判明した彼らの欲望の別のものを。）
我々は、リポジトリについての思考を開始するこれらの拡張子を持つOSGiの4.xを指定した後、リチャードはオスカーバンドルリポジトリを開発していました。OSGiの4.0の新しいヘッダに状況を分析し、それは、インポート、パッケージの実装が必要-バンドルのように多くのことを見て、さらにフラグメント・ホスト処理に似ていることが明らかになりました。
2006年にリチャードS.ホール、私が書いたRFC 112既存の依存モデルのセマンティクスをキャプチャしますが、それぞれに対して特異的ではなかった、より汎用的なモデル提案型の要件のを。フレームワークのためのすなわちリゾルバインポート、パッケージと必要-バンドルだけ自分が異なる名前空間。一般的な機能は、リポジトリのモデルは非常に簡単になるよう、一般的な要件としてインポート、パッケージおよびエクスポート・パッケージを考えます。我々は常により多くの名前空間を追加することができますので、さらに良いことに、それが拡張しました。これは実際に使用する名前空間のリゾルバは、完全に独立しました。
いくつかの非常に白熱した議論の後、OSGiのコアプラットフォーム専門家グループは、基本的な考え方を受け入れることを決定し、要件と機能仕様を開発しました。これは、もともとリポジトリのためのモデルでしたが、それは、フレームワーク自体のために非常に有用であることが判明しました。私たちは、このモデルに既存の仕様を適応することを決めました。OSGiの4.3内部モデルのインポート・パッケージ、輸出パッケージ、必要-バンドルなどの要件や機能などのリソース（バンドル）。下位互換性のために、我々は既存のヘッダーを保ったが、それらは内部的な要件や能力に変換されます。
そして、最終的にあなたの質問への答えに。時間が経つにつれてOSGiの仕様は、より多くの追加の名前空間を。名前空間は次のようであるタイプ要件および能力のために。これは、その名前空間の機能のプロパティのセットのセマンティクスを定義します。要件は、それらの性質にアサートされているフィルタ式です。A リソースは、そのすべての要件が満たされたときに、実行時に提供されている一連の機能を持っています。の作業ですリゾルバすべてのランタイムが提供する互いの能力や機能に満足しているリソースのセットを見つけること。
例えば、我々は追加osgi.eeことを定義し、正確にVMのバンドルが実行できるものに名前空間を。私たちは、追加osgi.extenderのネームスペースをモデルそのサービス・コンポーネントの実行時（SCR）のような外部プログラムへの依存性。ほとんどのSCRコンポーネントがSCR自体から任意のパッケージを必要としない、我々は可能な限り独立したとして、それらを作るために懸命に試みました。ランタイムでいくつかのバンドルがSCR機能を提供しない限り、しかし、SCRコンポーネントが無駄に座ります。SCRの複数の実装があるので、これは必要-バンドルを使用できないことに注意してください。私は約20の名前空間があると思います。各名前空間は、で定義されNamespaceたクラス。
このモデルは、OSGiに多くの利点を与えています。
- 結束仕様は、彼らは一般的なモデルに働いていたので、リゾルバの実装が変更に持っていなかった多くの名前空間を追加しましたが。
- ファイングレイン OSGiバンドルは、彼らは非常にきめの細かい方法でそれらの依存関係を記述する方法でユニークです。私が知っているすべてのモジュールシステムは、置換を許可しない、単純なモジュール間の依存関係を使用する傾向があります。
- 柔軟なフレームワークので、それはこれらの依存関係を活用するために、実行時に可能であるバンドル間の依存関係を具体化します。例えば、OSGiの途中で私は、これらの実行時の配線を横断するそのWebページへのバンドルをリンク。
私は個人的にその最高の保たれた秘密ののOSGi 1の要件と機能モデルを検討してください。私の知る限り、ソフトウェア工学の世界に多くの開発プロジェクトを改善するための地域の多くで使用することができる見ることができるように。
この問題の唯一残念な部分は、私は我々がかなりよく、これを説明思ったということであるCore仕様？:-)