ここに相乗効果があると考えるのは非常に正しいです。アプリ自体が独立したコンポーネント（OSGiバンドル）から自動的に組み立てられ、各バンドルが独自のページ、リソース、css、およびオプションでjavascriptを提供するモジュラーWebアプリがあります。
JSF（ここではSpring MVC）を使用していないため、OSGiコンテキストでのそのフレームワークの追加された複雑さについてコメントすることはできません。
そこにあるほとんどのフレームワークまたはアプローチは、依然として「古い」考え方に準拠しています。つまり、Webアプリケーションを表す1つのWARファイル、次に多くのOSGiバンドルとサービスですが、GUI自体のモジュール化にはほとんど関係ありません。
デザインの前提条件
OSGiで解決する最初の質問は、次のとおりです。デプロイメントシナリオは何であり、プライマリコンテナーは誰ですか。つまり、アプリケーションをOSGiランタイムにデプロイし、そのインフラストラクチャをすべてに使用できるということです。または、OSGiランタイムを従来のアプリサーバーに埋め込んでから、一部のインフラストラクチャを再利用する必要があります。具体的には、AppServerのサーブレットエンジンを使用する必要があります。
現在、私たちの設計はコンテナーとしてOSGiに基づいており、サーブレットコンテナーとしてOSGiが提供するHTTPServiceを使用しています。外部サーブレットコンテナとOSGiHTTPServiceの間にある種の透過的なブリッジを提供することを検討していますが、その作業は進行中です。
Spring MVC+OSGiモジュラーWebアプリのアーキテクチャスケッチ
したがって、目標は、OSGiを介してWebアプリケーションを提供するだけでなく、OSGiのコンポーネントモデルをWeb UI自体に適用して、構成可能、再利用可能、動的にすることです。
システムのコンポーネントは次のとおりです。
- Spring MVCとOSGiのブリッジングを処理する1つの中央バンドル。具体的には、Bernd Kolbによるコードを使用して、SpringDispatcherServletをOSGiにサーブレットとして登録できるようにします。
- DispatcherServletに挿入され、着信HTTPリクエストの正しいコントローラーへのマッピングを提供する1つのカスタムURLマッパー。
- サイトのグローバルレイアウトを定義する1つの中央SitemeshベースのデコレータJSPと、デフォルトとして提供する中央CSSおよびJavascriptライブラリ。
Web UIにページを提供する各バンドルは、1つ以上のコントローラーをOSGiサービスとして公開し、独自のサーブレットと独自のリソース（CSS、JSP、画像など）をOSGiHTTPServiceに登録する必要があります。登録はHTTPServiceを使用して行われ、主要なメソッドは次のとおりです。
httpService.registerResources（）およびhttpService.registerServlet（）
Web UIコントリビューションバンドルがアクティブ化してそのコントローラーを公開すると、それらは中央のWeb UIバンドルによって自動的に取得され、前述のカスタムURLマッパーがこれらのコントローラーサービスを収集し、コントローラーインスタンスへのURLの最新のマップを保持します。
次に、HTTPリクエストが特定のURLに着信すると、関連付けられたコントローラーを見つけて、そこにリクエストをディスパッチします。
コントローラはその業務を実行してから、レンダリングする必要のあるデータとビューの名前（この場合はJSP）を返します。このJSPはコントローラーのバンドルにあり、リソースの場所をHTTPServiceに登録したため、中央のWebUIバンドルからアクセスしてレンダリングできます。次に、中央ビューリゾルバーは、このJSPを中央のSitemeshデコレーターとマージし、結果のHTMLをクライアントに吐き出します。
これはかなり高レベルですが、完全な実装を提供しないと、完全に説明するのは困難です。
このための重要な学習ポイントは、 Bernd KolbがJPetstoreをOSGiに変換した例で何をしたかを調べ、その情報を使用して独自のアーキテクチャを設計することでした。
IMHOは現在、OSGiを従来のJava EEベースのアプリに組み込むことにあまりにも多くの誇大宣伝と焦点を当てており、OSGiイディオムとその優れたコンポーネントモデルを実際に利用してコンポーネント化されたWebアプリケーションの設計を実際に可能にすることについてはほとんど考えられていません。