モジュール式 Web アプリ
https://stackoverflow.com/questions/126073
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
調べてきました OSGi 最近、これはモジュール式 Java アプリケーションにとって非常に良いアイデアだと思いました。
しかし、私は、Web アプリケーションで OSGi がどのように機能するのか疑問に思っていました。Web アプリケーションでは、コードだけでなく、HTML、画像、CSS なども考慮する必要があります。
仕事では、複数の「タブ」を持つアプリケーションを構築しています。各タブはアプリの一部です。これには、OSGi アプローチを採用することで大きなメリットが得られると思いますが、通常のすべての Web アプリ リソースを処理する最適な方法が何かはまったくわかりません。
違いがあるかどうかはわかりませんが、JSF を使用しています。 アイスフェイス (ナビゲーション ルールがあり、web.xml ですべての顔の構成ファイルを指定する必要があるため、問題の層がさらに追加されます...やだ！）
編集：によると このスレッド, 、faces-config.xml ファイルは JAR ファイルからロードできるため、JAR ファイルに分割すれば、web.xml を変更せずに複数のfaces-config.xml ファイルを含めることが実際に可能です。
ご提案をいただければ幸いです:-)
解決
ここに相乗効果があると考えるのは非常に正しいです。アプリ自体が独立したコンポーネント (OSGi バンドル) から自動的に組み立てられるモジュラー Web アプリがあり、各バンドルは独自のページ、リソース、CSS、およびオプションで JavaScript を提供します。
私たちは JSF (ここでは Spring MVC) を使用していないため、OSGi コンテキストにおけるそのフレームワークの複雑さの追加についてコメントすることはできません。
世の中のほとんどのフレームワークやアプローチは依然として「古い」考え方に固執しています。Web アプリケーションを表す 1 つの WAR ファイルと、その後に多数の OSGi バンドルとサービスが含まれますが、GUI 自体のモジュール化に関係するものはほとんどありません。
設計の前提条件
OSGi を使用する場合、最初に解決すべき問題は次のとおりです。導入シナリオは何ですか? プライマリ コンテナは誰ですか?私が言いたいのは、アプリケーションを OSGi ランタイムにデプロイし、そのインフラストラクチャをあらゆる用途に使用できるということです。あるいは、OSGi ランタイムを従来のアプリ サーバーに埋め込むこともできます。その場合、一部のインフラストラクチャ、特に AppServer のサーブレット エンジンを再利用する必要があります。
現在、私たちの設計はコンテナとして OSGi に基づいており、OSGi が提供する HTTPService をサーブレット コンテナとして使用しています。私たちは外部サーブレット コンテナと OSGi HTTPService の間にある種の透過的なブリッジを提供することを検討していますが、その作業は進行中です。
Spring MVC + OSGi モジュラー Web アプリのアーキテクチャ スケッチ
したがって、目標は、単に OSGi 上で Web アプリケーションを提供することではなく、OSGi のコンポーネント モデルを Web UI 自体に適用して、Web UI を構成可能、再利用可能、動的にすることです。
システム内のコンポーネントは次のとおりです。
- Spring MVC と OSGi のブリッジングを担当する 1 つの中央バンドル。具体的には、 Bernd Kolb によるコード Spring DispatcherServlet をサーブレットとして OSGi に登録できるようにします。
- DispatcherServlet に挿入され、受信した HTTP リクエストを正しいコントローラーにマッピングする 1 つのカスタム URL マッパー。
- 1 つの中央の Sitemesh ベースのデコレータ JSP。サイトのグローバル レイアウトと、デフォルトとして提供する中央の CSS および Javascript ライブラリを定義します。
Web UI にページを提供したい各バンドルは、1 つ以上のコントローラーを OSGi サービスとして公開し、必ず 独自のサーブレットと独自のリソース (CSS、JSP、画像など) を登録します。 OSGi HTTPService を使用します。登録は HTTPService を使用して行われ、主なメソッドは次のとおりです。
httpservice.registerresources（）およびhttpservice.registerservlet（）
Web UI に貢献するバンドルがアクティブ化されてコントローラーを公開すると、それらは中央の Web UI バンドルによって自動的に取得され、前述のカスタム URL マッパーがこれらのコントローラー サービスを収集し、コントローラー インスタンスへの URL の最新のマップを保持します。
次に、特定の URL に対する HTTP リクエストが受信されると、関連付けられたコントローラーを見つけて、そこにリクエストをディスパッチします。
コントローラーは業務を実行した後、レンダリングする必要があるデータを返します。 そして ビューの名前 (この場合は JSP)。この JSP はコントローラーのバンドル内にあり、リソースの場所を HTTPService に登録したため、中央の Web UI バンドルによってアクセスしてレンダリングできます。次に、中央のビュー リゾルバーがこの JSP を中央の Sitemesh デコレーターとマージし、結果の HTML をクライアントに吐き出します。
これはかなり高レベルであることは承知していますが、完全な実装を提供しないと完全に説明するのは困難です。
このための重要な学習ポイントは、次の点に注目することでした。 ベルント・コルブがしたこと 彼の例では、JPetstore を OSGi に変換し、その情報を使用して独自のアーキテクチャを設計しました。
私の意見では、現在、OSGi を従来の Java EE ベースのアプリに何らかの形で埋め込むことにあまりにも多くの誇大宣伝と焦点が当てられており、実際にコンポーネント化された Web アプリケーションの設計を可能にする OSGi イディオムとその優れたコンポーネント モデルを実際に利用することについてはほとんど考慮されていません。
他のヒント
チェックアウト SpringSource dm サーバー - 完全に OSGi の観点から構築され、モジュラー Web アプリケーションをサポートするアプリケーション サーバー。無料、オープンソース、商用バージョンで利用できます。
標準の WAR ファイルをデプロイすることから始めて、アプリケーションを徐々に OSGi モジュール (OSGi 用語で「バンドル」) に分割できます。SpringSource から予想されるとおり、このサーバーは Spring フレームワークおよび関連する Spring ポートフォリオ製品を優れたサポートを備えています。
免責事項:私はこの製品に取り組んでいます。
Spring DM サーバーに注意する ライセンス.
私たちが使ってきたのは レストレット OSGi を使用すると、埋め込み Http サービスで効果を発揮します (実際には Jetty ですが、Tomcat も利用できます)。
Restlet には XML 構成の必要性がゼロまたは最小限であり、行う構成はすべて BundleActivator 内で行われます (新しいサービスの登録)。
ページを構築するときは、関連するサービス実装を処理して出力、デコレータ スタイルを生成するだけです。新しいバンドルをプラグインすると、次回レンダリング時に新しいページ装飾/ウィジェットが追加されます。
REST は、クリーンで意味のある URL、同じデータの複数の表現を提供し、拡張可能な比喩 (動詞が少なく、名詞が多い) を提供します。
私たちにとってのボーナス機能は、キャッシュ、特に ETag の広範なサポートでした。
SpringSource は、OSGi 上に構築された興味深いモジュラー Web フレームワークに取り組んでいるようです。 SpringSource スライス. 。詳細については、次のブログ投稿を参照してください。
RAP見てください！ http://www.eclipse.org/rap/
を見てみましょう http://www.ztemplates.org シンプルで学びやすいです。これを使用すると、関連するすべてのテンプレート、JavaScript、CSS を 1 つの jar に入れて透過的に使用できます。つまり、フレームワークが自動的に行うため、提供されたコンポーネントを使用するときにページ内で必要な JavaScript を宣言する必要さえありません。
興味深い投稿のセット。顧客ごとにカスタマイズされた Web アプリケーションがあります。各顧客は、サインアップした内容に応じて、コンポーネントのコア セットと追加コンポーネントを取得します。リリースごとに、正しいサービスのセットを「組み立て」、顧客に基づいて正しいメニュー構成 (Struts メニューを使用) を適用する必要がありますが、これは控えめに言っても面倒です。基本的には同じコードベースですが、ナビゲーションをカスタマイズして特定のページを表示または非表示にしているだけです。これは明らかに理想的ではないため、OSGi を活用してサービスをコンポーネント化したいと考えています。これがサービス API に対してどのように行われるのかはわかり、CSS や Java スクリプト、コントローラー (Spring MVC を使用) などのリソースもどのようにバンドルできるのかはある程度理解できますが、ページ ナビゲーションなどの「横断的な」問題にどのように対処すればよいでしょうか。特に、新しいサービスを動的にデプロイし、そのサービスにナビゲーションを追加する必要があるシナリオにおける一般的なワークフロー。また、他のサービスにまたがるサービスなど、他の「横断的」な懸念も存在する可能性があります。ありがとう、デクラン。
