13

私は、仕様全体を読むことなく、OSGi の全体像をもう少し理解しようと努めてきました。多くのことと同様に、OSGi が実際に何であるかの紹介は、おそらく 10 年間それに取り組んできた誰かによって書かれたものであり、おそらくそれについて何も知らない人の考え方に身を置くのに最適な場所ではありませんでした :-)

Felix の例を見ると、DictionaryService何が起こっているのかよくわかりません。OSGi は、バンドルをロードして相互に検出できる JVM の別個のインスタンスですか?

StackOverflow に関する他の回答は、OSGi が個別の JVM 内にデプロイされたモジュールを含む分散システムの依存関係の問題を解決できることを明示しているため、明らかにこれだけではありません(さらに、FAQ は ネットワークについて話し続けています)。

後者の場合、ある JVM で実行されているコンポーネントは、別の JVM の別のコンポーネントとどのように対話するのでしょうか? 2 つのコンポーネントは、同じ JVM 内で実行されているかのように (つまり、ローカル メソッド呼び出しを介して) 相互に「使用」できますか? また、OSGi はネットワークを介したデータのマーシャリングをどのように管理しますか (Serializableたとえば、使用する必要がありますか)?

または、コンポーネントの作成者は、リモート コンポーネント間の通信のために、別の別のメカニズム (OSGi によって提供されるか、独自に記述) を使用する必要がありますか?

どんな助けでも大歓迎です！

4

9 に答える 9

6

はい、OSGi は同じ VM で実行されているバンドルとサービスのみを扱います。ただし、同じ JVM で複数のアプリケーションを (制御された方法で、共通のモジュールを共有して) 実行することを容易にするのは、OSGi の明確な機能であることに注意してください。

クライアント JVM 外のサービスへのアクセスに関しては、現在、標準化されたソリューションはありません。Paremus Infiniflow と派生したオープンソース プロジェクトの Newton は、SCA アプローチを使用しています。来たる OSGi 仕様の 4.2 リリースでは、この問題の 1 つの側面、つまり、クライアントの JVM にリモート サービスをもたらすような汎用配布ソフトウェアの使用方法に対処する予定です。

誰かが R-OSGi について言及したように、このアプローチは問題の反対側、つまり分散 OSGi フレームワーク間の依存関係を管理する方法にも対処します。R-OSGi は一般的な配布ソフトウェアではありませんが、OSGi バンドルのライフサイクルの問題と依存関係の管理を明示的に処理します。

于 2009-01-15T23:30:46.743 に答える
4

私の知る限り、OSGiはこの問題をそのままでは解決しません。リモートOSGiなどのOSGiバンドルがあり、プログラマーがネットワーク全体にサービスを分散できるようにします。

于 2008-12-19T17:37:56.690 に答える
3

まだ、次のリリースに向けて取り組んでいると思います。

しかし、一部の企業はすでに分散 osgi を実装しています。私が知っているのは、Paremus の Infiniflow ( http://www.paremus.com/products/products.html ) です。リンクインでは、彼らもこれに取り組んでいます。詳細はこちら: osgi を使用した Linkedin 次世代アーキテクチャの構築およびこちら: Matt raible: linkedin 次世代アーキテクチャの構築

OSGI 4.2 の変更点の概要は次のとおりです。OSGi R4.2 ドラフトに関するいくつかの考え 、分散 OSGi を扱う RFC-119 に関するセクションがあります。

于 2008-12-28T11:11:24.140 に答える
2

AFAIK、バンドルは同じJVMで実行されていますが、同じクラスローダーを使用してロードされていません（そのため、同じバンドルの2つの異なるバージョンを同時に使用できます）。

別のJVMのコンポーネントと対話するには、rmiなどのネットワークプロトコルを使用する必要があります。

于 2008-12-18T11:39:26.810 に答える
1

「紹介」リンクは実際には紹介ではなく、FAQエントリです。詳細については、http： //www.osgi.org/About/WhatIsOSGiを参照してください。見つけるのは難しいことではないと思います。

とにかく、OSGiはVM内のSOAです。つまり、OSGiフレームワークは、VM内で行われることに関するものであり、VM内でアプリケーションを構造化するためのフレームワークを提供するため、コンポーネントから大規模に構築することができます。したがって、コアは配布とは関係がなく、誰がサービスを実装するかを完全に認識していません。モジュールが疎結合で相互に対応するためのメカニズムを提供するだけです。

そうは言っても、µServiceモデルはモジュール間の結合を具体化し、他のコンポーネントへの配布を提供するフレームワークの上にサポートを構築できることがわかります。前回のリリースでは、これをコアで標準化し、分散トポロジを管理できる特別なサービスRemoteServiceAdminを提供するいくつかのメカニズムを指定しました。

于 2011-06-10T13:50:49.330 に答える
1

@Patriarch24

この質問に対する受け入れられた回答は、そうではないことを示しているようです（私が誤解していない限り）。また、FAQ から抜粋:

OSGi Service Platform は、さまざまなネットワークのデバイス上で、再起動を必要とせずに構成を動的に変更する機能を提供します。

（私自身を強調してください）。同じ FAQ では OSGi をin-VMと説明していますが。

なぜ私はこれについてとても混乱しているのですか？なぜ、10 年前の技術についてのこのような基本的な疑問が明確でないのでしょうか?

于 2008-12-18T15:24:10.833 に答える
1

OSGI の元の問題は、実行の分散よりもコードの分散 (およびバンドルの構成) に関連していました。

分散コンポーネントを見ている人はむしろSCAに目を向けています

于 2009-02-19T23:10:32.297 に答える
0

分散 OSGi 中心のクラウド ランタイムを探している場合は、Paremus Service Fabric ( https://docs.paremus.com/display/SF16/Introduction ) がこれらの機能を提供します。

それぞれが多数の OSGi アセンブリ (Blueprint または Declarative Services) で構成される 1 つまたは複数のシステムを、OSGi ランタイム フレームワーク (Knopflerfish、Felix、または Equinox) の集団全体に動的に展開および維持できます。

軽量の RSA リモート フレームワークが提供され、デフォルトで DDS (非常に優れたミドルウェア メッセージング テクノロジ) を使用してサービス ディスカバリを提供します (ZooKeeper やその他のアプローチを使用できると考えられます)。現在サポートされているリモーティング プロトコルには、RMI と Avro が含まれます。

よろしく

リチャード

于 2011-07-26T20:18:04.293 に答える