ミドルウェア上の HTTP/JMS 上のハイブリッド SOAP の要求/応答モデル

Question

当社の製品の 1 つは、次の一方向 Web サービス構造を実装しています。

Server <--------------------- Middleware <---------------- Client
        SOAP over JMS (queue)              SOAP over HTTP

このモデルでは、クライアントは HTTP 経由で SOAP メッセージをミドルウェア (Progress SonicMQ) に送信します。メッセージは SonicMQ によって JMS キューにプッシュされ、サーバーがそこからメッセージを取得します。ただし、見てわかるように、サーバーはクライアントに応答を送信しません (非同期 JMS)。

このモデルへの応答チャネルを実装したいと思います。よく提案される解決策は、ミドルウェアで一時的な ReplyTo-queue (オンザフライ) を作成し、サーバーがそのキューに応答を送信できるようにすることです。その後、クライアントは応答をフェッチできるようになり、replyTo-queue が閉じられます。これは十分便利に思えますが、残念ながら、クライアントは JMS ではなくプレーン HTTP で動作するため、クライアントは簡単に ReplyTo キューを設定できません。

このようなハイブリッド HTTP/JMS SOAP モデルで応答チャネルを実現する 1 つのアプローチは、SOAP 受信が成功するたびに ReplyTo キューを開き、replyTo-queue と送信者の情報を SOAP メッセージに追加して、メッセージをキュー、サーバーによってフェッチされる場所。メッセージを受信して​​処理した後、サーバーはミドルウェア内の指定された ReplyTo-queue に応答を送信できます。最後に、ミドルウェアは、SOAP メッセージのデータ (最初に要求を受信したときにミドルウェア プロシージャに挿入されたデータ) を使用して、HTTP 経由で応答 (SOAP) を元のクライアントに送り返します。

確かに可能ではありますが、これはちょっと荒唐無稽に思えます。そこで質問は次のとおりです。私たちのケースでそのようなリクエスト/レスポンスモデルを実現するよりクリーンな方法はありますか?サーバー側は Java で実装されています。

ソリューション：

Progress SonicMQ は、JMS 応答を簡単に送信できる「コンテンツ応答送信」HTTP アクセプタをサポートしています。コンテンツ返信送信アクセプターは次のように動作します。

• アクセプターはクライアントが送信した HTTP メッセージを受信します
• アクセプタは一時的な JMS キューを作成します
• アクセプタは、HTTP 本文を含む JMS メッセージを作成し、新しく作成された JMS メッセージに一時キューの ID を追加します。
• アクセプタは、JMS メッセージを宛先キュー (一時キューではない) にプッシュします。
• アクセプタは一時的な返信先キューの消費を開始します
• クライアントが元の宛先キューからメッセージをフェッチすると、そのメッセージには設定された返信先キュー ID が含まれます。
• クライアントがメッセージを消費する
• クライアントは応答先キューに応答を送信します
• アクセプタはキューからメッセージを受信します
• アクセプターは、最初に HTTP メッセージを送信したクライアントにメッセージを HTTP として送信します。

コンシューマー (この場合は「サーバー」) に障害が発生し、応答が送信されずタイムアウトが発生した場合、Sonic の HTTP アクセプターはタイムアウトを示す HTTP メッセージをクライアントに送信します。これは SonicMQ の非常に標準的な機能です。他の製品にもあると思います。

これにより、「サーバー」側で標準の SOAP over JMS (skaffman の回答を参照) を使用できるようになり、ミドルウェアでのカスタム プログラミングが回避されます。

JMS モデルにはまだいくつかの問題が見られますが、これは間違いなく改善です。

2009 年 11 月 5 日の更新:

この問題をさらに調査した結果、HTTP<-->ミドルウェア<-->JMS に対する私の疑念が関連していることがわかりました。

このモデルにはいくつかの重大な問題があります。ミドルウェアを使用した同期/非同期モデルは単純に便利ではありません。両端で JMS 接続を実装するか (これは素晴らしいはずです)、両端で HTTP を使用します。それらを混ぜると頭痛が起こるだけです。これら 2 つのうち、SOAP-over-HTTP は SOAP-over-JMS よりもシンプルであり、サポートも優れています。

もう一度：この種のシステムを設計している場合...やめてください。

Answer 1

あなたが提案した解決策がハックであるとはまったく思いません、それが正しい解決策だと思います。同期プロトコルを使用するクライアント中間層があり、次に非同期層を使用する中間サーバー層があり、同期セマンティクスを満たすために応答パスを追加する必要があります。それがミドルウェアの目的です。JMS は一時的な応答先キューを明示的にサポートしているため、ペイロードをまったくいじる必要がないことに注意してください。

より左のフィールドの可能性は、SOAP 1.2 が JMS を念頭に置いて設計されているという事実を活用することで、SOAP-over-JMS を実行するミドルウェアとサーバー層の間に Web サービス層を使用できるようになります。つまり、ミドルウェアはトランスポートのみを変更して、SOAP をエンドツーエンドで維持できるということです。

私が知っている限り、JMS トランスポートをサポートする Web サービス スタックは次のとおりです。 Spring Webサービス, 、プロセスと開発は次のとおりです。 ここに文書化されています. 。これにより、SOAP 層を Spring-WS に移植する機会も得られます。これは素晴らしいことです :)

Answer 2

Fed Ex トラッカー ID のように、ユーザーがいつ応答の準備ができているかを確認できるページへのリンクを追加してはどうでしょうか?ユーザーがリクエストを送信するときにトラッカー ID を提供します。

これは HTTP リクエスト/レスポンスの慣用句に当てはまりますが、ユーザーはリクエストが「ファイア アンド フォーゲット」であることを認識します。