現在、多数の SOAP 呼び出しを受け入れ、さらに SOAP 呼び出しを行う必要があるアプリケーションのアプリケーション アーキテクチャを決定しようとしています。設計目標の 1 つは、考慮に入れる必要があるシンプルさと堅牢性です。
Grails スペースでは、これをすべて 1 つの大きな Grails アプリケーションに結び付けることができますが、Grails アプリケーションを更新するとすべての着信 SOAP 要求が無効になるため、堅牢性の面で頭痛の種になります。
Grails アプリを分割し、これを ActiveMQ/ServiceMix/Mule などと組み合わせることをお勧めしますか? アドバイスやコメントをいただければ幸いです。そして、どのようなソリューションが良い候補になるでしょうか?
モノリシックな Grails アプリをネットワーク ロード バランサーの背後で実行することで、ある程度の堅牢性を実現できます。これにより、ダウンタイムのないローリング アップグレードを実行できます。
現在、これは、到達できない可能性のあるリモート SOAP サービスなどに対処する必要があるなど、他の懸念事項には対処していません。例外処理、再試行などを提供する Mule などのツール/フレームワークが役立つのは、このような場合です。
これは、SOAP ブリッジの意図された動作によって条件付けられます。つまり、それが非同期であるか (つまり、ファイア アンド フォーゲット、メッセージをブリッジに送信し、すぐに ACK を取得し、可能な限りブリッジにリモート ディスパッチを実行させる)、または同期 (つまり、 . ブリッジの呼び出し元は、リモート応答が受信されて転送されるまで保留されます)。
ブリッジが基本的に同期している場合は、単一の Grails アプリを使い続けて、ロード バランサーを使用できると思います。再試行に対処するのは呼び出し元次第です。
それ以外の場合は、非同期の場合は、一時的なメッセージの永続化と障害発生時の再配信に役立つメッセージング ミドルウェアを検討してください。