Протокол надежного обмена сообщениями, версия 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 и Offer/EndpointсообщениеReplyToAcksTo.

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

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

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

    • WCF не применяется, но предполагает, что ссылочные параметры AcksToReplyToOffer/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 содержит элемент, то один из способов WCF Responder отклоняет предложенную Offer последовательность, отвечая на запрос без AcceptCreateSequenceResponse элемента.

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

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

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

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

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

  • 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 . Если точка назначения системы надежного обмена сообщениями определяет, что в последовательности нет противоречий, она, прежде чем высвободить ресурсы, ждет в течение времени, заданного точкой назначения приложения, чтобы клиент мог получить последнее подтверждение. В противном случае точка назначения системы надежного обмена сообщениями сразу же высвобождает ресурсы и сообщает точке назначения приложения, что последовательность завершена, но не гарантированно, вызывая для этого событие 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 использует механизм "piggy-back" для подтверждения последовательности, предоставляемых в WS-Reliable Messaging. Действуют следующие ограничения.

  • 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-Адресации. В этом разделе рассматриваются ошибки WS-Адресации, которые 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-Адресация 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-ReliableMessaging можно использовать как версию WS-Addressing 2004/08, так и версию WS-Addressing 1.0.

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

Сочетаемость с SOAP

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

Сочетаемость с WS-Security и WS-SecureConversation

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

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

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

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

  • Последовательность 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 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

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

SequenceAcknowledgement

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

Обмен сообщениями CloseSequence

Инициатор WCF передает CloseSequence сообщение по HTTP-запросу и ожидает CreateSequenceResponse сообщение в ответе HTTP. Ответ WCF передает CloseSequenceResponse сообщение по HTTP-ответу.

Обмен сообщениями TerminateSequence

Инициатор WCF передает TerminateSequence сообщение по HTTP-запросу и ожидает TerminateSequenceResponse сообщение в ответе HTTP. Ответ WCF передает TerminateSequenceResponse сообщение по HTTP-ответу.

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

Привязка

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

Обмен сообщениями CreateSequence

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

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

Привязка

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

Обмен сообщениями CreateSequence

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

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

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

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

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

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

Привязка

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

Обмен сообщениями CreateSequence

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

Односторонний обмен сообщениями

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

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

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

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

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

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

Повторные попытки ответов

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

Обмен сообщениями CloseSequence

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

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

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

Обмен сообщениями TerminateSequence

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

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

Ответ WCF передает TerminateSequenceResponse сообщение по HTTP-ответу.

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

Привязка

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

Обмен сообщениями CreateSequence

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

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

Следующие действия относятся ко всем связанным запросам и ответам.

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

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

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

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

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