5

私が最初にOSGiを見始めたとき、JARをビルドするだけで、マニフェストファイルがあればOSGiコンテナーにデプロイできるという印象を受けました。モジュールを古典的な方法（Maven）で構築し、プラグインなどを使用してマニフェストを作成することを想像しました。そうすれば、基本的にスタンドアロンアプリケーションであるモジュールをOSGiを介して他のモジュールと通信させることができます。

OSGiについてさらに読むと、OSGiがより低レベルで使用され、基本的に依存性注入に取って代わり、ロギングなどの横断的関心事サービスを提供する例が増え始めています。そして、休止状態などを使用するのは問題のようです...（または何かが足りないだけかもしれません）。

少なくとも私にとっては、このように優れたレベルのモジュール性とOSGiへの統合を実現する意味はあまりわかりません。むしろ、それぞれが独自のテクノロジーとフレームワークのセットを備えた個別のモジュールを用意したいと思います。そしておそらくWebリソースと永続化レイヤー。これはOSGiで達成できますか？はいの場合、正しい方向、例などを教えていただけますか？

編集、OSGiを使用しようとしている方法の詳細を追加しました：

私は、より高いレベルの責任を持つ可能性のある、複数のクラスのモジュールを持つ可能性を想像しています。

議事モジュールのように。この場合、イベントの永続化、イベントの追加、フィルターを使用したイベントの一覧表示などが必要です。このアジェンダには複数の内部クラスがあり、永続化レイヤーが必要な場合もあります。したがって、Guiceのようなものを使用してそれらのクラスをDIし、いくつかのJPAを使用してデータを永続化したいと思います。

サーバーやロギングなどのX-cuttingの懸念事項にはバンドルが含まれている可能性があることは理解できますが、データモデルはアジェンダバンドルに固有のものです。だから私の質問は最後だったと思いますバンドル内でできることとできないことは何ですか？そして、一般診療として内部で何をすべきか、すべきではないのでしょうか？

ありがとう！マウリシオ

4

4 に答える 4

2

アプリケーション コードで OSGi への依存を強制することなく、OSGi を使用できます。ただし、OSGi はモジュール性を提供するため、ミドルウェア (レイヤー) には OSGi に関する知識が必要です。問題は、モジュラーの世界では、実装の詳細を隠したいということです。それが全体の目的です。ただし、Spring や Hibernate などは、クラスパスに境界がないと想定する傾向があり、フェンスに真っ向からぶつかります。幸いなことに、これに対応するためのミドルウェアがますます増えています。Hibernate は現在、その取り組みを行っており、OSGi では JPA も利用できると聞きました。

于 2013-03-04T15:55:44.363 に答える
2

OSGi は多くの人にとって多くのものであり、使用したい部分をほぼ自由に選択できます。

  1. 他の依存関係を使用しない単純なライブラリはありますか? スイート、公開パッケージをリストする最小限の MANIFEST.MF を配置するだけで、maven を使用して JAR をビルドすれば完了です。
  2. 依存関係はありますか？(1) と同じように、インポートしたパッケージをマニフェストに追加するだけです。
  3. いくつかの初期化を実行する必要がありますか? Activator を作成し、マニフェストで言及します。
  4. サービス？依存関係とそれらの説明を XML ファイルに入れて、マニフェストに追加するだけです。

など - 快適なレベルを使用してください。

一方、Web アプリケーションを実行したい場合は、OSGi、使用するライブラリ、アプリケーション マネージャー、およびサーブレット/ジー/その他のコンテナー間のアーキテクチャーの相互作用を実際に考慮する必要があります。OSGi はどのレベルに存在しますか? 大まかに言えば、OSGi→コンテナ→アプリ、コンテナ→OSGi→アプリ、コンテナ→アプリ→OSGiのソリューションがあり、それぞれに特徴があります。

于 2013-03-05T09:14:37.737 に答える
1

Maven を使用したビルドに関しては、Maven-Bundle-Pluginを使用すると、自分でマニフェストを作成しなくても OSGi バンドルをビルドできます。必要なメタ情報はすべて POM に含まれます。

依存性注入は、モジュール層の上で実現できます。考えられる解決策の 1 つは、XML 記述またはコード注釈を介して挿入できる宣言型サービスです。これは、OSGi サービスの動的な性質 (サービスの動的バインディングのアンバインディング) を強く反映しています。もう 1 つの方法は、 Springに基づいており、非常によく似た構文を特徴とするBlueprintです。重要な機能の 1 つは、サービスのバインドとバインド解除の性質を抽象化できることです。Spring の使用を検討している場合は、Blueprint を使用してください。

OSGi は、モジュールの構造を示すだけです。モジュールの相互作用 (パッケージをインポート/エクスポートするのは誰か? サービスをエクスポートするのは誰か? サービスを使用するのは誰か?) の明確なグラフが得られるため、すべてのタスクにまとまりのあるバンドルを構築することで、その上にエンタープライズ アーキテクチャを構築できます。

于 2013-03-05T07:58:41.687 に答える
1

OSGi は、JVM のサービス指向アーキテクチャーと呼ばれることもあります。バンドルを、サービスを提供するモジュラー ユニットとして見ると、適切な粒度を定義するのに役立ちます。通常は、API を定義する Java パッケージを提供するためだけに存在する API バンドル、これらの API の実装を提供するサービス バンドル、および提供するユーティリティ/補助バンドルがあります。あなたが言及した分野横断的なサービス。

OSGi の上でいくつかの依存性注入フレームワークを使用できますが、私の経験 (Apache Sling と Adob​​e CQ5 で) からすると、物事をシンプルに保つ方が良い場合がよくあります。OSGi Service Component Runtime および Configuration Admin は、サービス、依存関係、および構成を管理するために必要なすべてを提供してくれます。システムを最初からそのように設計している場合は特にそうです。

Adobe CQ5 の設計における OSGi の経験については、http://www.slideshare.net/bdelacretaz/tales-from-the-osgi-trenches-2012- の「OSGi 塹壕からの物語」スライドをご覧ください。 short-form-edition - 複雑なシステムを構築する際に OSGi がどのように使用されているかを理解するのに役立つかもしれません。

于 2013-03-05T08:44:46.283 に答える