Compartir a través de

Protocolo de mensajería confiable versión 1.1

Este tema cubre los detalles de implementación de Windows Communication Foundation (WCF) para el protocolo WS-ReliableMessaging de febrero de 2007 (versión 1.1) necesario para la interoperación mediante el transporte HTTP. WCF sigue la especificación WS-ReliableMessaging con las restricciones y aclaraciones explicadas en este tema. Tenga en cuenta que la versión 1.1 del protocolo WS-ReliableMessaging se implementa a partir de .NET Framework versión 3.5.

ReliableSessionBindingElement implementa el protocolo WS-ReliableMessaging de febrero de 2007 en WCF.

Para su comodidad, el tema utiliza las siguientes funciones:

  • Iniciador: el cliente que inicia la creación de la secuencia de mensajes WS-Reliable.

  • Respondedor: el servicio que recibe las solicitudes del iniciador.

En este documento, se utilizan los prefijos y espacios de nombres de la tabla siguiente.

Prefijo

Espacio de nombres

wsrm

http://docs.oasis-open.org/ws-rx/wsrm/200702

netrm

https://schemas.microsoft.com/ws/2006/05/rm

s

http://www.w3.org/2003/05/soap-envelope

wsa

https://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

https://schemas.microsoft.com/ws-rx/wsrmp/200702

wsp

(Directiva WS-Policy 1.2 o WS-Policy 1.5)

Mensajería

Creación de secuencias

WCF implementa mensajes CreateSequence y CreateSequenceResponse para establecer una secuencia de mensajería de confianza. Las siguientes restricciones son aplicables:

  • B1101: el iniciador de WCF utiliza la misma referencia de extremo que ReplyTo, AcksTo y Offer/Endpoint del mensaje CreateSequence.

  • R1102: las referencias de extremo AcksTo, ReplyTo y Offer/Endpoint en el mensaje CreateSequence deben tener valores de dirección con representaciones de cadena idénticas, de tal modo que coincidan por octetos.

    • El respondedor de WCF comprueba que la parte del URI de las referencias de extremo AcksTo, ReplyTo y Endpoint sean idénticas antes de crear una secuencia.

  • R1103: las referencias de extremo AcksTo, ReplyTo y Offer/Endpoint en el mensaje CreateSequence deberían tener el mismo conjunto de parámetros de referencia.

    • WCF no exige, pero supone que los parámetros de las referencias de extremo AcksTo, ReplyTo y Offer/Endpoint en CreateSequence son idénticas y utiliza los parámetros de referencia de la referencia de extremo ReplyTo para las confirmaciones y los mensajes de secuencia inversa.

  • B1104: el iniciador de WCF no genera el elemento opcional Expires o Offer/Expires en el mensaje CreateSequence.

  • B1105: al tener acceso al mensaje CreateSequence, el respondedor de WCF utiliza el valor Expires del elemento CreateSequence como el valor Expires del elemento CreateSequenceResponse. De lo contrario, el respondedor de WCF lee y pasa por alto los valores Expires y Offer/Expires.

  • B1106: al tener acceso al mensaje CreateSequenceResponse, el iniciador de WCF lee el valor opcional Expires, pero no lo utiliza.

  • B1107: el iniciador y respondedor de WCF siempre generan el elemento opcional IncompleteSequenceBehavior en los elementos CreateSequence/Offer y CreateSequenceResponse.

  • B1108: WCF solo utiliza los valores DiscardFollowingFirstGap y NoDiscard en el elemento IncompleteSequenceBehavior.

    • WS-ReliableMessaging utiliza el mecanismo Offer para establecer las dos secuencias correlacionadas inversas que forman una sesión.

  • B1109: si CreateSequence contiene un elemento Offer, el respondedor unidireccional de WCF rechaza la secuencia proporcionada respondiendo con una CreateSequenceResponse sin un elemento Accept.

  • B1110: si un respondedor de mensajería de confianza rechaza la secuencia proporcionada, el iniciador de WCF produce un error en la secuencia recientemente establecida.

  • B1111: si CreateSequence no contiene un elemento Offer, el respondedor bidireccional de WCF rechaza la secuencia proporcionada respondiendo con un error de CreateSequenceRefused.

  • R1112: cuando dos secuencias inversas se establecen utilizando el mecanismo Offer, la propiedad [address] de la referencia de extremo CreateSequenceResponse/Accept/AcksTo debe coincidir con el URI de destino del mensaje CreateSequence byte a byte.

  • R1113: cuando dos secuencias inversas se establecen utilizando el mecanismo Offer, todos los mensajes en ambas secuencias que fluyen desde el iniciador hasta el respondedor se deben enviar a la misma referencia de extremo.

WCF utiliza WS-ReliableMessaging para establecer sesiones confiables entre el iniciador y el respondedor. La implementación de WS-ReliableMessaging de WCF proporciona una sesión confiable para modelos de mensajería dúplex completa y de solicitud-respuesta unidireccional. El mecanismo Offer de WS-ReliableMessaging en CreateSequence y CreateSequenceResponse le permite establecer dos secuencias inversas correlacionadas y proporciona un protocolo de sesión que es apto para todos los extremos de mensajes. Dado que WCF proporciona una garantía de seguridad para este tipo de sesiones, incluyendo protección de un extremo a otro para la integridad de la sesión, es práctico asegurar que los mensajes dirigidos a la misma parte lleguen al mismo destino. Esto también permite el “apoyo a caballo” de confirmaciones de secuencias en mensajes de aplicaciones. Por consiguiente, las restricciones R1102, R1112 y R1113 se aplican a WCF.

Ejemplo de mensaje 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>

Ejemplo de mensaje 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>

Cierre de una secuencia

WCF utiliza los mensajes CloseSequenceResponse y CloseSequence para llevar a cabo un cierre iniciado por el origen de la mensajería de confianza. El destino de la mensajería de confianza de WCF no inicia el cierre y el origen de la mensajería de confianza de WCF no admite un cierre iniciado por el destino de la mensajería de confianza. Las siguientes restricciones son aplicables:

  • B1201: el origen de la mensajería de confianza de WCF siempre envía un mensaje CloseSequence para cerrar la secuencia.

  • B1202: el origen de la mensajería de confianza espera la confirmación del intervalo completo de mensajes de secuencia antes de enviar el mensaje CloseSequence.

  • B1203: el origen de la mensajería de confianza siempre incluye el elemento opcional LastMsgNumber, a menos que la secuencia no contenga mensajes.

  • R1204: el destino de la mensajería de confianza no debe iniciar el cierre mediante el envío de un mensaje CloseSequence.

  • B1205: tras recibir un mensaje CloseSequence, el origen de la mensajería de confianza de WCF considera la secuencia incompleta y envía un error.

Ejemplo de mensaje 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>
Example CloseSequenceResponse message:
<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>

Finalización de secuencia

WCF utiliza principalmente el protocolo de enlace TerminateSequence/TerminateSequenceResponse después de completar el protocolo de enlace CloseSequence/CloseSequenceResponse. El destino de la mensajería de confianza de WCF no inicia la finalización y el origen de la mensajería de confianza no admite una finalización de la mensajería de confianza iniciada por el destino. Las siguientes restricciones son aplicables:

  • B1301: el iniciador de WCF solo envía el mensaje TerminateSequence después de la finalización correcta del protocolo de enlace CloseSequence/CloseSequenceResponse.

  • R1302: WCF valida que el elemento LastMsgNumber sea coherente en todos los mensajes TerminateSequence y CloseSequence para una secuencia determinada. Esto significa que LastMsgNumber no está presente en todos los mensajes TerminateSequence y CloseSequence, o está presente y es idéntico en todos los mensajes TerminateSequence y CloseSequence.

  • B1303: al recibir un mensaje TerminateSequence después del protocolo de enlace CloseSequence/CloseSequenceResponse, el destino de la mensajería de confianza responde con un mensaje TerminateSequenceResponse. Puesto que el origen de la mensajería de confianza recibe la confirmación definitiva antes de enviar el mensaje TerminateSequence, el destino de la mensajería de confianza sabe sin duda que finaliza la secuencia y reclama recursos inmediatamente.

  • B1304: al recibir un mensaje TerminateSequence antes del protocolo de enlace CloseSequence/CloseSequenceResponse, el destino de la mensajería de confianza de WCF responde con un mensaje TerminateSequenceResponse. Si el destino de la mensajería de confianza determina que no hay incoherencias en la secuencia, el destino de la mensajería de confianza espera durante un tiempo especificado por el destino de la aplicación antes de reclamar recursos, para permitir al cliente que reciba la confirmación final. De lo contrario, el destino de la mensajería de confianza reclama recursos inmediatamente e indica al destino de la aplicación que la secuencia finaliza de manera dudosa iniciando el evento Faulted.

Ejemplo de mensaje 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>
Example TerminateSequenceResponse message:
<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>

Secuencias

A continuación, se muestra una lista de restricciones que se aplican a las secuencias:

  • B1401: WCF genera y tiene acceso a números de secuencia no superiores al valor máximo incluido de xs:long, 9223372036854775807.

Ejemplo de encabezado 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 confirmación

WCF utiliza el encabezado AckRequested como un mecanismo de supervivencia.

Ejemplo de encabezado AckRequested.

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

SequenceAcknowledgement

WCF utiliza un mecanismo de "apoyo a caballo" para las confirmaciones de secuencias proporcionadas en la mensajería de confianza de WS. Las siguientes restricciones son aplicables:

  • R1601: cuando dos secuencias inversas se establecen utilizando el mecanismo Offer, el encabezado SequenceAcknowledgement puede estar incluido en cualquier mensaje de aplicación transmitido al destinatario previsto. El extremo remoto debe poder tener acceso a un encabezado SequenceAcknowledgement superpuesto.

  • B1602: WCF no genera encabezados SequenceAcknowledgement que contengan elementos Nack. WCF valida que cada elemento Nack contenga un número de secuencia, pero, de lo contrario, omite el elemento Nack y su valor.

Ejemplo de encabezado SequenceAcknowledgement.

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

Errores de WS-ReliableMessaging

A continuación, se muestra una lista de restricciones que se aplican a la implementación de WCF de errores de WS-ReliableMessaging. Las siguientes restricciones son aplicables:

  • B1701: WCF no genera errores MessageNumberRollover.

  • B1702: sobre SOAP 1.2, cuando el extremo de servicio alcanza su límite de conexiones y no puede procesar nuevas conexiones, WCF genera un subcódigo de error CreateSequenceRefused anidado, netrm:ConnectionLimitReached, como se muestra en el siguiente ejemplo.

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

Errores WS-Addressing

Dado que WS-ReliableMessaging utiliza WS-Addressing, la implementación de WS-ReliableMessaging de WCF puede generar y transmitir errores de WS-Addressing. Esta sección cubre los errores de WS-Addressing que WCF genera explícitamente y transmite en la capa de WS-ReliableMessaging:

  • B1801: WCF genera y transmite el error Message Addressing Header Required cuando una de las siguientes situaciones es verdadera:

    • A un mensaje CreateSequence, CloseSequence, o TerminateSequence le falta un encabezado MessageId.

    • A un mensaje CreateSequence, CloseSequence, o TerminateSequence le falta un encabezado ReplyTo.

    • A un mensaje CreateSequenceResponse, CloseSequenceResponse, o TerminateSequenceResponse le falta un encabezado RelatesTo.

  • B1802:: WCF genera y transmite el error Endpoint Unavailable para indicar que no hay ningún extremo a la escucha que pueda procesar la secuencia a partir del examen de los encabezados de direccionamiento del mensaje CreateSequence.

Composición de protocolos

Composición con WS-Addressing

WCF admite dos versiones de WS-Addressing: WS-Addressing 2004/08 [WS-ADDR] y las recomendaciones de WS-Addressing 1.0 de W3C [WS-ADDR-CORE] y [WS-ADDR-SOAP].

Aunque la especificación de WS-ReliableMessaging solo menciona WS-Addressing 2004/08, no restringe la versión de WS-Addressing que se ha de utilizar. A continuación, se muestra una lista de restricciones que se aplican a WCF:

  • R2101: WS-Addressing 2004/08 y WS-Addressing 1.0 se pueden utilizar con la mensajería de confianza de WS.

  • R2102: se debe utilizar una única versión de WS-Addressing a lo largo de una secuencia de WS-ReliableMessaging determinada o un par de secuencias inversas correlacionadas mediante el mecanismo Offer.

Composición con SOAP

WCF admite el uso de SOAP 1.1 y SOAP 1.2 con la mensajería de confianza de WS.

Composición con WS-Security y WS-SecureConversation

WCF proporciona protección para secuencias de WS-ReliableMessaging mediante el transporte seguro (HTTPS), la composición con WS-Security y la composición con WS-Secure Conversation. Los protocolos WS-ReliableMessaging 1.1, WS-Security 1.1 y WS-Secure Conversation 1.3 deberían utilizarse conjuntamente. A continuación se muestra una lista de restricciones que se aplican a WCF:

  • R2301: para proteger la integridad de una secuencia de WS-ReliableMessaging además de la integridad y confidencialidad de los mensajes individuales, WCF requiere que se utilice WS-Secure Conversation.

  • R2302: una sesión de WS-Secure Conversation se debe establecer antes de establecer las secuencias de WS-ReliableMessaging.

  • R2303: si la duración de la secuencia de WS-ReliableMessaging supera la duración de la sesión de WS-Secure Conversation, el SecurityContextToken establecido mediante WS-Secure Conversation se debe renovar utilizando el enlace de renovación de WS-Secure Conversation correspondiente.

  • B2304: La secuencia de WS-ReliableMessaging o un par de secuencias inversas correlacionadas siempre se enlazan a una única sesión de WS-SecureConversation.

  • R2305: cuando se compone con WS-Secure Conversation, el respondedor de WCF requiere que el mensaje CreateSequence contenga el elemento wsse:SecurityTokenReference y el encabezado wsrm:UsesSequenceSTR.

Ejemplo de encabezado UsesSequenceSTR.

<wsrm:UsesSequenceSTR></wsrm:UsesSequenceSTR>

Composición con sesiones de SSL/TLS

WCF no admite la composición con sesiones de SSL/TLS:

  • B2401: WCF no genera el encabezado wsrm:UsesSequenceSSL.

  • R2402: un iniciador de la mensajería de confianza no debe enviar un mensaje CreateSequence con un encabezado wsrm:UsesSequenceSSL a un respondedor de WCF.

Composición con WS-Policy

WCF admite dos versiones de WS-Policy: WS-Policy 1.2 y WS-Policy 1.5.

Aserción de WS-Policy de WS-ReliableMessaging

WCF utiliza la aserción de WS-Policy de WS-ReliableMessaging wsrm:RMAssertion para describir funciones de extremos. A continuación se muestra una lista de restricciones que se aplican a WCF:

  • B3001: WCF adjunta la aserción de WS-Policy wsrmn:RMAssertion a elementos de wsdl:binding. WCF admite datos adjuntos a elementos de wsdl:binding y wsdl:port.

  • B3002: WCF nunca genera la etiqueta wsp:Optional.

  • B3003: al tener acceso la aserción de WS-Policy wsrmp:RMAssertion, WCF omite la etiqueta wsp:Optional y trata la directiva WS-RM como obligatoria.

  • R3004: puesto que WCF no compone con sesiones de SSL/TLS, WCF no acepta ninguna directiva que especifique wsrmp:SequenceTransportSecurity.

  • B3005: WCF siempre genera el elemento wsrmp:DeliveryAssurance.

  • B3006: WCF siempre especifica la garantía de entrega wsrmp:ExactlyOnce.

  • B3007: WCF genera y lee las siguientes propiedades de la aserción de WS-ReliableMessaging y proporciona control sobre ellas en el elemento ReliableSessionBindingElement de WCF:

    • netrmp:InactivityTimeout

    • netrmp:AcknowledgementInterval

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

Extensión de WS-ReliableMessaging de control de flujo

WCF utiliza la extensibilidad de WS-ReliableMessaging para proporcionar un mayor control adicional y opcional sobre el flujo de mensajes de secuencias.

El control de flujo se habilita estableciendo en true la propiedad boolean FlowControlEnabled del ReliableSessionBindingElement. A continuación se muestra una lista de restricciones que se aplican a WCF:

  • B4001: cuando está habilitado el control de flujo de la mensajería de confianza, WCF genera un elemento netrm:BufferRemaining en la extensibilidad de elementos del encabezado SequenceAcknowledgement, tal y como se muestra en el siguiente ejemplo.

    <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: incluso cuando está habilitado el control de flujo de la mensajería de confianza, WCF no requiere un elemento netrm:BufferRemaining en el encabezado SequenceAcknowledgement.

  • B4003: el destino de la mensajería de confianza de WCF utiliza netrm:BufferRemaining para indicar cuántos mensajes nuevos puede almacenar en búfer.

  • B4004: cuando está habilitado el control de flujo de la mensajería de confianza, el origen de la mensajería de confianza de WCF utiliza el valor de netrm:BufferRemaining para limitar la transmisión de mensajes.

  • B4005: WCF genera valores enteros de netrm:BufferRemaining entre 0 y 4.096, ambos incluidos, y lee valores enteros entre 0 y el valor maxInclusive 214748364 de xs:int.

Patrones de intercambio de mensajes

En esta sección se describe el comportamiento de WCF cuando se utiliza WS-ReliableMessaging para modelos de intercambio de mensajes diferentes. Para cada modelo de intercambio de mensajes, se consideran los dos escenarios de implementación siguientes:

  • Iniciador no direccionable: el iniciador está tras un firewall; el respondedor solo puede entregar mensajes al iniciador mediante respuestas HTTP.

  • Iniciador direccionable: el iniciador y el respondedor pueden enviar solicitudes HTTP; en otras palabras, se pueden establecer dos conexiones HTTP inversas.

Iniciador unidireccional no direccionable

Enlace

WCF proporciona un modelo de intercambio de mensajes unidireccional utilizando una secuencia sobre un canal HTTP. WCF utiliza las solicitudes HTTP para transmitir todos los mensajes desde el iniciador hasta el respondedor y respuestas HTTP para transmitir todos los mensajes desde el respondedor hasta el iniciador.

CreateSequence Exchange

El iniciador de WCF transmite un mensaje CreateSequence sin elemento Offer en una solicitud HTTP y espera el mensaje CreateSequenceResponse en la respuesta HTTP. El respondedor de WCF crea una secuencia y transmite el mensaje CreateSequenceResponse sin elemento Accept en la respuesta HTTP.

SequenceAcknowledgement

El iniciador de WCF procesa las confirmaciones en la respuesta de todos los mensajes, salvo en los mensajes de error y el mensaje CreateSequence. El respondedor de WCF siempre transmite una confirmación independiente en la respuesta HTTP a todos los mensajes de AckRequested y secuencias.

Intercambio de CloseSequence

El iniciador de WCF transmite un mensaje CloseSequence en una solicitud HTTP y espera el mensaje CreateSequenceResponse en la respuesta HTTP. El respondedor de WCF transmite el mensaje CloseSequenceResponse en la respuesta HTTP.

Intercambio de TerminateSequence

El iniciador de WCF transmite un mensaje TerminateSequence en una solicitud HTTP y espera el mensaje TerminateSequenceResponse en la respuesta HTTP. El respondedor de WCF transmite el mensaje TerminateSequenceResponse en la respuesta HTTP.

Iniciador unidireccional y direccionable

Enlace

WCF proporciona un modelo de intercambio de mensajes unidireccional utilizando una secuencia sobre un canal HTTP entrante y uno saliente. WCF utiliza solicitudes HTTP para transmitir todos los mensajes. Todas las respuestas HTTP tienen un cuerpo vacío y código de estado HTTP 202.

CreateSequence Exchange

El iniciador WCF transmite un mensaje CreateSequence sin elemento Offer en una solicitud HTTP. El respondedor WCF crea una secuencia y transmite el mensaje CreateSequenceResponse sin elemento Accept en una solicitud HTTP.

Iniciador dúplex y direccionable

Enlace

WCF proporciona un modelo de intercambio de mensajes totalmente asincrónico y bidireccional utilizando dos secuencias sobre un canal HTTP entrante y uno saliente. Este modelo de intercambio de mensajes se puede mezclar con el modelo de intercambio de mensajes del iniciador de Request/Reply y Addressable de una manera limitada. WCF utiliza solicitudes HTTP para transmitir todos los mensajes. Todas las respuestas HTTP tienen un cuerpo vacío y código de estado HTTP 202.

CreateSequence Exchange

El iniciador WCF transmite un mensaje CreateSequence con un elemento Offer en una solicitud HTTP. El respondedor de WCF asegura que la CreateSequence tiene un elemento Offer, a continuación, crea una secuencia y transmite el mensaje CreateSequenceResponse con un elemento Accept.

Duración de la secuencia

WCF trata las dos secuencias como una sesión totalmente dúplex.

Tras generar un error que provoca un error en una secuencia, WCF espera que el extremo remoto genere un error en ambas secuencias. Tras leer un error que provoca un error en una secuencia, WCF genera un error en ambas secuencias.

WCF puede cerrar su secuencia saliente y continuar procesando mensajes en su secuencia entrante. De manera inversa, WCF puede procesar el cierre de la secuencia entrante y continuar enviando mensajes en su secuencia saliente.

Iniciador de solicitud-respuesta unidireccional y no direccionable

Enlace

WCF proporciona un modelo de intercambio de mensajes unidireccionales y de solicitud-respuesta utilizando dos secuencias sobre un canal HTTP. WCF utiliza las solicitudes HTTP para transmitir todos los mensajes desde el iniciador hasta el respondedor y respuestas HTTP para transmitir todos los mensajes desde el respondedor hasta el iniciador.

CreateSequence Exchange

El iniciador de WCF transmite un mensaje CreateSequence con un elemento Offer en una solicitud HTTP y espera el mensaje CreateSequenceResponse en la respuesta HTTP. El respondedor de WCF crea una secuencia y transmite el mensaje CreateSequenceResponse con un elemento Accept en la respuesta HTTP.

Mensaje unidireccional

Para completar correctamente un intercambio de mensajes unidireccional, el iniciador de WCF transmite un mensaje de secuencia de solicitud en la solicitud HTTP y recibe un mensaje SequenceAcknowledgement independiente en la respuesta HTTP. La SequenceAcknowledgement debe confirmar el mensaje transmitido.

El respondedor de WCF puede responder a la solicitud con una confirmación, un error o una respuesta con un cuerpo vacío y un código de estado HTTP 202.

Mensajes bidireccionales

Para completar correctamente un protocolo de intercambio de mensajes bidireccional, el iniciador de WCF transmite un mensaje de secuencia de solicitud en la solicitud HTTP y recibe un mensaje de secuencia de respuesta en la respuesta HTTP. La respuesta debe llevar una SequenceAcknowledgement que confirme que se ha transmitido el mensaje de secuencia de solicitud.

El respondedor de WCF puede responder a la solicitud con una respuesta de la aplicación, un error o una respuesta con un cuerpo vacío y un código de estado HTTP 202.

Debido a la presencia de mensajes unidireccionales y al control de tiempo de las respuestas de la aplicación, el número de secuencia del mensaje de secuencia de solicitud y el número de secuencia del mensaje de respuesta no tienen ninguna correlación.

Reintento de respuestas

WCF confía en la correlación de solicitud-respuesta HTTP para la correlación del protocolo de intercambio de mensajes bidireccional. Debido a esto, el iniciador de WCF no deja de reintentar un mensaje de secuencia de solicitud cuando se confirma el mensaje de secuencia de solicitud, sino cuando la respuesta HTTP lleva una SequenceAcknowledgement, una respuesta de la aplicación o error. El respondedor de WCF reintenta las respuestas en la respuesta HTTP de la solicitud con la que se correlaciona la respuesta.

Intercambio de CloseSequence

Después de recibir todos los mensajes de secuencia de respuesta y confirmaciones para todos los mensajes de secuencia de solicitud unidireccionales, el iniciador de WCF transmite un mensaje CloseSequence para la secuencia de la solicitud en una solicitud HTTP y espera la CloseSequenceResponse en la respuesta HTTP.

Al cerrar implícitamente la secuencia de la solicitud, se cierra la secuencia de la respuesta. Esto significa que el iniciador de WCF incluye la SequenceAcknowledgement final de la secuencia de respuesta en el mensaje CloseSequence y la secuencia de respuesta no tiene un intercambio de CloseSequence.

El respondedor de WCF garantiza que todas las respuestas se confirmen y transmite el mensaje CloseSequenceResponse en la respuesta HTTP.

Intercambio de TerminateSequence

Después de recibir el mensaje CloseSequenceResponse, el iniciador de WCF transmite un mensaje TerminateSequence para la secuencia de la solicitud en una solicitud HTTP y espera la TerminateSequenceResponse en la respuesta HTTP.

Al igual que en el intercambio de CloseSequence, al finalizar la secuencia de solicitud, se finaliza la secuencia de respuesta. Esto significa que el iniciador de WCF incluye la SequenceAcknowledgement final de la secuencia de respuesta en el mensaje TerminateSequence y la secuencia de respuesta no tiene un intercambio de TerminateSequence.

El respondedor de WCF transmite el mensaje TerminateSequenceResponse en la respuesta HTTP.

Iniciador direccionable de solicitud-respuesta

Enlace

WCF proporciona un modelo de intercambio de mensajes de solicitud-respuesta utilizando dos secuencias sobre un canal HTTP entrante y uno saliente. Este modelo de intercambio de mensajes se puede mezclar con el modelo de intercambio de mensajes del iniciador de Duplex, Addressable de una manera limitada. WCF utiliza solicitudes HTTP para transmitir todos los mensajes. Todas las respuestas HTTP tienen un cuerpo vacío y código de estado HTTP 202.

CreateSequence Exchange

El iniciador WCF transmite un mensaje CreateSequence con un elemento Offer en una solicitud HTTP. El respondedor de WCF asegura que la CreateSequence tiene un elemento Offer, a continuación, crea una secuencia y transmite el mensaje CreateSequenceResponse con un elemento Accept.

Correlación entre solicitud y respuesta

Lo siguiente se aplica a todas las solicitudes y respuestas correlacionadas:

  • WCF garantiza que todos los mensajes de solicitud de la aplicación llevan una referencia de extremo ReplyTo y un MessageId.

  • WCF aplica la referencia del extremo local como cada ReplyTo de mensaje de solicitud de la aplicación. La referencia del extremo local es la ReplyTo del mensaje CreateSequence para el iniciador y la To del mensaje CreateSequence para el respondedor.

  • WCF garantiza que los mensajes de solicitud entrantes lleven un MessageId y una ReplyTo.

  • WCF garantiza que el URI de la referencia de extremo ReplyTo de todos los mensajes de solicitud de aplicaciones coinciden con la referencia del extremo local tal y como se definió anteriormente.

  • WCF garantiza que todas las respuestas llevan los encabezados RelatesTo y To correctos que siguen las reglas de correlación de solicitud/respuesta de wsa.