Compartir a través de

Protocolo de mensajería confiable versión 1.1

En este tema se abordan 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 a través del transporte HTTP. WCF sigue la especificación WS-ReliableMessaging con las restricciones y aclaraciones que se explican en este tema. Tenga en cuenta que el protocolo WS-ReliableMessaging versión 1.1 se implementa a partir de .NET Framework 3.5.

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

Para mayor comodidad, el tema usa los siguientes roles:

  • 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 usan los prefijos y los espacios de nombres de la tabla siguiente.

Prefijo 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 o WS-Policy 1.5)

Mensajería

Creación de secuencias

WCF implementa CreateSequence y CreateSequenceResponse mensajes para establecer una secuencia de mensajería confiable. Se aplican las restricciones siguientes:

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

  • R1103: Las referencias de punto de conexión `AcksTo`, `ReplyTo` y `Offer/Endpoint` en el mensaje `CreateSequence` deben tener el mismo conjunto de parámetros de referencia.

    • WCF no impone, pero supone que los parámetros de referencia de las referencias de punto de conexión AcksTo, ReplyTo y Offer/Endpoint en CreateSequence son idénticos y usa parámetros de referencia de la referencia de punto de conexión ReplyTo para confirmaciones y 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 emisor de WCF usa el valor Expires en el elemento CreateSequence como el valor Expires en el elemento CreateSequenceResponse. De lo contrario, el respondedor de WCF lee y omite los valores Expires y Offer/Expires.

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

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

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

    • WS-ReliableMessaging utiliza el Offer mecanismo 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 ofrecida, el iniciador de WCF marca como defectuosa la secuencia recién establecida.

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

  • 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 se establecen dos secuencias inversas mediante el Offer mecanismo, todos los mensajes de ambas secuencias que fluyen desde el iniciador al respondedor deben enviarse 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 dicha sesión, incluida la protección de un extremo a otro para la integridad de la sesión, es práctico asegurarse de que los mensajes destinados a la misma entidad lleguen al mismo destino. Esto también permite el “apoyo a caballo” de confirmaciones de secuencias en mensajes de aplicaciones. Por lo tanto, las restricciones R1102, R1112 y R1113 se aplican a WCF.

Ejemplo de un CreateSequence mensaje.

<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 un CreateSequenceResponse mensaje.

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

Cerrar 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 WCF Reliable Messaging no inicia el apagado y el origen de WCF Reliable Messaging no admite un apagado iniciado por el destino. Se aplican las restricciones siguientes:

  • B1201: El origen de Mensajería Confiable de WCF siempre envía un CloseSequence mensaje para finalizar 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 Reliable Messaging siempre incluye el elemento opcional LastMsgNumber a menos que la secuencia no contenga mensajes.

  • R1204: El destino de Reliable Messaging no debe iniciar el apagado enviando un CloseSequence mensaje.

  • 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 un CloseSequence mensaje.

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

Mensaje de ejemplo 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>

Terminació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 restricciones siguientes:

  • 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 LastMsgNumber elemento es coherente en todos los CloseSequence mensajes y TerminateSequence para una secuencia determinada. Esto significa que LastMsgNumber no está presente en todos los CloseSequence mensajes y TerminateSequence , o está presente y es idéntico en todos los CloseSequence mensajes 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. Dado que el origen de Reliable Messaging tiene la confirmación final antes de enviar el TerminateSequence mensaje, el destino de Reliable Messaging sabe sin duda que la secuencia finaliza y reclama los 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 Reliable Messaging determina que no hay incoherencias en la secuencia, el destino de Reliable Messaging espera un tiempo especificado por el destino de una aplicación antes de reclamar recursos, para permitir al cliente recibir la confirmación final. De lo contrario, el destino de Reliable Messaging recupera los recursos inmediatamente e indica al destino de la aplicación que la secuencia termina con incertidumbre al generar el evento Faulted.

Ejemplo de un TerminateSequence mensaje.

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

Mensaje de ejemplo 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 accede a números de secuencia que no superan el valor máximo inclusivo de xs:long, 9223372036854775807.

Un ejemplo de un Sequence encabezado.

<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 restricciones siguientes:

  • R1601: cuando se establecen dos secuencias inversas mediante el Offer mecanismo, el SequenceAcknowledgement encabezado puede incluirse 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 SequenceAcknowledgement encabezados que contienen Nack elementos. WCF valida que cada elemento Nack contiene un número de secuencia; de lo contrario, ignora el elemento Nack y el valor.

Un ejemplo de un SequenceAcknowledgement encabezado.

<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 restricciones siguientes:

  • B1701: WCF no genera MessageNumberRollover errores.

  • 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 WCF de WS-ReliableMessaging puede generar y transmitir fallos 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 Message Addressing Header Required error cuando se cumple una de las siguientes condiciones:

    • Falta un encabezado en el mensaje CreateSequence, CloseSequence o TerminateSequence.

    • Falta un encabezado en el mensaje CreateSequence, CloseSequence o TerminateSequence.

    • Falta la cabecera CreateSequenceResponse en un mensaje de tipo CloseSequenceResponse, TerminateSequenceResponse o 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 del protocolo

Composición con WS-Addressing

WCF admite dos versiones de WS-Addressing: WS-Addressing 2004/08 [WS-ADDR] y W3C WS-Addressing 1.0 Recommendations [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 va a usar. A continuación se muestra una lista de restricciones que se aplican a WCF:

  • R2101: tanto WS-Addressing 2004/08 como WS-Addressing 1.0 se pueden usar con WS-Reliable Messaging.

  • 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. El protocolo WS-ReliableMessaging 1.1, el protocolo WS-Security 1.1 y el protocolo WS-Secure Conversation 1.3 deben usarse juntos. A continuación se muestra una lista de restricciones que se aplican a WCF:

  • R2301: Para proteger la integridad de la secuencia WS-ReliableMessaging además de la integridad y confidencialidad de los mensajes individuales, WCF requiere utilizar 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.

Un ejemplo de un UsesSequenceSTR encabezado.

<wsrm:UsesSequenceSTR></wsrm:UsesSequenceSTR>

Composición con sesiones de SSL/TLS

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

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

  • 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 soporta elementos adjuntos a wsdl:binding y wsdl:port.

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

  • 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 es compatible con sesiones SSL/TLS, no acepta la directiva que especifica wsrmp:SequenceTransportSecurity.

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

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

  • B3007: WCF genera y lee las siguientes propiedades de la aserción de WS-ReliableMessaging y proporciona control sobre ellos en WCFReliableSessionBindingElement:

    • netrmp:InactivityTimeout

    • netrmp:AcknowledgementInterval

    Un 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 está habilitado al configurar la propiedad ReliableSessionBindingElement.FlowControlEnabled a true. A continuación se muestra una lista de restricciones que se aplican a WCF:

  • B4001: Cuando el control de flujo de mensajería confiable está habilitado, WCF genera un elemento netrm:BufferRemaining en la extensibilidad del elemento del encabezado SequenceAcknowledgement, 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 el control de flujo de mensajería confiable está habilitado, WCF no requiere un netrm:BufferRemaining elemento en el SequenceAcknowledgement encabezado.

  • B4003: WcF Reliable Messaging Destination usa netrm:BufferRemaining para indicar cuántos mensajes nuevos puede almacenar en búfer.

  • B4004:Cuando el control de flujo de mensajería confiable está habilitado, el origen de mensajería confiable de WCF utiliza el valor de netrm:BufferRemaining para regular 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 xs:int de maxInclusive, ambos incluidos.

Patrones de Intercambio de mensajes

En esta sección se describe el comportamiento de WCF cuando se usa WS-ReliableMessaging para diferentes patrones de Intercambio de mensajes. Para cada patrón de Intercambio de mensajes se tienen en cuenta los dos escenarios de implementación siguientes:

  • Iniciador no direccionable: el iniciador está detrás de un firewall; El respondedor solo puede entregar mensajes al iniciador en las respuestas HTTP.

  • Iniciador direccionable: Tanto el iniciador como el respondedor pueden recibir solicitudes HTTP; es decir, se pueden establecer dos conexiones HTTP bidireccionales.

Iniciador unidireccional y 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 y las respuestas HTTP para transmitir todos los mensajes del respondedor al iniciador.

CreateSequence Exchange

El iniciador de WCF transmite un mensaje CreateSequence sin el 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 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 de WCF transmite un CloseSequence mensaje en una solicitud HTTP y espera el CreateSequenceResponse mensaje en la respuesta HTTP. El respondedor de WCF transmite el CloseSequenceResponse mensaje en la respuesta HTTP.

Intercambio de TerminateSequence

El iniciador de WCF transmite un TerminateSequence mensaje en una solicitud HTTP y espera el TerminateSequenceResponse mensaje en la respuesta HTTP. El respondedor de WCF transmite el TerminateSequenceResponse mensaje 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 otro saliente. WCF usa las solicitudes HTTP para transmitir todos los mensajes. Todas las respuestas HTTP tienen un cuerpo vacío y un código de estado HTTP 202.

CreateSequence Exchange

El iniciador WCF transmite un CreateSequence mensaje sin Offer elemento en una solicitud HTTP. El respondedor de 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 bidireccional totalmente asincrónico mediante dos secuencias a través de un canal HTTP entrante y otro saliente. Este patrón de intercambio de mensajes se puede mezclar con el Request/Replypatrón de intercambio de mensajes del Addressable iniciador de forma limitada. WCF usa solicitudes HTTP para transmitir todos los mensajes. Todas las respuestas HTTP tienen un cuerpo vacío y un 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 garantiza que CreateSequence tiene un Offer elemento y, a continuación, crea una secuencia y transmite el CreateSequenceResponse mensaje con un Accept elemento .

Duración de la secuencia

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

Al generar un error que afecta a una secuencia, WCF espera que el punto de conexión remoto afecte a ambas secuencias. Tras leer un error que genera un error en una secuencia, WCF genera errores en ambas secuencias.

WCF puede cerrar su secuencia de salida y continuar procesando mensajes en su secuencia entrante. Por el contrario, WCF puede procesar el cierre de la secuencia de entrada y continuar enviando mensajes en su secuencia de salida.

Iniciador de solicitud-respuesta unidireccional y no direccionable

Enlace

WCF proporciona un patrón de intercambio de mensajes unidireccional y 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 y las respuestas HTTP para transmitir todos los mensajes del respondedor al 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 independiente SequenceAcknowledgement en la respuesta HTTP. 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 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 confirmación del mensaje de secuencia de solicitud transmitido.

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

Debido a la presencia de mensajes unidireccionales y el tiempo de 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 correlación.

Reintentar 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 la secuencia de respuestas y confirmaciones para todos los mensajes de la secuencia de solicitudes unidireccionales, el iniciador de WCF transmite un mensaje CloseSequence para la secuencia de solicitudes en una solicitud HTTP y espera el CloseSequenceResponse en la respuesta HTTP.

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

El respondedor de WCF garantiza que todas las respuestas se confirmen y transmitan el CloseSequenceResponse mensaje 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 solicitudes en una petición HTTP y espera el mensaje TerminateSequenceResponse en la respuesta HTTP.

Al igual que el CloseSequence intercambio, la finalización de la secuencia de solicitudes finaliza implícitamente la secuencia de respuesta. Esto significa que el iniciador de WCF incluye la secuencia de respuesta final SequenceAcknowledgement en el mensaje TerminateSequence, y la secuencia de respuesta no tiene un intercambio TerminateSequence.

El respondedor de WCF transmite el TerminateSequenceResponse mensaje 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 otro saliente. Este patrón de intercambio de mensajes se puede mezclar con el Duplex, Addressable patrón de intercambio de mensajes del iniciador de forma limitada. WCF usa las solicitudes HTTP para transmitir todos los mensajes. Todas las respuestas HTTP tienen un cuerpo vacío y un 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 se asegura de que el CreateSequence tenga un elemento Offer, luego crea una secuencia y transmite el mensaje CreateSequenceResponse con un elemento Accept.

Correlación de solicitudes y respuestas

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

  • WCF garantiza que todos los mensajes de solicitud de aplicación tengan una ReplyTo referencia de punto de conexión y una 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 el CreateSequence mensaje ReplyTo para el iniciador y el CreateSequence mensaje To para el respondedor.

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

  • WCF garantiza que el URI de la referencia del punto de conexión de todos los mensajes de solicitud de las aplicaciones coincida con la referencia del punto de conexión local tal como se definió anteriormente.

  • WCF garantiza que todas las respuestas tengan los encabezados correctos RelatesTo y To, siguiendo las reglas de correlación de solicitudes y respuestas wsa.

  • Last updated on