我々は現在、SOAP呼び出しの数を受け入れ、また、SOAP呼び出しを行う必要がありますアプリケーションのためのアプリケーションアーキテクチャを決定しようとしています。設計目標の1つは、我々は考慮に入れる必要があるシンプルさと堅牢性です。 GrailsのスペースでハンドルSOAPは、ESB /のMessageBrokerやGrailsので呼び出しますか？
我々はすべて一つの大きなGrailsアプリケーションにこれを結びつけることができますが、これはと堅牢性の面で頭痛を与え、Grailsアプリケーションのアップデートは、すべての着信SOAPリクエストを無効にします。 Grailsのアプリを分割し、ActiveMQの/ ServiceMixの/ミュールのようなものなどでこれを組み合わせた場合、私は思っていた
がお勧めですか？どんなアドバイスやコメントも感謝しています！そして、どんな解決策が良い候補になるのだろうか？
あなたは、ネットワークロードバランサの背後でそれを実行することで、モノリシックなGrailsアプリケーションでいくつかの堅牢性を達成することができます。これにより、ダウンタイムのないローリング・アップグレードを実行できます。
これは、おそらく到達不能なリモートSOAPサービスなどを処理する必要性のような他の懸案事項には対処しません。これは、Muleのようなツール/フレームワークが、再試行とそれ以外のもの。
これは、SOAPブリッジの意図された動作、つまり非同期（つまり、ブリッジにメッセージを送信し、即時のACKを取得し、可能な限りブリッジをリモートディスパッチさせる）か、これは、同期（リモート応答を受信し、それに戻って転送されるまで、すなわちブリッジの呼び出し元が保持されています）。
ブリッジが基本的に同期している場合は、1つのGrailsアプリを使用してロードバランサを使用することができます。再試行を処理するのは発信者次第です。
それ以外の場合は、非同期の場合は、一時的なメッセージの永続性と障害発生時の再配信を支援するメッセージングミドルウェアを検討してください。