3

Java で記述され、WAR ファイルとしてコンパイルされた、さまざまな独立した (ステートレス) Web サービスの大規模なコレクションがあります。それらを単一の Web アプリケーション サーバーにデプロイしたいと考えています。

各 WAR ファイル内のサービスによって処理される URI が、Web アプリ名として使用できるプレフィックスで始まっていれば、これは簡単です。たとえば、

SALES WAR FILE:次のコードが含まれています。
GET http://example.com/sales/widgets
POST http://example.com/sales/widgets
GET http://example.com/sales/sky-hooks

MARKETING WAR FILE:次のコードが含まれています:
GET http://example.com/marketing/widgets
PUT http://example.com/marketing/sky-hooks

...その場合、「sales」と「marketing」という名前で 2 つの WAR ファイルをデプロイするだけです。しかし、私はそれほど幸運ではありません。代わりに、コンポーネントによって処理される URI パスが重複します。このようなもの：

SALES WAR FILE:次のコードが含まれています:
GET http://example.com/widgets/sales
POST http://example.com/widgets/sales
GET http://example.com/sky-hooks/sales

MARKETING WAR FILE:次のコードが含まれています:
GET http://example.com/widgets/marketing
PUT http://example.com/sky-hooks/marketing

私の質問は、これらを 1 つの Web アプリケーション サーバーにデプロイする方法 (もしあれば) です。

かなりの量の作業を必要とする提案を受け入れます。たとえば、私のこれまでの最善のアイデアは、通常の URI パスの前にコンポーネント名のプレフィックスを期待するサービスを構築し、次に、各 URI パターンがどのコンポーネントに該当するかを認識し、URI をそのプレフィックスを追加します。このアプローチの難しさは、私のソース コードを読み取る Swagger のようなツールが、URI がどのように見えるかについて誤った考えを持つことです。

何か案は？

4

5 に答える 5

1

最初に、展開の構成方法を決定する

絶対 URI が重複している必要がありますか? コンテキスト ルートは、絶対パスが何らかの方法でアプリケーション自体にコード化されていない限り、各サービスでサポートされるパスの前に付けられます。最初のステップは、一意のコンテキスト ルートまたはアプリケーション インスタンスを介して、各 WAR ファイルへの直接アクセスを有効にすることです。

オプション 1: 各 WAR ファイルのコンテキスト ルートを明示的に設定する

war ファイルのコンテキスト ルートは、デプロイ時に設定されます。一部のサーバーでは、外部デプロイメント記述子を使用して Web アプリケーションの外部でこれを設定できます。Tomcat の場合、META-INF/context.xml に埋め込むことができます。詳細については、 http://tomcat.apache.org/tomcat-7.0-doc/config/context.htmlを参照してください。

オプション 2: 複数のコンテナーを使用してコンテキスト ルート インスタンスを分離する

または、各 war ファイルを Java EE サーブレット コンテナーの個別のインスタンスにデプロイし、それぞれを異なるポートで実行します。これにより、ハードコーディングされた絶対パスの場合の展開の競合が解決されます。

最後に、仮想ホストをセットアップし、Apache と mod_jk を介してリクエストをプロキシします。

前述のいずれかの方法でコンテキスト ルート インスタンスに一意にアクセスできるようになったら、リバース プロキシとして機能するように Apache のインスタンスを構成します。まず、外部から見える URI の要求を処理する仮想ホストをセットアップします。次に、mod_jk を構成して、要求を正しい WAR ファイルのデプロイメントにルーティングします。詳細については、 http://tomcat.apache.org/connectors-doc/webserver_howto/apache.htmlを参照してください。

後付け

上記のソリューション アプローチは、このタイプの問題に対する一般的なものであり、実装のためのリバース プロキシおよび Java EE サーブレット テクノロジの例として選択された Apache および Tomcat の構成に関するある程度の知識が必要です。展開の制約に関する追加の詳細は、最適なソリューションを決定するのに役立ちます。一般に、何が変更される可能性があり、何が変更されない可能性があるかについて厳しい制約を特定することは、解決策を迅速に導くはずです。

于 2014-06-18T01:50:22.560 に答える
0

これはリバース プロキシの使用例です。Web サーバーが Apache の場合、@nont proxy_mod で提案されているように、リバース プロキシを作成するために使用できます。

IBM Http Server (IHS) もこの mod を許可していることを知っています。

于 2014-06-19T17:07:45.887 に答える