java - OSGiデプロイメント管理サービスの状況

Question

OSGiアプリケーションは、バンドルと呼ばれるモジュールで構成されています。問題は、適度なサイズのアプリケーションには多数のバンドルが含まれるため（Eclipse IDEのプラグインディレクトリを見るだけで数百になる可能性があります）、アプリケーションを管理またはデプロイするときに個々のバンドルよりも粗い粒度が必要になることです。

OSGi Service Compendium Specには、デプロイメント管理サービスが含まれています。これは、デプロイメント・パッケージを、単一のユニットとしてデプロイ、アップグレード、アンインストールなどできるバンドルおよびその他のアーティファクト（構成など）のコレクションとして定義しました。

残念ながら、Deployment Adminの実装、ツール、またはユーザーに関する多くの情報を見つけることができませんでした。

このサービスの状況はどうなっていますか？Deployment Adminに関する経験、意見、または推奨事項はありますか？

また、Spring dm-serverにはバンドル（PARファイル）のアプリケーションスコープコレクションの概念があり、EclipseEquinoxはこの問題に対処するためにネストされたフレームワークに取り組んでいると思います。これらのアプローチは、Deployment Adminとどのように関連していますか？

Answer 1

Deployment Adminは、比較的注目されていないように思われるOSGi大要サービスの1つです。明らかに仕様があり、したがっておそらくリファレンス実装とコンプライアンステストがあります。実装はApacheFelixプロジェクトに貢献しましたが、痕跡を残さずにほとんど沈んでいるようです。

SpringSource dm ServerでPARファイルのサポートを設計するときにDeploymentAdminを調べましたが、このモデルはユースケースには不適切でした。特に、特定のシンボリック名（および任意のバージョン）のバンドルは、同じOSGiフレームワークにインストールされている2つの異なるデプロイメントパッケージに存在しない場合があります。

対照的に、dm Serverの同じインスタンスにインストールされた2つのPARファイルには、両方とも、指定されたバンドルシンボリック名（および同じまたは異なるバンドルバージョン）のバンドルが含まれている場合があります。これは、アプリケーションのスケーリング要件と見なされます。開発者がたまたま同じバンドルをパッケージ化したという理由だけで、大規模なアプリケーションが「衝突」することは望ましくありませんでした。サービスもPARファイルによってスコープされます。

dm Server 2.0では、PARの概念を「プラン」に一般化しました。これは、タイプ名とバージョンによって、インストールされるアーティファクトを参照するファイルです。プランはスコープ（PARのように）またはスコープなしであり、アトミック（その内容のライフサイクルがPARのようにプランのライフサイクルにアトミックに結び付けられていることを意味します）または非アトミックである可能性があります。

ネストされたフレームワークも、アプリケーションのスコーピング要件に対応するための将来のOSGi標準として調査されていますが、dmServerスコープとはかなり異なる設計ポイントが使用されています。ネストされたフレームワークは、その親フレームワーク内のパッケージとサービスを自動的に表示できません。したがって、モデルは、子フレームワークを相互に分離する場合でも、子フレームワークと親フレームワークを分離する場合でも、デフォルトで分離の1つです。dm Serverスコープは、子を意図的に相互に分離しますが、子を親から一方向にのみ分離します。子は、親のすべてのパッケージとサービスを表示できます。

Answer 2

Apache Ace（現在インキュベーションおよび立ち上げ中）がDeployment Adminのデプロイメント・パッケージを動的に生成し、（デフォルトでは、OSGiターゲットにプロビジョニングするときに）FelixのDeploymentAdminを使用できることを知りたいと思うかもしれません。

Webサイトは非常に開発中であるため、Apache Aceは、ソフトウェアコンポーネント、構成データ、およびその他の成果物を一元管理してターゲットシステムに配布できるソフトウェア配布フレームワークです。OSGiを使用して構築されており、さまざまなトポロジで展開できます。ターゲットシステムも通常OSGiベースですが、そうである必要はありません。