Compartilhar via

Protocolo de mensagem confiável versão 1.1

  • Artigo

Este tópico aborda os detalhes de implementação do Windows Communication Foundation (WCF) para o protocolo WS-ReliableMessaging de fevereiro de 2007 (versão 1.1) necessário para interoperação usando o transporte HTTP. O WCF segue a especificação WS-ReliableMessaging com as restrições e esclarecimentos explicados neste tópico. Observe que o protocolo WS-ReliableMessaging versão 1.1 é implementado a partir do .NET Framework 3.5.

O protocolo WS-ReliableMessaging de fevereiro de 2007 é implementado no WCF pelo ReliableSessionBindingElement.

Para conveniência, o tópico usa as seguintes funções:

  • Iniciador: o cliente que inicia a criação da sequência de mensagens WS-Reliable.

  • Respondente: o serviço que recebe as solicitações do iniciador.

Este documento usa os prefixos e namespaces na tabela a seguir.

Prefixo 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 ou WS-Policy 1.5)

Mensagens

Criação de sequência

O WCF implementa as mensagens CreateSequence e CreateSequenceResponse para estabelecer uma sequência de mensagens confiável. As seguintes restrições se aplicam:

  • B1101: o Iniciador do WCF usa a mesma referência de ponto de extremidade que ReplyTo, AcksTo e Offer/Endpoint da mensagem CreateSequence.

  • R1102: as referências do ponto de extremidade AcksTo, ReplyTo e Offer/Endpoint na mensagem CreateSequence devem ter valores de endereço com representações de cadeia de caracteres idênticas, de modo que correspondam ao octeto.

    • O Respondente do WCF verifica se a parte do URI das referências do ponto de extremidade AcksTo, ReplyTo e Endpoint são idênticos antes de criar uma sequência.

  • R1103: as referências de ponto de extremidade AcksTo, ReplyTo e Offer/Endpoint na mensagem CreateSequence devem ter o mesmo conjunto de parâmetros de referência.

    • O WCF não impõe, mas assume que os parâmetros de referência das referências de ponto de extremidade AcksTo, ReplyTo e Offer/Endpoint em CreateSequence são idênticos e usa parâmetros de referência da referência do ponto de extremidade ReplyTo para confirmações e mensagens de sequência inversa.

  • B1104: o Iniciador do WCF não gera o elemento Expires ou Offer/Expires opcional na mensagem CreateSequence.

  • B1105: ao acessar a mensagem CreateSequence, o Respondente do WCF usa o valor Expires no elemento CreateSequence como o valor Expires no elemento CreateSequenceResponse. Caso contrário, o Respondente do WCF lerá e ignorará os valores Expires e Offer/Expires.

  • B1106: ao acessar a mensagem CreateSequenceResponse, o Iniciador do WCF lê o valor Expires opcional, mas não o usa.

  • B1107: o Iniciador do WCF e o Respondente sempre geram o elemento IncompleteSequenceBehavior opcional nos elementos CreateSequence/Offer e CreateSequenceResponse.

  • B1108: o WCF usa apenas os valores DiscardFollowingFirstGap e NoDiscard no elemento IncompleteSequenceBehavior.

    • WS-ReliableMessaging introduz o mecanismo Offer para estabelecer as duas sequências correlacionadas inversas que formam uma sessão.

  • B1109: se CreateSequence contiver um elemento Offer, a única maneira de o Respondente do WCF rejeitar a sequência oferecida respondendo com um CreateSequenceResponse sem um elemento Accept.

  • B1110: se um Respondente de mensagens confiáveis rejeitar a sequência oferecida, o Iniciador do WCF falhará na sequência recém-estabelecida.

  • B1111: se CreateSequence não contiver um elemento Offer, o Respondente do WCF bidirecional rejeita a sequência oferecida respondendo com uma falha CreateSequenceRefused.

  • R1112: quando duas sequências inversas são estabelecidas usando o mecanismo Offer, a propriedade [address] da referência do ponto de extremidade CreateSequenceResponse/Accept/AcksTo deve corresponder ao URI de destino do byte por byte da mensagem CreateSequence.

  • R1113: quando duas sequências inversas são estabelecidas usando o mecanismo Offer, todas as mensagens em ambas as sequências que fluem do Iniciador para o Respondente devem ser enviadas para a mesma referência de ponto de extremidade.

O WCF usa WS-ReliableMessaging para estabelecer sessões confiáveis entre o Iniciador e o Respondente. A implementação de WS-ReliableMessaging do WCF fornece uma sessão confiável para padrões de mensagens duplex unidirecionais, de solicitação-resposta e duplex completo. O mecanismo Offer de WS-ReliableMessaging em CreateSequence e CreateSequenceResponse permite estabelecer duas sequências inversas correlacionadas e fornece um protocolo de sessão adequado para todos os pontos de extremidade de mensagem. Como o WCF fornece uma garantia de segurança para essa sessão, incluindo a proteção de ponta a ponta para a integridade da sessão, é prático garantir que as mensagens destinadas para a mesma parte cheguem ao mesmo destino. Isso também permite o “piggy-back” de confirmações de sequência em mensagens de aplicativo. Portanto, as restrições R1102, R1112 e R1113 se aplicam ao WCF.

Um exemplo de uma mensagem 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>

Um exemplo de uma mensagem 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>

Fechando uma sequência

O WCF usa as mensagens CloseSequence e CloseSequenceResponse para um desligamento iniciado pela fonte das mensagens confiáveis. O destino das mensagens confiáveis do WCF não inicia o desligamento e a fonte das mensagens confiáveis do WCF não dá suporte a um desligamento iniciado pelo destino das mensagens confiáveis. As seguintes restrições se aplicam:

  • B1201: a fonte das mensagens confiáveis do WCF sempre envia uma mensagem CloseSequence para desligar a sequência.

  • B1202: a fonte das mensagens confiáveis aguarda a confirmação de todo o intervalo de mensagens de sequência antes de enviar a mensagem CloseSequence.

  • B1203: a fonte das mensagens confiáveis sempre inclui o elemento LastMsgNumber opcional, a menos que a sequência não contenha mensagens.

  • R1204: o destino das mensagens confiáveis não deve iniciar o desligamento enviando uma mensagem CloseSequence.

  • B1205: ao receber uma mensagem CloseSequence, a fonte das mensagens confiáveis do WCF considera a sequência incompleta e envia uma falha.

Um exemplo de uma mensagem 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>

Exemplo de mensagem 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>

Terminação de sequência

O WCF usa principalmente o handshake TerminateSequence/TerminateSequenceResponse depois de concluir o handshake CloseSequence/CloseSequenceResponse. O destino das mensagens confiáveis do WCF não inicia a terminação e a fonte das mensagens confiáveis não dá suporte a uma terminação iniciada pelo destino das mensagens confiáveis. As seguintes restrições se aplicam:

  • B1301: o Iniciador do WCF só envia a mensagem TerminateSequence após a conclusão bem-sucedida do handshake CloseSequence/CloseSequenceResponse.

  • R1302: o WCF valida que o elemento LastMsgNumber é consistente em todas as mensagens CloseSequence e TerminateSequence em uma determinada sequência. Isso significa que LastMsgNumber não está presente em todas as mensagens CloseSequencee TerminateSequence ou está presente e idêntico em todas as mensagens CloseSequence e TerminateSequence.

  • B1303: ao receber uma mensagem TerminateSequence após o handshake CloseSequence/CloseSequenceResponse, o destino das mensagens confiáveis responde com uma mensagem TerminateSequenceResponse. Como a fonte das mensagens confiáveis tem a confirmação final antes de enviar a mensagem TerminateSequence, o destino das mensagens confiáveis sabe, sem dúvida, que a sequência termina e recupera recursos imediatamente.

  • B1304: ao receber uma mensagem TerminateSequence antes do handshake CloseSequence/CloseSequenceResponse, o destino das mensagens confiáveis do WCF responde com uma mensagem TerminateSequenceResponse. Se o destino das mensagens confiáveis determinar que não há inconsistências na sequência, o destino das mensagens confiáveis aguardará um tempo especificado pelo destino do aplicativo antes de recuperar recursos, para permitir ao cliente a chance de receber a confirmação final. Caso contrário, o destino das mensagens confiáveis recupera recursos imediatamente e indica ao destino do aplicativo que a sequência termina com dúvida ao gerar o evento Faulted.

Um exemplo de uma mensagem 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>

Exemplo de mensagem 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>

Sequências

Veja a seguir uma lista de restrições que se aplicam a sequências:

  • B1401: o WCF gera e acessa números de sequência não superiores ao valor inclusivo máximo de xs:long, 9223372036854775807.

Um exemplo de um cabeçalho Sequence.

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

Solicitar confirmação

O WCF usa o cabeçalho AckRequested como um mecanismo de keep alive.

Um exemplo de um cabeçalho AckRequested.

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

SequenceAcknowledgement

O WCF usa um mecanismo “piggy-back” para confirmações de sequência fornecidas no WS-Reliable Messaging. As seguintes restrições se aplicam:

  • R1601: quando duas sequências inversas são estabelecidas usando o mecanismo Offer, o cabeçalho SequenceAcknowledgement pode ser incluído em qualquer mensagem de aplicativo transmitida para o destinatário pretendido. O ponto de extremidade remoto deve ser capaz de acessar um cabeçalho com piggyback SequenceAcknowledgement.

  • B1602: o WCF não gera cabeçalhos SequenceAcknowledgement que contêm elementos Nack. O WCF valida que cada elemento Nack contém um número de sequência, mas, caso contrário, ignora o elemento e o valor Nack.

Um exemplo de um cabeçalho SequenceAcknowledgement.

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

Falhas de WS-ReliableMessaging

A seguir temos uma lista de restrições que se aplicam à implementação do WCF de falhas do WS-ReliableMessaging. As seguintes restrições se aplicam:

  • B1701: o WCF não gera falhas de MessageNumberRollover.

  • B1702: sobre SOAP 1.2, quando o ponto de extremidade de serviço atinge seu limite de conexão e não pode processar novas conexões, o WCF gera um subcódigo de falha de CreateSequenceRefused aninhado, netrm:ConnectionLimitReached, conforme mostrado no exemplo a seguir.

<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>

Falhas de WS-Addressing

Como WS-ReliableMessaging usa o WS-Addressing, a implementação de WS-ReliableMessaging do WCF pode gerar e transmitir falhas de WS-Addressing. Esta seção aborda as falhas de WS-Addressing que o WCF gera e transmite explicitamente na camada de WS-ReliableMessaging:

  • B1801: o WCF gera e transmite a falha Message Addressing Header Required quando um dos seguintes é verdadeiro:

    • Uma mensagem CreateSequence, CloseSequence ou TerminateSequence está sem um cabeçalho MessageId.

    • Uma mensagem CreateSequence, CloseSequence ou TerminateSequence está sem um cabeçalho ReplyTo.

    • Uma mensagem CreateSequenceResponse, CloseSequenceResponse ou TerminateSequenceResponse está sem um cabeçalho RelatesTo.

  • B1802: o WCF gera e transmite a falha Endpoint Unavailable para indicar que não há nenhum ponto de extremidade escutando que possa processar a sequência com base no exame dos cabeçalhos de endereçamento na mensagem CreateSequence.

Composição de protocolo

Composição com WS-Addressing

O WCF dá suporte a duas versões do WS-Addressing: WS-Addressing 2004/08 [WS-ADDR] e Recomendações do W3C WS-Addressing 1.0 [WS-ADDR-CORE] e [WS-ADDR-SOAP].

Embora a especificação de WS-ReliableMessaging mencione apenas WS-Addressing 2004/08, ela não restringe a versão do WS-Addressing a ser usada. Veja a seguir uma lista de restrições que se aplicam ao WCF:

  • R2101: WS-Addressing 2004/08 e WS-Addressing 1.0 podem ser usados com WS-Reliable Messaging.

  • R2102: uma única versão do WS-Addressing deve ser usada em uma determinada sequência de WS-ReliableMessaging ou um par de sequências inversas correlacionadas usando o mecanismo Offer.

Composição com SOAP

O WCF dá suporte ao uso de SOAP 1.1 e SOAP 1.2 com WS-Reliable Messaging.

Composição com WS-Security e WS-SecureConversation

O WCF fornece proteção para sequências de WS-ReliableMessaging usando Transporte seguro (HTTPS), composição com WS-Security e composição com WS-Secure Conversation. O protocolo WS-ReliableMessaging 1.1, protocolo WS-Security 1.1 e WS-Secure Conversation 1.3 devem ser usados juntos. Veja a seguir uma lista de restrições que se aplicam ao WCF:

  • R2301: para proteger a integridade de uma sequência de WS-ReliableMessaging, além da integridade e confidencialidade de mensagens individuais, o WCF exige que WS-Secure Conversation seja usado.

  • R2302: a sessão de AWS-Secure Conversation deve ser estabelecida antes de estabelecer a(s) sequência(s) de WS-ReliableMessaging.

  • R2303: se o tempo de vida da sequência de WS-ReliableMessaging exceder o tempo de vida da sessão de WS-Secure Conversation, o SecurityContextToken estabelecido pelo uso de WS-Secure Conversation deve ser renovado usando a associação de WS-Secure Conversation Renewal correspondente.

  • B2304: a sequência WS-ReliableMessaging ou um par de sequências inversas correlacionadas são sempre associadas a uma única sessão de WS-SecureConversation.

  • R2305: quando composto com WS-Secure Conversation, o respondente do WCF requer que a mensagem CreateSequence contenha o elemento wsse:SecurityTokenReference e o cabeçalho wsrm:UsesSequenceSTR.

Um exemplo de um cabeçalho UsesSequenceSTR.

<wsrm:UsesSequenceSTR></wsrm:UsesSequenceSTR>

Composição com sessões SSL/TLS

O WCF não dá suporte à composição com sessões SSL/TLS:

  • B2401: o WCF não gera o cabeçalho wsrm:UsesSequenceSSL.

  • R2402: um Iniciador de mensagens confiáveis não deve enviar uma mensagem CreateSequence com um cabeçalho wsrm:UsesSequenceSSL para um Respondente do WCF.

Composição com WS-Policy

O WCF dá suporte a duas versões do WS-Policy: WS-Policy 1.2 e WS-Policy 1.5.

Declaração de WS-Policy do WS-ReliableMessaging

O WCF usa Declaração de WS-Policy do WS-ReliableMessaging wsrm:RMAssertion para descrever os recursos de pontos de extremidade. Veja a seguir uma lista de restrições que se aplicam ao WCF:

  • B3001: o WCF anexa a Declaração de WS-Policy wsrmn:RMAssertion a elementos wsdl:binding. O WCF dá suporte a anexos para os elementos wsdl:binding e wsdl:port.

  • B3002: o WCF nunca gera a marca wsp:Optional.

  • B3003: ao acessar a Declaração de WS-Policy wsrmp:RMAssertion, o WCF ignora a marca wsp:Optional e trata a política WS-RM como obrigatória.

  • R3004: como o WCF não compõe com sessões SSL/TLS, o WCF não aceita a política que especifica wsrmp:SequenceTransportSecurity.

  • B3005: o WCF sempre gera o elemento wsrmp:DeliveryAssurance.

  • B3006: o WCF sempre especifica a garantia de entrega wsrmp:ExactlyOnce.

  • B3007: o WCF gera e lê as seguintes propriedades da declaração de WS-ReliableMessaging e fornece controle sobre elas no WCFReliableSessionBindingElement:

    • netrmp:InactivityTimeout

    • netrmp:AcknowledgementInterval

    Um exemplo de um 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>

Extensão de WS-ReliableMessaging de controle de fluxo

O WCF usa a extensibilidade de WS-ReliableMessaging para fornecer controle mais rigoroso adicional opcional sobre o fluxo de mensagens de sequência.

O controle de fluxo é habilitado definindo a propriedade ReliableSessionBindingElement.FlowControlEnabled como true. Veja a seguir uma lista de restrições que se aplicam ao WCF:

  • B4001: quando o controle de fluxo de mensagens confiáveis está habilitado, o WCF gera um elemento netrm:BufferRemaining na extensibilidade do elemento do cabeçalho SequenceAcknowledgement, conforme mostrado no exemplo a seguir.

    <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: mesmo quando o controle de fluxo de mensagens confiáveis está habilitado, o WCF não requer um elemento netrm:BufferRemaining no cabeçalho SequenceAcknowledgement.

  • B4003: o destino de mensagens confiáveis do WCF usa netrm:BufferRemaining para indicar quantas novas mensagens o destino pode armazenar em buffer.

  • B4004: quando o controle de fluxo de mensagens confiáveis está habilitado, a fonte de mensagens confiáveis do WCF usa o valor de netrm:BufferRemaining para limitar a transmissão de mensagens.

  • B4005: o WCF gera valores inteiros netrm:BufferRemaining entre 0 e 4096 inclusive e lê valores inteiros entre 0 e o valor 214748364 maxInclusive de xs:int inclusive.

Padrões de troca de mensagens

Esta seção descreve o comportamento do WCF quando WS-ReliableMessaging é usado para diferentes padrões de troca de mensagens. Para cada padrão de troca de mensagens, os dois cenários de implantações a seguir são considerados:

  • Iniciador não endereçável: o iniciador está atrás do firewall; o Respondente pode entregar mensagens ao Iniciador somente em respostas HTTP.

  • Iniciador endereçável: solicitações HTTP podem ser enviadas ao Iniciador e ao Respondente; em outras palavras, duas conexões HTTP inversas podem ser estabelecidas.

Iniciador unidirecional não endereçável

Associação

O WCF fornece um padrão de troca de mensagens unidirecionais usando uma sequência em um canal HTTP. O WCF usa solicitações HTTP para transmitir todas as mensagens do Iniciador para o Respondente e respostas HTTP para transmitir todas as mensagens do Respondente para o Iniciador.

Troca de CreateSequence

O Iniciador do WCF transmite uma mensagem CreateSequence sem nenhum elemento Offer em uma solicitação HTTP e espera a mensagem CreateSequenceResponse na resposta HTTP. O Respondente do WCF cria uma sequência e transmite a mensagem CreateSequenceResponse sem nenhum elemento Accept na resposta HTTP.

SequenceAcknowledgement

O Iniciador do WCF processa confirmações na resposta de todas as mensagens, exceto a mensagem CreateSequence e as mensagens de falha. O Respondente do WCF sempre transmite uma confirmação autônoma na resposta HTTP para todas as sequências e mensagens AckRequested.

Troca de CloseSequence

O Iniciador do WCF transmite uma mensagem CloseSequence sem uma solicitação HTTP e espera a mensagem CreateSequenceResponse na resposta HTTP. O Respondente do WCF transmite a mensagem CloseSequenceResponse na resposta HTTP.

Troca TerminateSequence

O Iniciador do WCF transmite uma mensagem TerminateSequence em uma solicitação HTTP e espera a mensagem TerminateSequenceResponse na resposta HTTP. O Respondente do WCF transmite a mensagem TerminateSequenceResponse na resposta HTTP.

Iniciador unidirecional endereçável

Associação

O WCF fornece um padrão de troca de mensagens unidirecionais usando uma sequência em um canal HTTP de entrada e um de saída. O WCF usa as solicitações HTTP para transmitir todas as mensagens. Todas as respostas HTTP têm um corpo vazio e um código de status HTTP 202.

Troca de CreateSequence

O Iniciador do WCF transmite uma mensagem CreateSequence sem nenhum elemento Offer em uma solicitação HTTP. O Respondente do WCF cria uma sequência e transmite a mensagem CreateSequenceResponse sem nenhum elemento Accept em uma solicitação HTTP.

Iniciador duplex endereçável

Associação

O WCF fornece um padrão de troca de mensagens bidirecional totalmente assíncrono usando duas sequências em um canal HTTP de entrada e um de saída. Esse padrão de troca de mensagens pode ser misturado com Request/Reply, o padrão de troca de mensagens do Iniciador Addressable de maneira limitada. O WCF usa as solicitações HTTP para transmitir todas as mensagens. Todas as respostas HTTP têm um corpo vazio e um código de status HTTP 202.

Troca de CreateSequence

O Iniciador do WCF transmite uma mensagem CreateSequence com um elemento Offer em uma solicitação HTTP. O Respondente do WCF garante que o CreateSequence tenha um elemento Offer, em seguida, cria uma sequência e transmite a mensagem CreateSequenceResponse com um elemento Accept.

Tempo de vida da sequência

O WCF trata as duas sequências como uma sessão totalmente duplex.

Ao gerar uma falha que causa falha em uma sequência, o WCF espera que o ponto de extremidade remoto cause falha nas duas sequências. Ao ler uma falha que causa falha em uma sequência, o WCF causa falha em ambas as sequências.

O WCF pode fechar sua sequência de saída e continuar processando mensagens em sua sequência de entrada. Por outro lado, o WCF pode processar o fechamento da sequência de entrada e continuar enviando mensagens em sua sequência de saída.

Solicitação-resposta e Iniciador unidirecional não endereçável

Associação

O WCF fornece um padrão de troca de mensagens unidirecionais e de solicitação-resposta usando duas sequências em um canal HTTP. O WCF usa solicitações HTTP para transmitir todas as mensagens do Iniciador para o Respondente e respostas HTTP para transmitir todas as mensagens do Respondente para o Iniciador.

Troca de CreateSequence

O Iniciador do WCF transmite uma mensagem CreateSequence com um elemento Offer em uma solicitação HTTP e espera a mensagem CreateSequenceResponse na resposta HTTP. O Respondente do WCF cria uma sequência e transmite a mensagem CreateSequenceResponse com um elemento Accept na resposta HTTP.

Mensagem unidirecional

Para concluir uma troca de mensagens unidirecionais com sucesso, o Iniciador do WCF transmite uma mensagem de sequência de solicitação na solicitação HTTP e recebe uma mensagem SequenceAcknowledgement autônoma na resposta HTTP. O SequenceAcknowledgement deve confirmar a mensagem transmitida.

O Respondente do WCF pode responder à solicitação com uma confirmação, uma falha ou uma resposta com um corpo vazio e um código de status HTTP 202.

Mensagens bidirecionais

Para concluir um protocolo de troca de mensagens bidirecional com sucesso, o Iniciador do WCF transmite uma mensagem de sequência de solicitação na solicitação HTTP e recebe uma mensagem de sequência de respostas na resposta HTTP. A resposta deve conter um SequenceAcknowledgement confirmando a mensagem de sequência de solicitações transmitida.

O Respondente do WCF pode responder à solicitação com uma resposta de aplicativo, uma falha ou uma resposta com um corpo vazio e um código de status HTTP 202.

Devido à presença de mensagens unidirecionais e ao tempo das respostas do aplicativo, o número de sequência da mensagem de sequências de solicitação e o número da sequência da mensagem de resposta não têm correlação.

Repetindo respostas

O WCF depende da correlação de solicitação-resposta HTTP para correlação de protocolo de troca de mensagens bidirecionais. Por isso, o Iniciador do WCF não para de repetir uma mensagem de sequência de solicitações quando a mensagem de sequência de solicitações é reconhecida, mas sim quando a resposta HTTP carrega uma SequenceAcknowledgement, uma mensagem do aplicativo ou uma falha. O Respondente do WCF tenta novamente as respostas na resposta HTTP da solicitação à qual a resposta está correlacionada.

Troca de CloseSequence

Depois de receber todas as mensagens de sequência de resposta e confirmações para todas as mensagens de sequência de solicitações unidirecionais, o Iniciador do WCF transmite uma mensagem CloseSequence para a sequência de solicitações em uma solicitação HTTP e espera a CloseSequenceResponse na resposta HTTP.

Fechar a sequência de solicitações fecha implicitamente a sequência de resposta. Isso significa que o Iniciador do WCF inclui a Final SequenceAcknowledgement da sequência de resposta na mensagem CloseSequence e a sequência de resposta não tem uma troca CloseSequence.

O Respondente do WCF garante que todas as respostas sejam reconhecidas e transmita a mensagem CloseSequenceResponse na resposta HTTP.

Troca TerminateSequence

Depois de receber a mensagem CloseSequenceResponse, o Iniciador do WCF transmite uma mensagem TerminateSequence para a sequência de solicitações em uma solicitação HTTP e espera a TerminateSequenceResponse na resposta HTTP.

Assim como a troca CloseSequence, encerrar a sequência de solicitações encerra implicitamente a sequência de resposta. Isso significa que o Iniciador do WCF inclui a final SequenceAcknowledgement da sequência de resposta na mensagem TerminateSequence e a sequência de resposta não tem uma troca TerminateSequence.

O Respondente do WCF transmite a mensagem TerminateSequenceResponse na resposta HTTP.

Iniciador de solicitação/resposta endereçável

Associação

O WCF fornece um padrão de troca de mensagens de solicitação-resposta usando duas sequências em um canal HTTP de entrada e um de saída. Esse padrão de troca de mensagens pode ser misturado com o padrão de troca de mensagens do Iniciador Duplex, Addressable de maneira limitada. O WCF usa as solicitações HTTP para transmitir todas as mensagens. Todas as respostas HTTP têm um corpo vazio e um código de status HTTP 202.

Troca de CreateSequence

O Iniciador do WCF transmite uma mensagem CreateSequence com um elemento Offer em uma solicitação HTTP. O Respondente do WCF garante que o CreateSequence tenha um elemento Offer, em seguida, cria uma sequência e transmite a mensagem CreateSequenceResponse com um elemento Accept.

Correlação de solicitação/resposta

O seguinte se aplica a todas as solicitações e respostas correlacionadas:

  • O WCF garante que todas as mensagens de solicitação de aplicativo possuam uma referência de ponto de extremidade ReplyTo e um MessageId.

  • O WCF aplica a referência de ponto de extremidade local como ReplyTo de cada mensagem de solicitação de aplicativo. A referência de ponto de extremidade local é ReplyTo da mensagem CreateSequence para o Iniciador e To da mensagem CreateSequence para o Respondente.

  • O WCF garante que as mensagens de solicitação de entrada têm um MessageId e um ReplyTo.

  • O WCF garante que o URI da referência do ponto de extremidade ReplyTo de todas as mensagens de solicitação de aplicativo corresponda à referência do ponto de extremidade local, conforme definido anteriormente.

  • O WCF garante que todas as respostas têm os cabeçalhos RelatesTo e To corretos seguindo as regras de correlação de solicitação/resposta wsa.