OSGi Deployment Admin Serviceのステータス

Question

OSGiアプリケーションは、バンドルと呼ばれるモジュールで構成されています。問題は、アプリケーションを管理またはデプロイするときに、個々のバンドルよりも細かい粒度を望むように、合理的なサイズのアプリケーションには数多くのバンドル（簡単に数百になる可能性があり、Eclipse IDEのプラグインディレクトリを参照）があることです。

OSGi Service Compendium Specには、デプロイメント管理サービスが含まれています。デプロイメント管理サービスは、デプロイメントパッケージをバンドルの集合として定義し、デプロイメント、アップグレード、アンインストールなどを単一の単位として行うことができます。

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

このサービスのステータスはどのようなものですか？ Deployment Adminに関する経験、意見、または推奨事項はありますか？

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

Answer 1

デプロイメント管理者は、比較的注意を集めていないと思われるOSGi要約サービスの1つです。明らかに仕様が存在し、おそらく参照実装と準拠テストが存在します。実装はApache Felixプロジェクトに貢献しましたが、トレースなしでほとんど沈んだようです。

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

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

dm Server 2.0では、PARの概念を「プラン」に一般化しています。このプランは、タイプ名とバージョン別に、インストールする成果物を参照するファイルです。プランは、PAR（PARのような）スコープでもスコープのないものでもよく、アトミック（PARのようなプランのライフサイクルに原子的に結びついていることを意味します）または非アトミックかもしれません。

ネストされたフレームワークは、アプリケーションスコープの要件に対処する可能性がある将来のOSGi標準としても調査されていますが、dm Serverスコープとはかなり異なる設計ポイントがあります。ネストされたフレームワークは、親フレームワーク内のパッケージとサービスを自動的に表示することはできません。したがって、モデルは、子フレームワークを互いに隔離しているか、子フレームワークと親フレームワークを分離しているかにかかわらず、デフォルトで分離の1つです。 dmサーバスコープは、意図的にお子様をお互いに隔離しますが、子供を親から片方だけ隔離します。子供は親のパッケージとサービスをすべて見ることができます。

Answer 2

Apache Ace（現在インキュベーション中であり、ランピング中）は、Deployment Adminのデプロイメントパッケージを動的に生成し、（デフォルトではOSGiターゲットにプロビジョニングするときに）FelixのDeployment Adminを使用することができます。

Apache Aceは、ソフトウェアコンポーネント、設定データ、その他の成果物を集中管理してターゲットシステムに配布できるソフトウェア配布フレームワークです。これはOSGiを使用して構築され、 は異なるトポロジに配置できます。ターゲットシステムは通常、OSGiもベースですが、必ずしもそうである必要はありません。