Protocolo de mensajería de confianza versión 1,1

  • Artículo

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

El WS-ReliableMessaging de febrero de 2007 se implementa en WCF mediante ReliableSessionBindingElement.

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 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 (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 confiable. Se aplican las siguientes restricciones:

  • B1101: el iniciador WCF usa la misma referencia de punto de conexión que CreateSequence y ReplyTo del mensaje, AcksTo y Offer/Endpoint.

  • R1102: las referencias de punto de conexión 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 WCF comprueba que la parte del URI de las referencias de punto de conexión AcksTo, ReplyTo y Endpoint sean idénticas antes de crear una secuencia.

  • R1103: las referencias de punto de conexión 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 referencias de punto de conexión AcksTo, ReplyTo y Offer/Endpoint en CreateSequence son idénticas y usa los parámetros de referencia de la referencia de punto de conexión ReplyTo para las confirmaciones y los mensajes de secuencia inversa.

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

  • B1105: al acceder al mensaje CreateSequence, el respondedor WCF usa el valor Expires del elemento CreateSequence como el valor Expiresdel elemento CreateSequenceResponse. De lo contrario, el respondedor WCF lee y omite los valores Expires y Offer/Expires.

  • B1106: al acceder al mensaje CreateSequenceResponse, el iniciador WCF lee el valor opcional Expires, pero no lo usa.

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

  • B1108: WCF solo usa 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 WCF rechaza la secuencia proporcionada y responde con un CreateSequenceResponse sin un elemento Accept.

  • B1110: si un respondedor de mensajería confiable rechaza la secuencia proporcionada, el iniciador WCF produce un error en la secuencia recién establecida.

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

  • R1112: cuando dos secuencias inversas se establecen utilizando el mecanismo Offer, la propiedad [address] de la referencia de punto de conexión 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 punto de conexión.

WCF usa WS-ReliableMessaging para establecer sesiones confiables entre el iniciador y el respondedor. La implementación de WS-ReliableMessaging WCF proporciona una sesión confiable para patrones 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 puntos de conexión de mensajes. Dado que WCF proporciona una garantía de seguridad para este tipo de sesiones, entre las que se incluyen la protección de un extremo a otro para la integridad de la sesión, resulta práctico garantizar que los mensajes que se dirigen 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 tanto, 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 usa los mensajes CloseSequence y CloseSequenceResponse para llevar a cabo un apagado que inicie el origen de la mensajería confiable. El destino de la mensajería confiable WCF no inicia el apagado y el origen de la mensajería confiable WCF no admite que el destino inicie un apagado de la mensajería confiable. Se aplican las siguientes restricciones:

  • B1201: el origen de la mensajería confiable WCF siempre envía un mensaje CloseSequence para apagar 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: al recibir un mensaje CloseSequence, el origen de la mensajería confiable 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>

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

Finalización de secuencia

WCF usa principalmente el protocolo de enlace TerminateSequence/TerminateSequenceResponse después de completar el protocolo de enlace CloseSequence/CloseSequenceResponse. El destino de la mensajería confiable WCF no inicia la terminación y el origen de la mensajería confiable no admite que el destino inicie una terminación de la mensajería confiable. Se aplican las siguientes restricciones:

  • B1301: el iniciador WC 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 CloseSequence y TerminateSequence para una secuencia determinada. Esto significa que LastMsgNumber no está presente en todos los mensajes CloseSequence y TerminateSequence, o está presente y es idéntico en todos los mensajes CloseSequence y TerminateSequence.

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

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

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 que no superan el 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 usa el encabezado AckRequested como un mecanismo de mantenimiento.

Ejemplo de encabezado AckRequested.

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

SequenceAcknowledgement

WFC usa un mecanismo de "apoyo a caballo" para las confirmaciones de secuencias que se proporcionan en WS-Reliable Messaging. Se aplican las siguientes restricciones:

  • R1601: cuando dos secuencias inversas se establecen mediante el mecanismo Offer, el encabezado SequenceAcknowledgement puede estar incluido en cualquier mensaje de aplicación que se transmite 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 y el valor Nack.

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 las restricciones que se aplican a la implementación WCF de errores de WS-ReliableMessaging. Se aplican las siguientes restricciones:

  • B1701: WCF no genera errores de MessageNumberRollover.

  • B1702: a través de SOAP 1.2, cuando el punto de conexión 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 ejemplo siguiente.

<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 usa WS-Addressing, la implementación de WS-ReliableMessaging WCF puede generar y transmitir errores de WS-Addressing. En esta sección se tratan los errores de WS-Addressing que WCF genera y transmite explícitamente en la capa de WS-ReliableMessaging:

  • B1801: WCF genera y transmite el error Message Addressing Header Required cuando se cumple uno de los siguientes requisitos:

    • 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 punto de conexión a la escucha que pueda procesar la secuencia según el 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 WS-Reliable Messaging.

Composición con WS-Security y WS-SecureConversation

WCF proporciona protección para secuencias de WS-ReliableMessaging mediante el transporte seguro (HTTPS), la creación con WS-Security y la creació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 mensajes individuales, WCF necesita que se use 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 crea con WS-Secure Conversation, el respondedor WCF necesita 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 creación con sesiones de SSL/TLS:

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

  • R2402: un iniciador de mensajería confiable no debe enviar un mensaje CreateSequence con un encabezado wsrm:UsesSequenceSSL a un respondedor 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 usa la aserción wsrm:RMAssertion de WS-Policy de WS-ReliableMessaging para describir funciones de puntos de conexión. 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 wsdl:binding. WCF admite datos adjuntos para los elementos wsdl:binding y wsdl:port.

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

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

  • R3004: dado que WCF no crea con sesiones SSL/TLS, WCF no acepta la directiva que especifica 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 estas en WCFReliableSessionBindingElement:

    • 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 usa la extensibilidad de WS-ReliableMessaging para proporcionar un control adicional más estricto y opcional sobre el flujo de mensajes de secuencias.

El control de flujo se habilita cuando la propiedad ReliableSessionBindingElement.FlowControlEnabled se establece en true. 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 confiable, 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 confiable, WCF no necesita un elemento netrm:BufferRemaining en el encabezado SequenceAcknowledgement.

  • B4003: el destino de la mensajería confiable WCF usa 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 confiable, el origen de la mensajería confiable WCF usa el valor netrm:BufferRemaining para limitar la transmisión de mensajes.

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

Modelos de intercambio de mensajes

En esta sección se describe el comportamiento de WCF cuando se usa WS-ReliableMessaging para patrones de intercambio de mensajes diferentes. Para cada patrón 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 patrón de intercambio de mensajes unidireccional mediante una secuencia a través de un canal HTTP. WCF usa solicitudes HTTP para transmitir todos los mensajes del iniciador al respondedor, así como respuestas HTTP para transmitir todos los mensajes del respondedor al iniciador.

Intercambio de CreateSequence

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

SequenceAcknowledgement

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

Intercambio de CloseSequence

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

Intercambio de TerminateSequence

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

Iniciador unidireccional y direccionable

Enlace

WCF proporciona un patrón de intercambio de mensajes unidireccional mediante una secuencia a través de un canal HTTP entrante y uno saliente. WCF usa las solicitudes HTTP para transmitir todos los mensajes. Todas las respuestas HTTP tienen un cuerpo vacío y código de estado HTTP 202.

Intercambio de CreateSequence

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

Iniciador dúplex y direccionable

Enlace

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

Intercambio de CreateSequence

El iniciador WCF transmite un mensaje CreateSequence con un elemento Offer en una solicitud HTTP. El respondedor WCF garantiza que CreateSequence tenga 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.

Al generar un error que produce un error en una secuencia, WCF espera que el punto de conexión remoto genere un error en ambas secuencias. Al leer un error en una secuencia, WCF producirá un error en ambas secuencias.

WCF puede cerrar la secuencia saliente y continuar con el procesamiento de mensajes en la secuencia entrante. En cambio, WCF puede procesar el cierre de la secuencia entrante y continuar con el envío de mensajes en la secuencia saliente.

Iniciador de solicitud-respuesta unidireccional y no direccionable

Enlace

WCF proporciona un patrón de intercambio de mensajes unidireccional de solicitud-respuesta mediante dos secuencias a través de un canal HTTP. WCF usa solicitudes HTTP para transmitir todos los mensajes del iniciador al respondedor, así como respuestas HTTP para transmitir todos los mensajes del respondedor al iniciador.

Intercambio de CreateSequence

El iniciador WCF transmite un mensaje CreateSequence con un elemento Offer en una solicitud HTTP y espera el mensaje CreateSequenceResponse en la respuesta HTTP. El respondedor 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 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 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 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 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 depende de la correlación de solicitud-respuesta HTTP para la correlación del protocolo de intercambio de mensajes bidireccional. Por este motivo, el iniciador 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 un error. El respondedor WCF vuelve a intentar responder 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 las confirmaciones para todos los mensajes de secuencia de solicitud unidireccionales, el iniciador WCF transmite un mensaje CloseSequence para la secuencia de solicitud en una solicitud HTTP y espera 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 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 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 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 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 WCF transmite el mensaje TerminateSequenceResponse en la respuesta HTTP.

Iniciador direccionable de solicitud-respuesta

Enlace

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

Intercambio de CreateSequence

El iniciador WCF transmite un mensaje CreateSequence con un elemento Offer en una solicitud HTTP. El respondedor WCF garantiza que CreateSequence tenga 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 punto de conexión ReplyTo y un MessageId.

  • WCF aplica la referencia de punto de conexión local como cada ReplyTo del mensaje de solicitud de la aplicación. La referencia del punto de conexión local es la CreateSequence del mensaje ReplyTo para el iniciador y la CreateSequence del mensaje To 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 punto de conexión ReplyTo de todos los mensajes de solicitud de aplicaciones coincida con la referencia del punto de conexión local tal y como se definió anteriormente.

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