次のような状況があります。いくつかのサービスは、主に SOAP インターフェイスを介して機能を提供します。この機能を使用して Web サイトに統合するモジュールが 1 つあります。それを行うためのベストプラクティスは何ですか？
サービスの機能は変更される場合があります。したがって、各関数/メソッドは「再ルーティング可能」である必要があります。Web サービスは、おそらく別のマシンでホストされています。
すべての Web サービスを JMS キューにマップすることは合理的ですか (私の最初のアイデア)? その場合、Web サイト モジュールは JMS とのみ通信します。ルーターは、すべての着信 JMS メッセージをさまざまな Web サービス (または別の場所) にルーティングします。
または: すべての機能を統合し、その Web サイトだけが使用する専用の Web サービスが 1 つある可能性はありますか? ここでの利点は、パラメーターと戻り値が型指定されていることです。
何を提案しますか？別のより良いアプローチは何でしょうか?
私があなたの言うことを正しく理解していれば、あなたが目指しているのは、複数のリモートインターフェイス（主にSOAPインターフェイス）のファサードの目的を果たす、Webアプリケーションモジュール用のコヒーレントAPIである同種のインターフェイスを提供することです。
あなたが言及したJMSアプローチに関して-それは合理的なようですが：
多くのキューの代わりに、キューの直後にCamelコンテンツベースのルーターを備えた単一のJMS宛先（または要求/応答パターンの場合は2つのキュー）を使用します。これにより、処理が「再ルーティング」され、Webモジュールがサービスの変更から分離されます。 。
リクエストは、サービス関連のエラーやサービスの可用性に関する簡単な問題などが発生しにくくなりますが、リクエスト/リプライスタイルの呼び出し（RPC風のSOAPの性質に共通）を実行する機能は保持されます。
可能な限り一方向スタイルの呼び出しを使用します（信頼性と反応性を高めるため）。
タイピングの欠如について心配する必要はありません。WSDL+SOAPは強いタイピングを強制しているようですが、それは自動生成されたスタブによって引き起こされる幻想です。それでも、データを前後にマーシャリングする必要があります。SOAPの代わりにJSONを使用します。これは、JSONがXMLよりもはるかにクリーンで冗長性が少ないためです（おそらく高速ですが、通常は関係ありません）。Jacksonは非常に効率的なJSONライブラリであり、Camelディストリビューションですでにサポートされています。JMSObjectMessageは大きなNOです（いくつかの落とし穴に関する良い記事ObjectMessage）
シングルサービスアプローチは、Webモジュールをサービスレイヤーから分離するための良い方法のようです。これは、JMSアプローチの柔軟性とフォールトトレランスに欠けていますが、実装が少し簡単なようです。
一方向に終了できる呼び出しが多数ある場合は、JMSを使用して、キューの後にメッセージを再ルーティングすると思います。