Поделиться через

Протокол надежного обмена сообщениями версии 1.1

В этой статье рассматриваются сведения о реализации Windows Communication Foundation (WCF) для протокола WS-ReliableMessaging февраля 2007 г. (версия 1.1), необходимого для взаимодействия с использованием транспорта HTTP. WCF следует спецификации WS-ReliableMessaging с ограничениями и пояснениями, изложенными в этом разделе. Обратите внимание, что протокол WS-ReliableMessaging версии 1.1 реализуется начиная с .NET Framework 3.5.

Протокол WS-ReliableMessaging февраля 2007 года реализуется в WCF с помощью ReliableSessionBindingElement.

Для удобства в этом разделе используются следующие роли:

  • Инициатор: клиент, инициирующий создание последовательности сообщений WS-Reliable.

  • Ответитель: служба, которая получает запросы инициатора.

В этом документе используются префиксы и пространства имен в следующей таблице.

Приставка Пространство имен
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: Ссылки на AcksTo, ReplyTo и Offer/Endpoint конечные точки в сообщении CreateSequence должны иметь адреса с идентичными строковыми представлениями, так чтобы они совпадали побайтово.

    • Средство реагирования WCF проверяет, совпадают ли URI-части в AcksTo, ReplyTo и Endpoint ссылках на конечные точки перед созданием последовательности.

  • R1103: ссылки на конечные точки AcksTo, ReplyTo и Offer/Endpoint в CreateSequence сообщении должны иметь одинаковый набор ссылочных параметров.

    • WCF не обеспечивает, но предполагает, что ссылочные параметры AcksTo, ReplyTo и Offer/Endpoint в ссылках на конечные точки CreateSequence идентичны и использует ссылочные параметры из ReplyTo ссылки на конечную точку для подтверждений и сообщений последовательности.

  • B1104: Инициатор WCF не создает необязательный элемент Expires или элемент Offer/Expires в сообщении CreateSequence.

  • B1105: при доступе к CreateSequence сообщению средство ответа WCF использует значение Expires в элементе CreateSequence в качестве значения Expires в элементе CreateSequenceResponse. В противном случае средство реагирования WCF считывает и игнорирует значения Expires и Offer/Expires.

  • B1106: при обращении CreateSequenceResponse к сообщению инициатор WCF читает необязательное Expires значение, но не использует его.

  • B1107: инициатор WCF и ответчик всегда создают необязательный IncompleteSequenceBehavior элемент в CreateSequence/Offer и CreateSequenceResponse элементах.

  • B1108: WCF использует только значения DiscardFollowingFirstGap и NoDiscard в элементе IncompleteSequenceBehavior.

    • WS-ReliableMessaging использует Offer механизм для установления двух противоположных коррелированных последовательностей, формирующих сеанс.

  • B1109: если CreateSequence содержит элемент Offer, WCF Responder отклоняет предложенную последовательность, отвечая CreateSequenceResponse без элемента Accept.

  • B1110: Если Надежный Ответчик обмена сообщениями отклоняет предложенную последовательность, инициатор WCF прерывает только что установленную последовательность.

  • B1111: Если CreateSequence не содержит элемент Offer, двусторонний компонент ответа WCF отклоняет предложенную последовательность, отвечая с ошибкой CreateSequenceRefused.

  • R1112: при создании двух обратных последовательностей с помощью Offer механизма [address] свойство CreateSequenceResponse/Accept/AcksTo ссылки на конечную точку должно байт в байт совпадать с целевым URI сообщения CreateSequence.

  • R1113: при установке двух обратных последовательностей с помощью Offer механизма все сообщения обоих последовательностей, поступающих от инициатора к ответчику, должны отправляться в одну и ту же ссылку на конечную точку.

WCF использует WS-ReliableMessaging для установления надежных сеансов между Инициатором и Ответчиком. Реализация WCF WS-ReliableMessaging предоставляет надежный сеанс для одностороннего, ответного запроса и полного дуплексного обмена сообщениями. Механизм WS-ReliableMessaging Offer на CreateSequence и CreateSequenceResponse позволяет установить две связанные обратные последовательности и обеспечивает протокол сеанса, подходящий для всех конечных точек сообщения. Так как 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 использует сообщения CloseSequence и CloseSequenceResponse для завершения работы надежной передачи сообщений, инициированной источником. Приемник надежного обмена сообщениями WCF не инициирует завершение работы, а источник надежного обмена сообщениями WCF не поддерживает завершение, инициируемое приемником. Применяются следующие ограничения:

  • B1201: источник надежного обмена сообщениями WCF всегда отправляет CloseSequence сообщение для завершения последовательности.

  • B1202: источник надежного обмена сообщениями ожидает подтверждения всего диапазона последовательности сообщений перед отправкой CloseSequence сообщения.

  • B1203: источник надежного обмена сообщениями всегда включает необязательный LastMsgNumber элемент, если последовательность не содержит сообщений.

  • R1204: Назначение надёжного обмена сообщениями не должно инициировать завершение работы путем отправки сообщения CloseSequence.

  • B1205: при получении CloseSequence сообщения источник надежных сообщений WCF считает последовательность неполной и отправляет ошибку.

Пример 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 в основном использует TerminateSequence/TerminateSequenceResponse рукопожатие после завершения CloseSequence/CloseSequenceResponse рукопожатия. Назначение надежного обмена сообщениями WCF не инициирует завершение обмена, а источник надежного обмена сообщениями не поддерживает завершение обмена, инициированное назначением. Применяются следующие ограничения:

  • B1301: инициатор WCF отправляет TerminateSequence сообщение только после успешного завершения CloseSequence/CloseSequenceResponse рукопожатия.

  • R1302: WCF проверяет, что элемент LastMsgNumber согласован во всех сообщениях CloseSequence и TerminateSequence для заданной последовательности. Это означает, что LastMsgNumber либо не присутствует во всех CloseSequence и TerminateSequence сообщениях, либо присутствует и идентичен во всех CloseSequence и TerminateSequence сообщениях.

  • B1303: при получении TerminateSequence сообщения после CloseSequence/CloseSequenceResponse рукопожатия адресат Надежного обмена сообщениями отвечает сообщением TerminateSequenceResponse . Поскольку источник надежных сообщений получает окончательное подтверждение перед отправкой TerminateSequence сообщения, получатель точно знает, что последовательность завершена, и сразу же освобождает ресурсы.

  • B1304: При получении сообщения TerminateSequence перед рукопожатием CloseSequence/CloseSequenceResponse назначение WCF Reliable Messaging отвечает сообщением TerminateSequenceResponse. Если конечное назначение 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>

Подтверждение Последовательности

WCF использует механизм "piggy-back" для подтверждения последовательности, предоставляемых в WS-Reliable Обмена сообщениями. Применяются следующие ограничения:

  • R1601: При установке двух обратных последовательностей с помощью механизма Offer, заголовок SequenceAcknowledgement может быть включен в любое сообщение приложения, предназначенное для целевого получателя. Удаленная конечная точка должна иметь доступ к заголовку с наложением SequenceAcknowledgement.

  • B1602: WCF не генерирует SequenceAcknowledgement заголовки, содержащие Nack элементы. 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

Ниже приведен список ограничений, которые применяются к реализации ошибок WCF WS-ReliableMessaging. Применяются следующие ограничения:

  • 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. В этом разделе рассматриваются ошибки WS-Addressing, которые WCF явно генерирует и передает на уровне WS-ReliableMessaging:

  • B1801:WCF создает и передает ошибку Message Addressing Header Required , если одно из следующих значений имеет значение true:

    • Отсутствует заголовок CreateSequence в сообщении CloseSequence, TerminateSequence или MessageId.

    • Отсутствует заголовок CreateSequence в сообщении CloseSequence, TerminateSequence или ReplyTo.

    • Отсутствует заголовок \CreateSequenceResponse в сообщении \CloseSequenceResponse, \TerminateSequenceResponse или \RelatesTo.

  • B1802:WCF создает и передает Endpoint Unavailable ошибку, указывающую на отсутствие прослушивания конечной точки, которая может обрабатывать последовательность на основе проверки заголовков адресации в сообщении CreateSequence .

Состав протокола

Композиция с WS-Addressing

WCF поддерживает две версии WS-Адресации: WS-Addressing 2004/08 [WS-ADDR] и W3C WS-Addressing 1.0 Рекомендаций [WS-ADDR-CORE] и [WS-ADDR-SOAP].

Несмотря на то, что в спецификации WS-ReliableMessaging упоминается только версия WS-Addressing 2004/08, это не ограничивает использование версии WS-Addressing. Ниже приведен список ограничений, которые применяются к WCF:

  • R2101: можно использовать WS-Addressing 2004/08 и WS-Addressing 1.0 с WS-Reliable для обмена сообщениями.

  • R2102: Единая версия WS-Addressing должна использоваться на протяжении всей заданной WS-ReliableMessaging последовательности или пары последовательностей, имеющих обратное направление, сопоставленных с помощью Offer механизма.

Композиция с помощью SOAP

WCF поддерживает использование SOAP 1.1 и SOAP 1.2 в обмене сообщениями WS-Reliable.

Композиция с WS-Security и WS-SecureConversation

WCF обеспечивает защиту последовательностей WS-ReliableMessaging, используя безопасный транспорт (HTTPS), а также интеграцию с WS-Security и WS-Secure Conversation. Протоколы WS-ReliableMessaging 1.1, WS-Security 1.1 и WS-Secure 1.3 следует использовать вместе. Ниже приведен список ограничений, которые применяются к WCF:

  • R2301. Для защиты целостности последовательности WS-ReliableMessaging в дополнение к целостности и конфиденциальности отдельных сообщений WCF требует, чтобы использовалась WS-Secure Беседа.

  • R2302: перед установкой последовательностей WS-ReliableMessaging необходимо установить сеанс беседыAWS-Secure.

  • R2303. Если время существования последовательности WS-ReliableMessaging превышает время существования сеанса разговора WS-Secure, SecurityContextToken установленное с помощью WS-Secure Разговора, необходимо обновить с помощью соответствующей привязки обновления разговора WS-Secure.

  • B2304:WS-ReliableMessaging последовательность или пара коррелированных обратных последовательностей всегда привязаны к одному 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: инициатор надежного обмена сообщениями не должен отправлять CreateSequence сообщение с заголовком wsrm:UsesSequenceSSL в ответ WCF.

Композиция с WS-Policy

WCF поддерживает две версии WS-Policy: 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 и обеспечивает контроль над ними в WCFReliableSessionBindingElement:

    • 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: Если включено управление потоком надежных сообщений, WCF создает netrm:BufferRemaining элемент в расширяемости заголовка SequenceAcknowledgement, как показано в следующем примере.

    <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: даже если включено Управление Потоком Надежных Сообщений, WCF не требует элемента netrm:BufferRemaining в заголовке SequenceAcknowledgement.

  • B4003: Адресат надежного обмена сообщениями WCF использует netrm:BufferRemaining для указания, сколько новых сообщений он может буферизовать.

  • B4004:Если включен элемент управления потоком надежных сообщений, источник надежного обмена сообщениями WCF использует значение netrm:BufferRemaining для регулирования передачи сообщений.

  • B4005: WCF создает netrm:BufferRemaining целые значения в диапазоне от 0 до 4096 включительно и считывает целые значения от 0 до значения xs:intmaxInclusive 214748364 включительно.

Шаблоны Обмена сообщениями

В этом разделе описывается поведение WCF при использовании WS-ReliableMessaging для различных шаблонов Обмена сообщениями. Для каждого шаблона Обмена сообщениями рассматриваются следующие два сценария развертывания:

  • Неадресуемый инициатор: инициатор находится за брандмауэром; Ответчик может доставлять сообщения инициатору только в HTTP-ответах.

  • Адресный инициатор: инициатор и ответчик могут отправлять HTTP-запросы; другими словами, можно установить два обратных HTTP-подключения.

Однопутевая, неадресуемый инициатор

Привязка

WCF предоставляет шаблон обмена одностороннего сообщения с помощью одной последовательности по одному каналу HTTP. WCF использует HTTP-запросы для передачи всех сообщений от инициатора к ответчику и HTTP-ответы для передачи всех сообщений от ответчика к инициатору.

CreateSequence Exchange

Инициатор WCF передает CreateSequence сообщение без элемента Offer в HTTP-запросе и ожидает сообщение CreateSequenceResponse в HTTP-ответе. Респондент WCF создает последовательность действий и передает сообщение CreateSequenceResponse, не содержащая элемента Accept в ответе HTTP.

Подтверждение Последовательности

Инициатор WCF обрабатывает подтверждения по ответу всех сообщений, кроме сообщения CreateSequence и сообщений о сбое. Ответчик WCF всегда передает автономное подтверждение в HTTP-ответ на все последовательности и сообщения AckRequested.

CloseSequence Exchange

Инициатор WCF передает CloseSequence сообщение по HTTP-запросу и ожидает CreateSequenceResponse сообщение в ответе HTTP. Модуль-приемник WCF передает сообщение CloseSequenceResponse через HTTP-ответ.

Завершение последовательности обмена

Инициатор WCF передает TerminateSequence сообщение по HTTP-запросу и ожидает TerminateSequenceResponse сообщение в ответе HTTP. Модуль-приемник WCF передает сообщение TerminateSequenceResponse через HTTP-ответ.

Однонаправленный адресуемый инициатор

Привязка

WCF предоставляет шаблон обмена одностороннего сообщения с помощью одной последовательности через один входящий и один исходящий HTTP-канал. WCF использует HTTP-запросы для передачи всех сообщений. Все ответы HTTP имеют пустой текст и код состояния HTTP 202.

CreateSequence Exchange

Инициатор WCF передает HTTP-запрос с CreateSequence сообщением, но без элемента Offer. Респондент WCF создает последовательность и передает CreateSequenceResponse сообщение без Accept элемента на HTTP-запросе.

Дуплексный, адресуемый инициатор

Привязка

WCF предоставляет полностью асинхронный двусторонний шаблон обмена сообщениями с помощью двух последовательностей по одному входящего и одного исходящего HTTP-канала. Этот шаблон обмена сообщениями можно ограниченным образом совместить с шаблоном обмена сообщениями инициатора Request/ReplyAddressable. WCF использует HTTP-запросы для передачи всех сообщений. Все ответы HTTP имеют пустой текст и код состояния HTTP 202.

CreateSequence Exchange

Инициатор WCF передает сообщение CreateSequence с элементом Offer по HTTP-запросу. Компонент WCF гарантирует, что CreateSequence содержит элемент Offer, затем создает последовательность и передает сообщение CreateSequenceResponse с элементом Accept.

Время существования последовательности

WCF обрабатывает две последовательности как один полностью дуплексный сеанс.

При возникновении сбоя в одной последовательности, WCF ожидает, что удаленная конечная точка сгенерирует сбой в обеих последовательностях. При возникновении сбоя, который приводит к сбою одной последовательности, WCF вызывает сбой обеих последовательностей.

WCF может закрыть исходящую последовательность и продолжить обработку сообщений в входящей последовательности. И наоборот, WCF может обрабатывать закрытие входящей последовательности и продолжать отправлять сообщения в исходящей последовательности.

Request-Reply и односторонний, неадресуемый инициатор

Привязка

WCF предоставляет шаблоны обмена сообщениями: односторонний и запрос-ответ, используя две последовательности через один канал HTTP. WCF использует HTTP-запросы для передачи всех сообщений от инициатора к ответчику и HTTP-ответы для передачи всех сообщений от ответчика к инициатору.

CreateSequence Exchange

Инициатор WCF передает сообщение CreateSequence с элементом Offer в HTTP-запросе и ожидает сообщение CreateSequenceResponse в HTTP-ответе. Ответчик WCF создаёт последовательность и передаёт CreateSequenceResponse сообщение с элементом Accept в HTTP-ответе.

Одностороннее сообщение

Для успешного завершения одностороннего обмена сообщениями инициатор WCF передает сообщение последовательности запросов по HTTP-запросу и получает автономное SequenceAcknowledgement сообщение в ответе HTTP. SequenceAcknowledgement должно подтвердить переданное сообщение.

WCF Responder может ответить на запрос подтверждением, сбоем или ответом с пустым телом и кодом состояния HTTP 202.

Двустороннее сообщение

Для успешного выполнения протокола обмена сообщениями двумя способами инициатор WCF передает сообщение последовательности запросов по HTTP-запросу и получает сообщение последовательности ответа по HTTP-ответу. Ответ должен содержать SequenceAcknowledgement, подтверждающее сообщение, передаваемое в последовательности запросов.

Компонент WCF может ответить на запрос, выдав ответное сообщение приложения, сообщение об ошибке или ответ с пустым телом и кодом состояния HTTP 202.

Из-за наличия односторонних сообщений и времени ответов приложения порядковый номер сообщения запроса и ответа не связаны друг с другом.

Повторная попытка ответов

WCF использует корреляцию HTTP-запроса-ответа для двусторонней корреляции протокола обмена сообщениями. Из-за этого инициатор WCF не прекращает попытки отправки запросов последовательности, когда сообщение последовательности запросов подтверждено, а прекращает, когда HTTP-ответ содержит SequenceAcknowledgement, ответ приложения или ошибку. Средство ответа WCF повторно отправляет ответы по HTTP-ответу запроса, с которым соотносится ответ.

CloseSequence Exchange

Получив все ответные сообщения последовательности и подтверждения для всех однонаправленных сообщений последовательности запросов, инициатор WCF передает сообщение CloseSequence для последовательности запросов по HTTP-запросу и ожидает HTTP-ответ с CloseSequenceResponse.

Закрытие последовательности запросов неявно закрывает последовательность ответа. Это означает, что инициатор WCF включает окончательную SequenceAcknowledgement последовательность ответа в CloseSequence сообщении, а последовательность ответа не имеет CloseSequence обмена.

Обработчик WCF гарантирует, что все ответы подтверждены и передает CloseSequenceResponse сообщение в HTTP-ответе.

Завершение последовательности обмена

После получения CloseSequenceResponse сообщения инициатор WCF передает TerminateSequence сообщение для последовательности запросов HTTP и ожидает TerminateSequenceResponse ответ HTTP.

CloseSequence Как и в обмене, завершение последовательности запросов неявно завершает последовательность ответа. Это означает, что инициатор WCF включает окончательную SequenceAcknowledgement последовательность ответа в TerminateSequence сообщении, а последовательность ответа не имеет TerminateSequence обмена.

Модуль-приемник WCF передает сообщение TerminateSequenceResponse через HTTP-ответ.

Запрос/Ответ, адресуемый инициатор

Привязка

WCF предоставляет шаблон обмена сообщениями с запросами с помощью двух последовательностей через один входящий и один исходящий HTTP-канал. Этот шаблон обмена сообщениями можно смешать с шаблоном обмена сообщениями инициатора Duplex, Addressable в ограниченной степени. WCF использует HTTP-запросы для передачи всех сообщений. Все ответы HTTP имеют пустой текст и код состояния HTTP 202.

CreateSequence Exchange

Инициатор WCF передает сообщение CreateSequence с элементом Offer по HTTP-запросу. WCF средство ответчика гарантирует, что CreateSequence имеет элемент Offer, затем создает последовательность и передает сообщение CreateSequenceResponse с элементом Accept.

Корреляция запросов и ответа

Ниже приведены все коррелированные запросы и ответы:

  • WCF гарантирует, что все сообщения запроса приложения содержат ссылку на конечную точку ReplyTo и ссылку MessageId.

  • WCF применяет ссылку на локальную конечную точку для каждого сообщения запроса приложения ReplyTo. Ссылка на локальную конечную точку — это CreateSequence сообщение ReplyTo для инициатора и CreateSequence сообщения To для ответа.

  • WCF гарантирует, что входящие сообщения запроса содержат MessageId и ReplyTo.

  • WCF гарантирует, что URI ссылки на конечную точку всех сообщений запроса приложения соответствуют ReplyTo ссылке на локальную конечную точку, как определено ранее.

  • WCF гарантирует, что все ответы имеют правильные RelatesTo и To заголовки после wsa правил корреляции запросов и ответов.