質問

アプリケーション機能のモジュール/サービス/ビットが OSGi モジュールの候補として特に適している理由は何ですか?

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

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

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

役に立ちましたか?

解決

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

次のレベルに進むには、アプリをコンポーネントに分割し始める必要があります。通常、コンポーネントには、一連のインターフェイスとクラスの依存関係を通じて、アプリケーションの残りの部分から分離できる一連の責任が必要です。これらを純粋に手作業で特定することは、よく設計された、凝集性は高いが疎結合のアプリケーションの場合は比較的簡単な作業から、馴染みのないソース コードが連動する悪夢のような作業まで、さまざまです。

いくつかの助けは次のようなツールから得られます J依存 これにより、システム内の他のパッケージ/クラスに対する Java パッケージの結合を確認できます。遠心性結合が低いパッケージは、遠心性結合が高いパッケージよりも OSGi バンドルに抽出しやすいはずです。次のようなプロツールを使用すると、さらに多くのアーキテクチャに関する洞察を得ることができます。 構造 101.

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

OSGi は奥深く幅広いコンポーネント モデルなので、次のドキュメントをお勧めします。

  • OSGi R4仕様:Core および Compendium 仕様の PDF を入手してください。これらは正規で権威があり、非常に読みやすいものです。彼らへのショートカットを常に手元に用意して、彼らに相談してください。
  • OSGi のベスト プラクティスを読んでください。必要なものがたくさんあります。 できる あなたが行うことは、もう少し小規模なセットだけです すべき やるべきことがいくつかあります 決してしません (動的インポート:* 例えば)。

いくつかのリンク:

他のヒント

新しいテクノロジーを学ぶときは、豊富なツールを使用することで、大きな悩みを抱えることなく物事に取り組むことができます。この時点でのコミュニティは、 ops4j.org は、「PAX」と呼ばれる次のような豊富なツールセットを提供します。

  • パックス・ランナー:Felix、Equinox、Knopflerfish、Concierge を実行して簡単に切り替えることができます。
  • パックスコンストラクト:Maven を使用して OSGi プロジェクトを簡単に構築、整理、構築する
  • パックス・ドローン:フレームワークに依存せずに Junit を使用して OSGi バンドルをテストします (PaxRunner を使用)

次に、OSGi compendium サービスの実装が多数あります。

  • パックスロギング (ロギング)、
  • パックスウェブ (httpサービス)、
  • Pax Web エクステンダー (戦争支援)、
  • パックスコイン (構成)、
  • パックス・シェル (シェル実装、次の OSGI リリースの一部)
  • などなど。

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

この答えは質問されてからほぼ 3 年後に得られましたが、 リンク 私がたった今見つけたのは、 とてもいいです, 、特に Maven を使用する初心者向けです。段階的な説明。

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

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

私のチームの経験では、OSGi で Web に関する作業を行うのは苦痛であることがわかりました。その他の問題点は、Hibernate と Jakarta Commons Logging です。

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

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

試す http://njbartlett.name/files/osgibook_preview_20091217.pdf

または

http://www.manning.com/hall/

2冊目は私自身が読んだ本ではありませんが、それについて良いことを聞いたことがあります。

最初のものは私にとって非常に役に立ちました。彼は最初にアーキテクチャについて説明し、次に OSGi を実際に操作します。

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

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

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

私の経験では、モノリティックなアプリケーションを OSGi ベースのアプリケーションに変換しようとするべきではありません。これは通常、ひどく管理不能な混乱を引き起こします。新たに始めてください。

無料で利用できるスタンドアロン OSGi 実装の 1 つをダウンロードします。Knopflerfish はかなり良くて安定していることがわかりました (私は多くのプロジェクトで 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

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

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

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top