次の方法で共有

Reliable Messaging Protocol バージョン 1.1

このトピックでは、HTTP トランスポートを使用した相互運用に必要な WS-ReliableMessaging February 2007 (バージョン 1.1) プロトコルの Windows Communication Foundation (WCF) 実装の詳細について説明します。 WCF は、このトピックで説明する制約と説明を使用して、WS-ReliableMessaging の仕様に従います。 WS-ReliableMessaging バージョン 1.1 プロトコルは、.NET Framework 3.5 以降で実装されることに注意してください。

WS-ReliableMessaging February 2007 プロトコルは、によって WCF に実装されます。

便宜上、このトピックでは次のロールを使用します。

  • イニシエーター: メッセージ シーケンスの作成 WS-Reliable 開始するクライアント。

  • レスポンダー: イニシエーターの要求を受信するサービス。

このドキュメントでは、次の表のプレフィックスと名前空間を使用します。

接頭辞 Namespace
wsrm http://docs.oasis-open.org/ws-rx/wsrm/200702
netrm http://schemas.microsoft.com/ws/2006/05/rm
s http://www.w3.org/2003/05/soap-envelope
wsa http://schemas.xmlsoap.org/ws/2005/08/addressing
wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wssecurity-secext-1.0.xsd
wsrmp http://docs.oasis-open.org/ws-rx/wsrmp/200702
netrmp http://schemas.microsoft.com/ws-rx/wsrmp/200702
wsp (WS-Policy 1.2 または WS-Policy 1.5)

メッセージング

シーケンスの作成

WCF は、信頼できるメッセージング シーケンスを確立するために、 CreateSequence および CreateSequenceResponse メッセージを実装します。 次の制約が適用されます。

  • B1101: WCF イニシエーターは、 CreateSequence メッセージの ReplyTo、 AcksTo 、および Offer/Endpointと同じエンドポイント参照を使用します。

  • R1102: CreateSequence メッセージ内のAcksTo、ReplyTo、およびOffer/Endpointエンドポイント参照には、オクテット単位と一致するように、同じ文字列表現を持つアドレス値が必要です。

    • WCF レスポンダーは、シーケンスを作成する前に、 AcksTo、 ReplyTo 、および Endpoint エンドポイント参照の URI 部分が同一であることを確認します。

  • R1103: CreateSequence メッセージ内のAcksTo、ReplyTo、およびOffer/Endpointエンドポイント参照には、同じ参照パラメーターのセットが必要です。

    • WCF では適用されませんが、CreateSequenceのAcksTo、ReplyTo、およびOffer/Endpointエンドポイント参照の参照パラメーターは同一であり、受信確認メッセージと逆シーケンス メッセージにReplyTo エンドポイント参照の参照パラメーターを使用することを前提としています。

  • B1104: WCF イニシエーターは、オプションの Expires または Offer/Expires 要素を CreateSequence メッセージに生成しません。

  • B1105: CreateSequence メッセージにアクセスする場合、WCF レスポンダーは、CreateSequenceResponse要素のExpires値としてCreateSequence要素のExpires値を使用します。 それ以外の場合、WCF レスポンダーは Expires 値と Offer/Expires 値を読み取り、無視します。

  • B1106: CreateSequenceResponse メッセージにアクセスすると、WCF イニシエーターは省略可能な Expires 値を読み取りますが、使用しません。

  • B1107: WCF イニシエーターとレスポンダーは常に、CreateSequence/OfferおよびCreateSequenceResponse要素にオプションのIncompleteSequenceBehavior要素を生成します。

  • B1108: WCF では、IncompleteSequenceBehavior要素のDiscardFollowingFirstGap値とNoDiscard値のみが使用されます。

    • WS-ReliableMessaging では、 Offer メカニズムを利用して、セッションを形成する 2 つの逆相関シーケンスを確立します。

  • B1109: CreateSequenceにOffer要素が含まれている場合、WCF レスポンダーは、Accept要素のないCreateSequenceResponseで応答することで、提供されたシーケンスを拒否します。

  • B1110: Reliable Messaging Responder が提供されたシーケンスを拒否した場合、WCF イニシエーターは新しく確立されたシーケンスをエラーします。

  • B1111: CreateSequence に Offer 要素が含まれていない場合、双方向 WCF レスポンダーは、 CreateSequenceRefused エラーで応答することで提供されるシーケンスを拒否します。

  • R1112: Offer メカニズムを使用して 2 つの逆シーケンスが確立された場合、CreateSequenceResponse/Accept/AcksTo エンドポイント参照の[address]プロパティは、バイトのCreateSequence メッセージ バイトの宛先 URI と一致する必要があります。

  • R1113: Offer メカニズムを使用して 2 つの逆シーケンスが確立された場合、イニシエーターからレスポンダーに流れる両方のシーケンス上のすべてのメッセージを同じエンドポイント参照に送信する必要があります。

WCF は WS-ReliableMessaging を使用して、イニシエーターとレスポンダーの間に信頼できるセッションを確立します。 WCF WS-ReliableMessaging 実装は、一方向、要求/応答、および全二重メッセージング パターンに対して信頼性の高いセッションを提供します。 CreateSequenceとCreateSequenceResponseの WS-ReliableMessaging Offer メカニズムを使用すると、2 つの相互の逆シーケンスを確立し、すべてのメッセージ エンドポイントに適したセッション プロトコルを提供できます。 WCF は、セッションの整合性に対するエンド ツー エンドの保護を含む、このようなセッションのセキュリティ保証を提供するため、同じパーティを対象としたメッセージが同じ宛先に確実に到着するようにするのが実用的です。 これにより、アプリケーション メッセージに対するシーケンス受信確認の "ピギー バッキング" も可能になります。 したがって、制約 R1102、R1112、および R1113 は WCF に適用されます。

CreateSequence メッセージの例。

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequence</wsa:Action>
    <wsa:MessageID>urn:uuid:949cca61-8813-42ff-ab33-18d9e3fa82fa</wsa:MessageID>
    <wsa:ReplyTo>
        <wsa:Address>http://Business456.com/clientA</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CreateSequence>
      <wsrm:AcksTo>
        <wsa:Address>http://Business456.com/clientA</wsa:Address>
      </wsrm:AcksTo>
      <wsrm:Offer>
        <wsrm:Identifier>urn:uuid:066b4730-fc82-458a-a5c1-210be4fb4e4e</wsrm:Identifier>
        <wsrm:Endpoint>
          <wsa:Address>http://Business456.com/clientA</wsa:Address>
        </wsrm:Endpoint>
        <wsrm:IncompleteSequenceBehavior>DiscardFollowingFirstGap</wsrm:IncompleteSequenceBehavior>
      </wsrm:Offer>
    </wsrm:CreateSequence>
  </s:Body>
</s:Envelope>

CreateSequenceResponse メッセージの例。

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequenceResponse</wsa:Action>
    <wsa:RelatesTo>urn:uuid:949cca61-8813-42ff-ab33-18d9e3fa82fa</wsa:RelatesTo>
    <wsa:To s:mustUnderstand="1">http://Business456.com/clientA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CreateSequenceResponse>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:IncompleteSequenceBehavior>DiscardFollowingFirstGap</wsrm:IncompleteSequenceBehavior>
      <wsrm:Accept>
        <wsrm:AcksTo>
          <wsa:Address>http://BusinessABC.com/serviceA</wsa:Address>
        </wsrm:AcksTo>
      </wsrm:Accept>
    </wsrm:CreateSequenceResponse>
  </s:Body>
</s:Envelope>

シーケンスを閉じる

WCF では、Reliable Messaging のソースによって開始されるシャットダウンに CloseSequence および CloseSequenceResponse メッセージが使用されます。 WCF Reliable Messaging 変換先はシャットダウンを開始せず、WCF Reliable Messaging ソースは Reliable Messaging の宛先によって開始されるシャットダウンをサポートしていません。 次の制約が適用されます。

  • B1201: WCF Reliable Messaging ソースは、常に CloseSequence メッセージを送信してシーケンスをシャットダウンします。

  • B1202: Reliable Messaging ソースは、 CloseSequence メッセージを送信する前に、シーケンス メッセージの全範囲の受信確認を待機します。

  • B1203: Reliable Messaging ソースには、シーケンスにメッセージが含まれていない場合を除き、常に省略可能な LastMsgNumber 要素が含まれます。

  • R1204: Reliable Messaging destination must not initiate shutdown by sending a CloseSequence message.

  • B1205: CloseSequence メッセージを受信すると、WCF Reliable Messaging ソースはシーケンスが不完全であると見なしてエラーを送信します。

CloseSequence メッセージの例。

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CloseSequence</wsa:Action>
    <wsa:MessageID>urn:uuid:6ce1d4c3-e1c1-474f-a8c9-4210e37f7877</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://Business456.com/clientA</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CloseSequence>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:LastMsgNumber>30</wsrm:LastMsgNumber>
    </wsrm:CloseSequence>
  </s:Body>
</s:Envelope>

メッセージ CloseSequenceResponse 例:

<s:Envelope>
  <s:Header>
    <wsrm:SequenceAcknowledgement>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:AcknowledgementRange Lower="1" Upper="30"></wsrm:AcknowledgementRange>
      <wsrm:Final></wsrm:Final>
      <netrm:BufferRemaining>8</netrm:BufferRemaining>
    </wsrm:SequenceAcknowledgement>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CloseSequenceResponse</wsa:Action>
    <wsa:RelatesTo>urn:uuid:6ce1d4c3-e1c1-474f-a8c9-4210e37f7877</wsa:RelatesTo>
    <wsa:To s:mustUnderstand="1">http://Business456.com/clientA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CloseSequenceResponse>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
    </wsrm:CloseSequenceResponse>
  </s:Body>
</s:Envelope>

シーケンス終了

WCF は主に、CloseSequence/CloseSequenceResponse ハンドシェイクの完了後にTerminateSequence/TerminateSequenceResponse ハンドシェイクを使用します。 WCF Reliable Messaging 変換先は終了を開始せず、Reliable Messaging ソースは Reliable Messaging の宛先によって開始される終了をサポートしていません。 次の制約が適用されます。

  • B1301: WCF イニシエーターは、CloseSequence/CloseSequenceResponse ハンドシェイクが正常に完了した後にのみ、TerminateSequence メッセージを送信します。

  • R1302: WCF は、 LastMsgNumber 要素が特定のシーケンスのすべての CloseSequence および TerminateSequence メッセージ間で一貫性があることを検証します。 これは、 LastMsgNumber がすべての CloseSequence および TerminateSequence メッセージに存在しないか、すべての CloseSequence および TerminateSequence メッセージに存在し、同一であることを意味します。

  • B1303: CloseSequence/CloseSequenceResponse ハンドシェイク後にTerminateSequence メッセージを受信すると、Reliable Messaging 宛先はTerminateSequenceResponse メッセージで応答します。 Reliable Messaging ソースは、 TerminateSequence メッセージを送信する前に最終的な受信確認を行うため、Reliable Messaging の宛先はシーケンスが終了したことを確実に認識し、リソースを直ちに回収します。

  • B1304: CloseSequence/CloseSequenceResponse ハンドシェイクの前にTerminateSequence メッセージを受信すると、WCF Reliable Messaging 宛先はTerminateSequenceResponse メッセージで応答します。 Reliable Messaging 宛先がシーケンスに不整合がないと判断した場合、Reliable Messaging の宛先は、アプリケーションの宛先が指定した時間待機してからリソースを再利用し、クライアントが最終的な受信確認を受け取ることができるようにします。 それ以外の場合、Reliable Messaging 宛先はリソースを直ちに回収し、 Faulted イベントを発生させてシーケンスが疑わしい状態で終了することをアプリケーションの宛先に示します。

TerminateSequence メッセージの例。

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequence</wsa:Action>
    <wsa:MessageID>urn:uuid:3597a398-4f3c-40f4-9335-8f1515572fdf</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://Business456.com/clientA</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:TerminateSequence>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:LastMsgNumber>30</wsrm:LastMsgNumber>
      </wsrm:TerminateSequence>
  </s:Body>
</s:Envelope>

メッセージ TerminateSequenceResponse 例:

<s:Envelope>
  <s:Header>
    <wsrm:SequenceAcknowledgement>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:AcknowledgementRange Lower="1" Upper="30"></wsrm:AcknowledgementRange>
      <wsrm:Final></wsrm:Final>
      <netrm:BufferRemaining>8</netrm:BufferRemaining>
    </wsrm:SequenceAcknowledgement>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequenceResponse</wsa:Action>
    <wsa:RelatesTo>urn:uuid:3597a398-4f3c-40f4-9335-8f1515572fdf</wsa:RelatesTo>
    <wsa:To s:mustUnderstand="1">://Business456.com/clientA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:TerminateSequenceResponse>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
    </wsrm:TerminateSequenceResponse>
  </s:Body>
</s:Envelope>

シーケンス

シーケンスに適用される制約の一覧を次に示します。

  • B1401:WCF は、 xs:longの最大包括値 (9223372036854775807) 以下のシーケンス番号を生成してアクセスします。

Sequence ヘッダーの例。

<wsrm:Sequence s:mustUnderstand="1">
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
  <wsrm:MessageNumber>1</wsrm:MessageNumber>
</wsrm:Sequence>

要求の確認

WCF では、 AckRequested ヘッダーをキープアライブ メカニズムとして使用します。

AckRequested ヘッダーの例。

<wsrm:AckRequested>
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
</wsrm:AckRequested>

SequenceAcknowledgement

WCF は、WS-Reliable メッセージングで提供されるシーケンス受信確認に "ピギー バック" メカニズムを使用します。 次の制約が適用されます。

  • R1601: Offer メカニズムを使用して 2 つの逆シーケンスが確立された場合、 SequenceAcknowledgement ヘッダーは、目的の受信者に送信される任意のアプリケーション メッセージに含まれる場合があります。 リモート エンドポイントは、ピギーバックされた SequenceAcknowledgement ヘッダーにアクセスできる必要があります。

  • B1602: WCF では、Nack要素を含むSequenceAcknowledgementヘッダーは生成されません。 WCF は、各 Nack 要素にシーケンス番号が含まれていることを検証しますが、それ以外の場合は Nack 要素と値を無視します。

SequenceAcknowledgement ヘッダーの例。

<wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
  <wsrm:AcknowledgementRange Lower="1" Upper="1"></wsrm:AcknowledgementRange>
</wsrm:SequenceAcknowledgement>

WS-ReliableMessaging 障害

WS-ReliableMessaging 障害の WCF 実装に適用される制約の一覧を次に示します。 次の制約が適用されます。

  • B1701: WCF は MessageNumberRollover エラーを生成しません。

  • B1702: SOAP 1.2 を介して、サービス エンドポイントが接続制限に達し、新しい接続を処理できない場合、WCF は、次の例に示すように、入れ子になった CreateSequenceRefused 障害サブコード ( netrm:ConnectionLimitReached) を生成します。

<s:Envelope>
  <s:Header>
    <wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200702/fault</wsa:Action>
  </s:Header>
  <s:Body>
    <s:Fault>
      <s:Code>
        <s:Value>s:Receiver</s:Value>
        <s:Subcode>
          <s:Value>wsrm:CreateSequenceRefused</s:Value>
          <s:Subcode>
            <s:Value>netrm:ConnectionLimitReached</s:Value>
          </s:Subcode>
        </s:Subcode>
      </s:Code>
      <s:Reason>
        <s:Text xml:lang="en">Server 'http://BusinessABC.com/serviceA' is too busy to process this request. Try again later.</s:Text>
      </s:Reason>
    </s:Fault>
  </s:Body>
</s:Envelope>

WS-Addressing 障害

WS-ReliableMessaging は WS-Addressing を使用するため、WCF WS-ReliableMessaging 実装では WS-Addressing 障害が生成および送信される可能性があります。 このセクションでは、WCF が明示的に生成し、WS-ReliableMessaging 層で送信する WS-Addressing エラーについて説明します。

  • B1801:WCF は、次のいずれかに該当する場合に、 Message Addressing Header Required エラーを生成して送信します。

    • CreateSequence、CloseSequence、またはTerminateSequenceメッセージにMessageIdヘッダーがありません。

    • CreateSequence、CloseSequence、またはTerminateSequenceメッセージにReplyToヘッダーがありません。

    • CreateSequenceResponse、CloseSequenceResponse、またはTerminateSequenceResponseメッセージにRelatesToヘッダーがありません。

  • B1802:WCF は、 Endpoint Unavailable エラーを生成して送信し、 CreateSequence メッセージ内のアドレス指定ヘッダーの検査に基づいてシーケンスを処理できるエンドポイントがリッスンされていないことを示します。

プロトコルの構成

WS-Addressing を使用したコンポジション

WCF では、2 つのバージョンの WS-Addressing がサポートされています。WS-Addressing 2004/08 [WS-ADDR] と W3C WS-Addressing 1.0 Recommendations [WS-ADDR-CORE] と [WS-ADDR-SOAP]。

WS-ReliableMessaging 仕様では 2004/08 WS-Addressing のみが説明されていますが、使用する WS-Addressing バージョンは制限されません。 WCF に適用される制約の一覧を次に示します。

  • R2101: WS-Addressing 2004/08 と WS-Addressing 1.0 の両方を、WS-Reliable メッセージングで使用できます。

  • R2102: WS-Addressing の単一バージョンは、特定の WS-ReliableMessaging シーケンス全体で使用するか、 Offer メカニズムを使用して相関する逆シーケンスのペアを使用する必要があります。

SOAP を使用したコンポジション

WCF では、WS-Reliable メッセージングでの SOAP 1.1 と SOAP 1.2 の両方の使用がサポートされています。

WS-Security と WS-SecureConversation を使用したコンポジション

WCF では、セキュリティで保護されたトランスポート (HTTPS)、WS-Security でのコンポジション、および WS-Secure Conversation を使用したコンポジションを使用して、WS-ReliableMessaging シーケンスの保護を提供します。 WS-ReliableMessaging 1.1 プロトコル、WS-Security 1.1 プロトコル、WS-Secure Conversation 1.3 プロトコルを一緒に使用する必要があります。 WCF に適用される制約の一覧を次に示します。

  • R2301: 個々のメッセージの整合性と機密性に加えて、WS-ReliableMessaging シーケンスの整合性を保護するには、WCF では、WS-Secure 会話を使用する必要があります。

  • R2302:AWS-Secure 会話セッションは、WS-ReliableMessaging シーケンスを確立する前に確立する必要があります。

  • R2303: WS-ReliableMessaging シーケンスの有効期間が WS-Secure 会話セッションの有効期間を超えた場合、WS-Secure Conversation を使用して確立された SecurityContextToken は、対応する WS-Secure Conversation Renewal バインディングを使用して更新する必要があります。

  • B2304:WS-ReliableMessaging シーケンスまたは相関する逆シーケンスのペアは、常に 1 つの WS-SecureConversation セッションにバインドされます。

  • R2305: WS-Secure Conversation で構成されている場合、WCF レスポンダーでは、 CreateSequence メッセージに wsse:SecurityTokenReference 要素と wsrm:UsesSequenceSTR ヘッダーが含まれている必要があります。

UsesSequenceSTR ヘッダーの例。

<wsrm:UsesSequenceSTR></wsrm:UsesSequenceSTR>

SSL/TLS セッションを使用したコンポジション

WCF では、SSL/TLS セッションを使用したコンポジションはサポートされていません。

  • B2401: WCF では、 wsrm:UsesSequenceSSL ヘッダーは生成されません。

  • R2402: Reliable Messaging Initiator は、wsrm:UsesSequenceSSL ヘッダーを含むCreateSequence メッセージを WCF レスポンダーに送信してはなりません。

WS-Policy を使用したコンポジション

WCF では、WS-Policy の 2 つのバージョン (WS-Policy 1.2 と WS-Policy 1.5) がサポートされています。

WS-ReliableMessaging WS-Policy アサーション

WCF では、WS-ReliableMessaging WS-Policy アサーション wsrm:RMAssertion を使用して、エンドポイントの機能について説明します。 WCF に適用される制約の一覧を次に示します。

  • B3001: WCF は wsrmn:RMAssertion WS-Policy アサーションを wsdl:binding 要素にアタッチします。 WCF では、 wsdl:binding 要素と wsdl:port 要素の両方の添付ファイルがサポートされています。

  • B3002: WCF は wsp:Optional タグを生成しません。

  • B3003: wsrmp:RMAssertion WS-Policy アサーションにアクセスすると、WCF は wsp:Optional タグを無視し、WS-RM ポリシーを必須として扱います。

  • R3004: WCF は SSL/TLS セッションで構成されないため、WCF は wsrmp:SequenceTransportSecurityを指定するポリシーを受け入れません。

  • B3005: WCF は常に wsrmp:DeliveryAssurance 要素を生成します。

  • B3006: WCF は常に、 wsrmp:ExactlyOnce 配信保証を指定します。

  • B3007: WCF は、WS-ReliableMessaging アサーションの次のプロパティを生成して読み取り、WCF で制御しますReliableSessionBindingElement。

    • netrmp:InactivityTimeout

    • netrmp:AcknowledgementInterval

    RMAssertionの例。

    <wsrmp:RMAssertion>
  <wsp:Policy>
    <wsrmp:SequenceSTR/>
    <wsrmp:DeliveryAssurance>
      <wsp:Policy>
        <wsrmp:ExactlyOnce/>
        <wsrmp:InOrder/>
      </wsp:Policy>
    </wsrmp:DeliveryAssurance>
  </wsp:Policy>
  <netrmp:InactivityTimeout Milliseconds="600000"/>
  <netrmp:AcknowledgementInterval Milliseconds="200"/>
</wsrmp:RMAssertion>

フロー制御 WS-ReliableMessaging 拡張機能

WCF では、WS-ReliableMessaging 機能拡張を使用して、シーケンス メッセージ フローに対する追加のより厳密な制御をオプションで提供します。

フロー制御は、 ReliableSessionBindingElement.FlowControlEnabled プロパティを true に設定することで有効になります。 WCF に適用される制約の一覧を次に示します。

  • B4001: Reliable Messaging Flow Control が有効になっている場合、WCF は、次の例に示すように、SequenceAcknowledgement ヘッダーの要素拡張でnetrm:BufferRemaining要素を生成します。

    <wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
  <wsrm:AcknowledgementRange Upper="1" Lower="1"/>
  <netrm:BufferRemaining>8</netrm:BufferRemaining>
</wsrm:SequenceAcknowledgement>

  • B4002: Reliable Messaging Flow Control が有効になっている場合でも、WCF では、SequenceAcknowledgement ヘッダーにnetrm:BufferRemaining要素は必要ありません。

  • B4003: WCF Reliable Messaging Destination では、 netrm:BufferRemaining を使用して、バッファーできる新しいメッセージの数を示します。

  • B4004:Reliable Messaging Flow Control が有効になっている場合、WCF Reliable Messaging Source は netrm:BufferRemaining の値を使用してメッセージ送信を調整します。

  • B4005: WCF は、0 から 4096 までの netrm:BufferRemaining 整数値を生成し、0 から xs:intの maxInclusive 値214748364含む整数値を読み取ります。

メッセージ交換パターン

このセクションでは、さまざまなメッセージ交換パターンに WS-ReliableMessaging を使用する場合の WCF の動作について説明します。 メッセージ交換パターンごとに、次の 2 つの展開シナリオが考慮されます。

  • アドレス指定できないイニシエーター: イニシエーターはファイアウォールの内側にあります。レスポンダーは、HTTP 応答でのみイニシエーターにメッセージを配信できます。

  • アドレス指定可能なイニシエーター: イニシエーターとレスポンダーはどちらも HTTP 要求を送信できます。つまり、2 つの逆 HTTP 接続を確立できます。

一方向、アドレス指定できないイニシエーター

バインド

WCF は、1 つの HTTP チャネルに対して 1 つのシーケンスを使用する一方向のメッセージ交換パターンを提供します。 WCF では、HTTP 要求を使用してイニシエーターからレスポンダーにすべてのメッセージを送信し、HTTP 応答を使用してレスポンダーからイニシエーターにすべてのメッセージを送信します。

CreateSequence Exchange

WCF イニシエーターは、HTTP 要求でOffer要素を持たないCreateSequence メッセージを送信し、HTTP 応答でCreateSequenceResponse メッセージを受け取ります。 WCF レスポンダーはシーケンスを作成し、HTTP 応答にAccept要素を持たないCreateSequenceResponse メッセージを送信します。

SequenceAcknowledgement

WCF イニシエーターは、 CreateSequence メッセージとエラー メッセージを除くすべてのメッセージの応答で受信確認を処理します。 WCF レスポンダーは常に、HTTP 応答に対するスタンドアロンの受信確認をすべてのシーケンスおよび AckRequested メッセージに送信します。

CloseSequence Exchange

WCF イニシエーターは、HTTP 要求で CloseSequence メッセージを送信し、HTTP 応答で CreateSequenceResponse メッセージを受け取ります。 WCF レスポンダーは、HTTP 応答で CloseSequenceResponse メッセージを送信します。

TerminateSequence Exchange

WCF イニシエーターは、HTTP 要求で TerminateSequence メッセージを送信し、HTTP 応答で TerminateSequenceResponse メッセージを受け取ります。 WCF レスポンダーは、HTTP 応答で TerminateSequenceResponse メッセージを送信します。

一方向、アドレス指定可能なイニシエーター

バインド

WCF は、1 つの受信 HTTP チャネルと 1 つの送信 HTTP チャネルに対して 1 つのシーケンスを使用する一方向メッセージ交換パターンを提供します。 WCF では、HTTP 要求を使用してすべてのメッセージを送信します。 すべての HTTP 応答には、空の本文と HTTP 202 状態コードがあります。

CreateSequence Exchange

WCF イニシエーターは、HTTP 要求にOffer要素を持たないCreateSequence メッセージを送信します。 WCF レスポンダーはシーケンスを作成し、HTTP 要求にAccept要素を持たないCreateSequenceResponse メッセージを送信します。

双方向、アドレス指定可能イニシエーター

バインド

WCF は、1 つの受信と 1 つの送信 HTTP チャネルに対して 2 つのシーケンスを使用して、完全に非同期の双方向メッセージ交換パターンを提供します。 このメッセージ交換パターンは、限られた方法でイニシエーター メッセージ交換パターンAddressableRequest/Replyと混在させることができます。 WCF では、HTTP 要求を使用してすべてのメッセージを送信します。 すべての HTTP 応答には、空の本文と HTTP 202 状態コードがあります。

CreateSequence Exchange

WCF イニシエーターは、HTTP 要求でOffer要素を持つCreateSequence メッセージを送信します。 WCF レスポンダーは、CreateSequenceにOffer要素があることを確認し、シーケンスを作成し、Accept要素を使用してCreateSequenceResponse メッセージを送信します。

シーケンスの有効期間

WCF は、2 つのシーケンスを 1 つの完全二重セッションとして扱います。

1 つのシーケンスに障害が発生するエラーを生成すると、WCF はリモート エンドポイントが両方のシーケンスをエラーすることを想定します。 1 つのシーケンスをエラーとするエラーを読み取ると、WCF は両方のシーケンスをエラーします。

WCF では、送信シーケンスを閉じ、受信シーケンスでメッセージの処理を続行できます。 逆に、WCF は受信シーケンスの終了を処理し、送信シーケンスでメッセージを送信し続けることができます。

Request-Reply および一方向のアドレス指定不可能なイニシエーター

バインド

WCF は、1 つの HTTP チャネルに対して 2 つのシーケンスを使用して、一方向および要求/応答メッセージ交換パターンを提供します。 WCF では、HTTP 要求を使用してイニシエーターからレスポンダーにすべてのメッセージを送信し、HTTP 応答を使用してレスポンダーからイニシエーターにすべてのメッセージを送信します。

CreateSequence Exchange

WCF イニシエーターは、HTTP 要求でOffer要素を持つCreateSequence メッセージを送信し、HTTP 応答でCreateSequenceResponseメッセージを受け取ります。 WCF レスポンダーはシーケンスを作成し、HTTP 応答のAccept要素を使用してCreateSequenceResponse メッセージを送信します。

一方向メッセージ

一方向のメッセージ交換を正常に完了するために、WCF イニシエーターは HTTP 要求で要求シーケンス メッセージを送信し、HTTP 応答でスタンドアロン SequenceAcknowledgement メッセージを受信します。 SequenceAcknowledgementは、送信されたメッセージを確認する必要があります。

WCF レスポンダーは、確認応答、エラー、または空の本文と HTTP 202 状態コードを含む応答で要求に応答できます。

双方向メッセージ

双方向メッセージ交換プロトコルを正常に完了するために、WCF イニシエーターは HTTP 要求で要求シーケンス メッセージを送信し、HTTP 応答で応答シーケンス メッセージを受信します。 応答には、送信された要求シーケンス メッセージを確認する SequenceAcknowledgement が含まれている必要があります。

WCF レスポンダーは、アプリケーションの応答、エラー、または空の本文と HTTP 202 状態コードを含む応答で要求に応答できます。

一方向メッセージとアプリケーション応答のタイミングがあるため、要求シーケンス メッセージのシーケンス番号と応答メッセージのシーケンス番号には相関関係がありません。

応答の再試行

WCF は、双方向のメッセージ交換プロトコルの関連付けに HTTP 要求と応答の相関関係に依存します。 このため、WCF イニシエーターは、要求シーケンス メッセージが確認されたときに要求シーケンス メッセージの再試行を停止するのではなく、HTTP 応答に SequenceAcknowledgement、アプリケーションの応答、またはエラーが発生した場合に停止します。 WCF レスポンダーは、応答が関連付けられた要求の HTTP 応答で応答を再試行します。

CloseSequence Exchange

すべての一方向の要求シーケンス メッセージに対するすべての応答シーケンス メッセージと受信確認を受信した後、WCF イニシエーターは HTTP 要求の要求シーケンスの CloseSequence メッセージを送信し、HTTP 応答の CloseSequenceResponse を受け取ります。

要求シーケンスを閉じると、応答シーケンスが暗黙的に閉じられます。 つまり、WCF イニシエーターは、CloseSequence メッセージに応答シーケンスの Final SequenceAcknowledgementを含め、応答シーケンスにCloseSequence交換がないことを意味します。

WCF レスポンダーは、すべての応答が確認され、HTTP 応答で CloseSequenceResponse メッセージを送信します。

TerminateSequence Exchange

TerminateSequenceResponse メッセージを受信した後、WCF イニシエーターは HTTP 要求の要求シーケンスのTerminateSequence メッセージを送信し、HTTP 応答のTerminateSequenceResponseを受け取ります。

CloseSequence交換と同様に、要求シーケンスを終了すると、応答シーケンスが暗黙的に終了します。 つまり、WCF イニシエーターは、TerminateSequence メッセージに応答シーケンスの最終的なSequenceAcknowledgementを含め、応答シーケンスにTerminateSequence交換がないことを意味します。

WCF レスポンダーは、HTTP 応答で TerminateSequenceResponse メッセージを送信します。

要求/応答、アドレス指定可能イニシエーター

バインド

WCF は、1 つの受信 HTTP チャネルと 1 つの送信 HTTP チャネルに対して 2 つのシーケンスを使用して、要求/応答メッセージ交換パターンを提供します。 このメッセージ交換パターンは、限られた方法で Duplex, Addressable イニシエーター メッセージ交換パターンと混在させることができます。 WCF では、HTTP 要求を使用してすべてのメッセージを送信します。 すべての HTTP 応答には、空の本文と HTTP 202 状態コードがあります。

CreateSequence Exchange

WCF イニシエーターは、HTTP 要求でOffer要素を持つCreateSequence メッセージを送信します。 WCF レスポンダーは、CreateSequenceにOffer要素があることを確認し、シーケンスを作成し、Accept要素を使用してCreateSequenceResponse メッセージを送信します。

要求/応答の関連付け

以下は、関連付けられたすべての要求と応答に適用されます。

  • WCF では、すべてのアプリケーション要求メッセージが、 ReplyTo エンドポイント参照と MessageIdを持っていることを確認します。

  • WCF は、各アプリケーション要求メッセージの ReplyToとしてローカル エンドポイント参照を適用します。 ローカル エンドポイント参照は、イニシエーターの CreateSequence メッセージの ReplyTo と、レスポンダーの CreateSequence メッセージの To です。

  • WCF では、受信要求メッセージに MessageId と ReplyToが含まれるようにします。

  • WCF では、すべてのアプリケーション要求メッセージの ReplyTo エンドポイント参照の URI が、前に定義したローカル エンドポイント参照と一致することを確認します。

  • WCF では、要求/応答の関連付け規則に従って、すべての応答が正しい RelatesTo と To ヘッダー wsa 持っていることを確認します。