同時に実行されている 2 つのクライアントを持ったメッセージ サービスについて考えてみましょう。 クライアントはそれぞれ同じ要求キューに要求メッセージを送信できます。 サービスは任意の順に要求を処理し、応答キューに応答メッセージを送信できます。 各クライアントはどのように応答を受信し、ほかのクライアント宛の応答は受信しないのでしょうか。
最も一般的な方法は、要求にいくつかのタイプの識別子を組み込み、応答にその識別子をコピーすることです。 この識別子は、相関 ID と呼ばれます。 クライアントはそれぞれ一意の相関 ID を使用します。 各クライアントがそのクライアント用の相関 ID が含まれる応答のみを受信できるようにするために使用されるメカニズムもあります。
JMS 送信/受信ステップで相関を有効にできます。 以下の相関スキームが使用可能です。
相関スキームは、以下のことに基づいて異なります。
JMS 相関 ID
ほとんどのメッセージング プラットフォームには、相関 ID フィールドがあります。 このスキームでは、クライアントは一意の ID を生成し、相関 ID フィールドにその ID が含まれる要求メッセージを送信します。 サービスは、応答メッセージを送信する前に、相関 ID を要求メッセージから応答メッセージにコピーします。 クライアントは、元の要求と同じ相関 ID が含まれる応答メッセージをリスンします。
デフォルトでは、相関 ID は自動的に生成されます。 値を手動で指定するには、［手動値］フィールドを使用します。
［ID の再利用］リストは、新しいトランザクションそれぞれに新しい相関 ID を生成するか、テスト期間で同じ相関 ID を使用するかを示します。
JMS メッセージ ID から相関 ID
このスキームは、JMS 相関 ID スキームに類似しています。
ほとんどのメッセージング プラットフォームには、メッセージの一意の識別子が含まれるメッセージ ID フィールドもあります。 メッセージ ID は自動的に生成されます。
サービスは、応答メッセージを送信する前に、要求メッセージのメッセージ ID を応答メッセージの相関 ID にコピーします。 クライアントは、元の要求のメッセージ ID に一致する相関 ID が含まれる応答メッセージをリスンします。
メッセージ ID を手動で指定することはできません。 メッセージ ID を再利用することはできません。
JMS ペイロード
このスキームは、要求および応答メッセージのペイロードに埋め込まれている相関 ID に基づいています。 このスキームには、相関 ID を埋め込む方法を制御するペイロード スキームが関連付けられています。 デフォルトのペイロード スキームでは、メッセージから相関 ID を取得するための XPath 式を定義できます。
以下の図は、JMS ペイロード相関スキームと XPath ペイロード スキームの例を示しています。
［ID の再利用］リストは、新しいトランザクションそれぞれに新しい相関 ID を生成するか、テスト期間で同じ相関 ID を使用するかを示します。
JMS ペイロード相関スキームを同じキュー上のその他の 2 つの相関スキームと混在させることはできません。 1 つのリスナが JMS ペイロード相関スキームを使用してキューでリスンしている場合、そのキュー上のリスナはすべて JMS ペイロードを使用している必要があります。 ただし、JMS ペイロード相関スキームのペイロード スキームとして、JMS 相関 ID および JMS メッセージ ID から相関 ID を使用できます。
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|