44

モジュール/サービス/アプリケーション機能のビットがOSGiモジュールの特に優れた候補となる理由は何ですか？

アプリケーションでOSGiを使用することに興味があります。私たちはJavaショップであり、Springをかなり広範囲に使用しているため、OSGi（tm）サービスプラットフォーム用のSpringDynamicModulesを使用することに傾倒しています。トライアルとして、OSGiを少しアプリケーションに組み込む良い方法を探しています。ここで誰かがこれまたは同様のOSGiテクノロジーを使用しましたか？落とし穴はありますか？

@ニコラス-ありがとう、私はそれを見ました。これは良いチュートリアルですが、Hello Worldの例ではなく、最初の「実際の」OSGiバンドルを作成する方法についてのアイデアをもっと探しています。

@david-リンクをありがとう！理想的には、グリーンフィールドアプリを使用して、すべてを動的に設計します。しかし、私が今探しているのは、既存のアプリケーションの小さな部分にそれを導入することです。アプリの任意の部分を選択できると仮定すると、OSGiモルモットとしてその部分を良くしたり悪くしたりするために考慮すべきいくつかの要因は何ですか？

4

8 に答える 8

41

一部を OSGi で一部を非 OSGi にすることはできないため、アプリ全体を OSGi にする必要があります。最も単純な形式では、アプリケーション全体から単一の OSGi バンドルを作成します。明らかにこれはベスト プラクティスではありませんが、OSGi コンテナー (Equinox、Felix、Knoplerfish など) にバンドルをデプロイする感覚を掴むのに役立ちます。

次のレベルに進むには、アプリをコンポーネントに分割する必要があります。通常、コンポーネントには、一連のインターフェイスとクラスの依存関係を通じて、アプリケーションの残りの部分から分離できる一連の責任が必要です。これらを純粋に手作業で特定することは、適切に設計された高度に凝集性があるが疎結合のアプリケーションのかなり単純なものから、慣れていないインターロックされたソース コードの悪夢にまで及ぶ可能性があります。

システム内の他のパッケージ/クラスに対する Java パッケージの結合を表示できるJDependなどのツールから、いくつかの助けが得られます。遠心性カップリングが低いパッケージは、遠心性カップリングが高いパッケージよりも OSGi バンドルに抽出しやすいはずです。Structure 101などのプロ用ツールを使用すると、さらに建築に関する洞察を得ることができます。

純粋に技術的なレベルでは、160 の OSGi バンドルで構成されるアプリケーションで毎日作業し、Spring DM を使用して、「通常の」Spring から Spring DM への移行にほとんど問題がないことを確認できます。追加の名前空間と、OSGi 固有の Spring 構成を個別のファイルに分離できる (そして分離する必要がある) という事実により、OSGi デプロイメント シナリオを使用する場合と使用しない場合の両方をさらに簡単に行うことができます。

OSGi は深くて幅広いコンポーネント モデルであり、私が推奨するドキュメント:

  • OSGi R4 仕様: Core および Compendium 仕様の PDF を入手してください。これらは標準的で、権威があり、非常に読みやすいものです。それらへのショートカットをいつでも手元に置いておいてください。
  • OSGi のベスト プラクティスを読んでください。できることはたくさんありますが、やるべきことはやや少なく、絶対にやってはいけないこともあります(DynamicImport: * など)。

いくつかのリンク:

于 2008-08-19T19:51:39.143 に答える
9

新しいテクノロジーの豊富なツールを学ぶとき、頭を悩ませることなく物事に取り掛かることができます。この時点で、ops4j.orgのコミュニティは、以下を含む「PAX」と呼ばれる豊富なツールセットを提供しています。

  • Pax Runner : Felix、Equinox、Knopflerfish、Concierge を簡単に切り替えて実行
  • Pax Construct : Maven を使用して OSGi プロジェクトを簡単に構築、整理、構築する
  • Pax Drone : フレームワークに依存せずに、OSGi バンドルを Junit でテストします (PaxRunner を使用)

次に、OSGi 概要サービスの多くの実装があります。

  • Pax ロギング(ロギング)、
  • Pax ウェブ(http サービス)、
  • Pax Web Extender (戦争サポート)、
  • Pax Coin (構成),
  • Pax Shell (シェル実装、次の osgi リリースの一部)
  • などなど。

.. そして、役立つ、フレームワークに依存しないコミュニティがあります - しかし、それは今では宣伝です ;-)

于 2008-09-30T09:45:46.577 に答える
5

この回答は、質問が出されてからほぼ 3 年後に出されますが、私が見つけたばかりのリンクは、特に maven を使用する初心者にとっては非常に優れています。ステップバイステップの説明。

于 2011-04-24T00:14:06.560 に答える
4

http://neilbartlett.name/blog/osgibook/を試してみてください。この本には、OSGi のベスト プラクティスを使用した実践的な例が含まれています。

于 2008-09-27T19:24:17.863 に答える
4

既存のアプリケーションはモノリシックですか、それとも個別のプロセス/レイヤーで階層化されていますか?

階層化されている場合は、中間/アプリ層を OSGi コンテナーで実行するように変換できます。

私のチームの経験では、OSGi で Web 関連の作業を行うのは苦痛でした。その他の問題点は、Hibernate と Jakarta Commons Logging です。

OSGi の仕様はかなり読みやすいので、クラスのロードのアルゴリズムを示すフローチャートを印刷することをお勧めします。「NoClassDefFoundError が発生するのはなぜ?」という瞬間があることを保証します: フローチャートが理由を教えてくれます。

于 2008-08-19T21:51:54.610 に答える
3

OSGi を使い始める場合、留意すべき点がいくつかあります。

このスレッドの他の場所で述べたように、クラスローディングについて知ることは非常に重要です。私の経験では、誰もが遅かれ早かれ問題に遭遇します。

覚えておくべきもう 1 つの重要なことは、参照を保持しないことです。OSGi のサービス概念が構築されているホワイトボード パターンを見てください (他の回答のいずれかのリンクを参照してください)。

私の経験では、モノリシックなアプリケーションを OSGi ベースのアプリケーションに変換しようとするべきではありません。これは通常、ひどく手に負えない混乱につながります。新たに開始します。

無料で入手できるスタンドアロン OSGi 実装のいずれかをダウンロードします。Knopflerfish はかなり優れていて安定していることがわかります (多くのプロジェクトで使用しています)。また、多くのソースコードが付属しています。ここで見つけることができます: http://www.knopflerfish.org

別の優れたチュートリアルがここにあります。https://pro40.abac.com/deanhiller/cgi-bin/moin.cgi/OsgiTutorial

OSGi Alliance の Peter Kriens は素晴らしいインタビューを行いました: http://www.infoq.com/interviews/osgi-peter-kriens。彼のホームページとブログ (常によく読まれています) はここにあります: http://www.aqute.biz

于 2008-09-05T21:07:43.700 に答える
1

Apache Felix のチュートリアルがとても気に入っています。ただし、一般的に、アプリケーションで OSGi を活用することは、「誇大広告なので、このフレームワークを使用しましょう」という決定の 1 つではないと思います。これはどちらかというと設計上の問題ですが、設計に関して OSGi が提供するものはすべて、標準の Java でも実現できます。

ランタイムに関しては、既存のアプリケーションを追加して OSGi 対応にすることはできません。動的に設計する必要があります。Spring DM を使用すると、それを簡単に隠すことができますが、それでも存在するため、注意する必要があります。

于 2008-08-19T15:32:05.017 に答える