WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

Web サービス高信頼性メッセージング

WebSphere® Message Broker は WS-RM (Web サービス高信頼性メッセージング) をサポートします。 これを使用すると、2 つのシステムは信頼性の高い方法で互いにメッセージを交換できます。

OASIS 標準である Web サービス高信頼性メッセージング (WS-RM) を使用すると、2 つのシステムは信頼性の高い方法で互いに SOAP メッセージを交換できます。 WS-RM の目的は、(例えばサーバー再始動のため) 宛先エンドポイントが一時的に使用不可になる状況や、メッセージ・パスが複数のトランスポート接続を経由し、(例えばファイアウォールを通るため) そのいずれかが失敗する可能性があるような状況で、確実にメッセージを届けることです。 WS-RM は HTTP トランスポートの使用時に大いに信頼性を発揮しますが、パフォーマンスに悪影響を及ぼします。

WS-RM が該当するのは、HTTP トランスポートに対してのみです。 JMS トランスポートを使用するメッセージ・フローで WS-RM を構成しても、WS-RM 設定はフローのデプロイ時に使用されません。

WS-RM を実装するシステムは、正常に送達および受信確認されなかったメッセージを再送し、重複するメッセージがアプリケーション宛先に送られるのを防ぎます。 WS-RM は Web サービス・プロトコルであり、WS-Security および WS-Addressing と共にこれを使用できます。

初期送信側が、アプリケーション・ソースから高信頼性メッセージング・ソースにメッセージを伝送します。 高信頼性メッセージング・ソースは、高信頼性メッセージング宛先にメッセージを伝送し、宛先はメッセージの受信を確認応答します。 その後、高信頼性メッセージング宛先はアプリケーション宛先にメッセージを送り、それがアプリケーション宛先に届きます。

高信頼性メッセージングは、「高信頼性メッセージング・ソース」および「高信頼性メッセージング宛先」という 2 つのエンドポイントの間で発生します。 メッセージが送られるようになる前に、高信頼性ソースと高信頼性宛先は「シーケンス」を確立するためにメッセージ交換を実行します。 各シーケンスは固有 ID で識別されます。1 から始まる番号付きメッセージから成るシーケンスとなります。 メッセージのグループをシーケンスで送信することにより、このシーケンス内のすべてのメッセージの信頼性が確保されます。

高信頼性メッセージング・ソースは、1 回以上にわたって各メッセージを高信頼性メッセージング宛先に送ります。 宛先は、メッセージが正常に受信されたことを示すために、受け取った各メッセージに関する確認応答を送り返します。 宛先によるメッセージ受信の確認応答が高信頼性メッセージング・ソースに届かない場合、ソースは確認応答を受け取るまでメッセージを再送します。

シーケンス内のすべてのメッセージが宛先で正常に受信され、ソースが確認応答を受け取ると、ソースはメッセージ・シーケンスの完了を宛先に示すために TerminateSequence メッセージを送ります。

クライアントが送達されていないメッセージを待機していると、WS-MakeConnection 要求が開始される可能性があります。 WS-MakeConnection は、トランスポート固有のバック・チャネルを使ってサーバー/クライアント間でメッセージを交換する方法を記述する仕様です。 クライアントの MakeConnection 要求によって、クライアントがまだ受け取っていない、キューに入っているメッセージを使ってサーバーは応答可能です。

WebSphere Message Broker は、WS-RM による HTTP 圧縮または SSL はサポートしていません。

メッセージの順序

WS-RM は、プロバイダーによってサポートされる多数の送達保証を指定します。 InOrder 保証は、シーケンス番号に従い、送信されたときの順序で、メッセージが RM 宛先によってアプリケーション宛先に確実に送達されるようにします。 例えば m1、m3、m2 という順序でメッセージを受け取った RM 宛先は、まず m1 を送達し、m2 を受け取るまで m3 を保持した後、m2 と m3 をアプリケーション宛先に送達します。 ブローカーが再開される場合、メッセージは持続しません。

以下の図に示されているサンプル・シナリオでは、InOrder が使用されておらず、メッセージが送信されてきた順序でメッセージを配信する必要はありません。 このシーケンスの 2 番目のメッセージが失われますが、そのメッセージが配信されない場合であっても 3 番目のメッセージは処理されます。

InOrder が false に設定されている場合、すべてのメッセージは配信時に処理されます。

以下のシナリオではこのオプションが選択された状態で、メッセージは送信されてきた順序で配信する必要があります。 シーケンスで 2 番目のメッセージが失われ、3 番目のメッセージは msg2 が配信可能になるまで処理されません。

InOrder が True に設定されている場合、メッセージ 3 はメッセージ 2 がまだ配信されていないため処理されません。

InOrder 保証は、インバウンド・メッセージの処理にのみ影響します。例えば、InOrder 配信を要求するポリシー・セットは、SOAPInput ノードまたはインバウンド・メッセージ・フローに関連付けられます。 インバウンド SOAP メッセージ処理で InOrder 配信が有効な場合、メッセージは、RM ソースによって割り当てられたメッセージ番号に従ってフローで処理されます。

InOrder 保証は、アウトバウンド・メッセージの処理には適用されません。 アウトバウンド SOAP メッセージの処理で InOrder 配信が選択されている場合 (SOAPRequest ノードなど)、メッセージは、必ずしもメッセージ・フローから送信されたときの順序でアプリケーション宛先に配信されるとは限りません。

WS-RM で InOrder を使用する場合のスケーラビリティーについては、スケーラビリティーとパフォーマンスのための SOAP 処理の調整を参照してください。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:48:31


概念トピック概念トピック | バージョン 8.0.0.5 | bc19220_