Compartir a través de

Protocolo de mensajería de confianza versión 1.0

  • Artículo

Este tema incluye los detalles de implementación de Windows Communication Foundation (WCF) para el protocolo WS-ReliableMessaging (versión 1.0) de febrero de 2005, que es necesario para la interoperación mediante el transporte HTTP. WCF sigue la especificación WS-Reliable Messaging con las restricciones y clarificaciones que se explican en este tema. Tenga en cuenta que la versión 1.0 del protocolo WS-ReliableMessaging se implementa a partir de WinFX.

ReliableSessionBindingElement implementa el protocolo WS-Reliable Messaging de febrero de 2005 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://schemas.xmlsoap.org/ws/2005/02/rm
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

Mensajería

Mensajes de establecimiento de secuencia

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

  • B1101: el iniciador WCF no genera el elemento Expires opcional en el mensaje CreateSequence o, en los casos en los que el mensaje CreateSequence contiene un elemento Offer, el elemento opcional Expires en el elemento Offer.

  • B1102: cuando se accede al mensaje CreateSequence, ResponderWCF envía y recibe los elementos Expires si existen, pero no usa sus valores.

WS-Reliable Messaging incluye el mecanismo Offer para establecer las dos secuencias correlacionadas inversas que forman una sesión.

  • R1103: si CreateSequence contiene un elemento Offer, el respondedor de la mensajería de confianza debe aceptar la secuencia y responder con CreateSequenceResponse, que contiene un elemento wsrm:Accept, formando dos secuencias correlacionadas inversas, o rechazar la solicitud CreateSequence.

  • R1104: SequenceAcknowledgement y los mensajes de la aplicación que fluyen en una secuencia inversa se deben enviar a la referencia de punto de conexión ReplyTo de CreateSequence.

  • R1105: las referencias de punto de conexión AcksTo y ReplyTo en CreateSequence deben tener valores de dirección que coincidan byte a byte.

    El respondedor WCF comprueba que la parte del URI de las EPR AcksTo y ReplyTo sea idéntica antes de la creación de una secuencia.

  • R1106: las referencias de punto de conexión AcksTo y ReplyTo del mensaje CreateSequence deberían tener el mismo conjunto de parámetros de referencia.

    WCF no exige, pero supone que los [parámetros de referencia] de AcksTo y ReplyTo en CreateSequence son idénticos 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.

  • R1107: cuando dos secuencias inversas se establecen por medio del mecanismo Offer, los mensajes de aplicación y SequenceAcknowledgement que fluyen en secuencias inversas se deben enviar a la referencia de punto de conexión ReplyTo de CreateSequence.

  • R1108: cuando dos secuencias inversas se establecen mediante el mecanismo Offer, la propiedad [address] del elemento secundario de referencia de extremo wsrm:AcksTo del elemento wsrm:Accept de CreateSequenceResponse debe coincidir byte a byte con el URI de destino de CreateSequence.

  • R1109: cuando se establecen dos secuencias inversas por medio del mecanismo Offer, los mensajes enviados por el iniciador y las confirmaciones de los mensajes por parte del respondedor se deben enviar a la misma referencia de punto de conexión.

    WCF usa WS-Reliable Messaging para establecer sesiones confiables entre el iniciador y el respondedor. La implementación de WS-Reliable Messaging WCF proporciona una sesión confiable para patrones de mensajería dúplex completa y de solicitud-respuesta unidireccional. El mecanismo Offer de WS-Reliable Messaging en CreateSequence/CreateSequenceResponsepermite 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 para garantizar 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 tanto, las restricciones R1104, R1105 y R1108 se aplican a WCF.

Ejemplo de mensaje CreateSequence.

<s:Envelope>
  <s:Header>
    <a:Action s:mustUnderstand="1">
      http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequence
    </a:Action>
    <a:ReplyTo>
      <a:Address>
         http://Business456.com/clientA
      </a:Address>
    </a:ReplyTo>
    <a:MessageID>
      urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
    </a:MessageID>
    <a:To s:mustUnderstand="1">
      http://Business456.com/clientA
    </a: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:0afb8d36-bf26-4776-b8cf-8c91fddb5496
      </wsrm:Identifier>
     </wsrm:Offer>
   </wsrm:CreateSequence>
  </s:Body>
</s:Envelope>

Ejemplo de mensaje CreateSequenceResponse.

<s:Envelope>
  <s:Header>
    <a:Action s:mustUnderstand="1">
      http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequenceResponse
    </a:Action>
    <a:RelatesTo>
      urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
    </a:RelatesTo>
    <a:To s:mustUnderstand="1">
      http://Business456.com/clientA
    </a:To>
  </s:Header>
  <s:Body>
   <wsrm:CreateSequenceResponse>
    <Identifier>
     urn:uuid:eea0a36c-b38a-43e8-8c76-2fabe2d76386
    </Identifier>
    <Accept>
    <AcksTo>
      <a:Address>
        http://BusinessABC.com/serviceA
      </a:Address>
    </AcksTo>
    </Accept>
   </wsrm:CreateSequenceResponse>
  </s:Body>
</s:Envelope>

Secuencia

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

  • B1201: WCF genera y tiene acceso a números de secuencia que no superan el valor máximo incluido de xs:long, 9223372036854775807.

  • B1202: WCF siempre genera un último mensaje de cuerpo vacío con el URI de acción de http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage.

  • B1203: WCF recibe y entrega un mensaje con un encabezado de secuencia que contiene un elemento LastMessage siempre que el URI de acción no sea http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage.

Ejemplo de encabezado de secuencia.

<wsrm:Sequence>
  <wsrm:Identifier>
    urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
  </wsrm:Identifier>
  <wsrm:MessageNumber>
    10
  </wsrm:MessageNumber>
  <wsrm:LastMessage/>
 </wsrm:Sequence>

Encabezado AckRequested

WCF usa el encabezado AckRequested como mecanismo de mantenimiento. WCF no genera el elemento MessageNumber opcional. Cuando se recibe un mensaje con un encabezado AckRequested que contiene el elemento MessageNumber, WCF ignora el valor del elemento MessageNumber, tal y como se muestra en el siguiente ejemplo.

<wsrm:AckRequested>
  <wsrm:Identifier>
    urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
  </wsrm:Identifier>
</wsrm:AckRequested>

Encabezado SequenceAcknowledgement

WCF usa un mecanismo de superposición para las confirmaciones de secuencias que se proporcionan en WS-Reliable Messaging.

  • R1401: 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.

  • B1402: cuando WCF debe generar una confirmación antes de recibir ningún mensaje de secuencia (por ejemplo, para satisfacer un mensaje AckRequested), WCF genera un encabezado SequenceAcknowledgementque contiene el rango 0-0, tal y como se muestra en el siguiente ejemplo.

    <wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>
    urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
  </wsrm:Identifier>
  <wsrm:AcknowledgementRange Upper="0" Lower="0"/>
</wsrm:SequenceAcknowledgement>

  • B1403: WCF no genera encabezados SequenceAcknowledgement que contengan un elemento Nack, pero admite elementos Nack.

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-Reliable Messaging:

  • B1501: WCF no genera errores MessageNumberRollover.

  • B1502: el punto de conexión WCF puede generar errores CreateSequenceRefused, tal y como se describe en la especificación.

  • B1503: cuando el punto de conexión de servicio alcanza el límite de conexiones y no puede procesar ninguna nueva, WCF genera un subcódigo de error CreateSequenceRefused adicional, netrm:ConnectionLimitReached, tal y como se muestra en el siguiente ejemplo.

    <s:Envelope>
  <s:Header>
    <wsa:Action>
      http://schemas.xmlsoap.org/ws/2005/08/addressing/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">
          [Reason]
        </s:Text>
      </s:Reason>
    </s:Fault>
  </s:Body>
</s:Envelope>

Errores WS-Addressing

Dado que WS-Reliable Messaging usa WS-Addressing, la implementación de WS-Reliable Messaging WCF puede generar errores de WS-Addressing. Esta sección incluye los errores de WS-Addressing que WCF genera de forma explícita en la capa de WS-Reliable Messaging:

  • B1601: WCF genera el error Encabezado de direccionamiento de mensaje necesario cuando se cumple uno de los siguientes requisitos:

    • Falta un encabezado Sequence y un encabezado Action en un mensaje.

    • Falta un encabezado CreateSequence en un mensaje MessageId.

    • Falta un encabezado CreateSequence en un mensaje ReplyTo.

  • B1602: WCF genera el error Acción no admitida en respuesta a un mensaje que carece de un encabezado Sequence y que tiene un encabezado Action que se reconoce en la especificación WS-Reliable Messaging.

  • B1603: WCF genera el error Punto de conexión no disponible para indicar que el punto de conexión no procesa la secuencia en función 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-Reliable Messaging solo menciona a WS-Addressing 2004/08, no limita 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 WS-Reliable Messaging.

  • R2102: se debe utilizar una única versión de WS-Addressing a en una secuencia de WS-Reliable Messaging determinada o un par de secuencias inversas correlacionadas mediante el mecanismo wsrm: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-Reliable Messaging mediante el transporte seguro (HTTPS), la creación con WS-Security y la composición con WS-Secure Conversation. A continuación, se muestra una lista de restricciones que se aplican a WCF:

  • R2301: para proteger la integridad de una secuencia de WS-Reliable Messaging 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-Reliable Messaging.

  • R2303: si la duración de la secuencia de WS-Reliable Messaging 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-Reliable Messaging o un par de secuencias inversas correlacionadas siempre se enlazan a una única sesión de WS-SecureConversation.

    El origen WCF genera el elemento wsse:SecurityTokenReference en la sección de extensibilidad de elementos del mensaje CreateSequence.

  • R2305: cuando se realiza con WS-Secure Conversation, un mensaje CreateSequence debe contener el elemento wsse:SecurityTokenReference.

Aserción de WS-Policy de WS-Reliable Messaging

WCF usa la aserción de WS-Policy de WS-Reliable Messaging para wsrm:RMAssertion a fin de describir funcionalidades 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 wsrm:RMAssertion a elementos wsdl:binding. WCF admite datos adjuntos para los elementos wsdl:binding y wsdl:port.

  • B3002: WCF admite las siguientes propiedades de aserción opcionales de WS-Reliable Messaging y proporciona control sobre estas en WCFReliableMessagingBindingElement:

    • wsrm:InactivityTimeout

    • wsrm:AcknowledgementInterval

    A continuación se muestra un ejemplo.

    <wsrm:RMAssertion>
  <wsrm:InactivityTimeout Milliseconds="600000" />
  <wsrm:AcknowledgementInterval Milliseconds="200" />
</wsrm:RMAssertion>

Extensión de WS-Reliable Messaging de control de flujo

WCF usa la extensibilidad de WS-Reliable Messaging 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 se habilitada el control de flujo de la mensajería confiable, WCF genera un elemento netrm:BufferRemaining en la extensibilidad de elementos del encabezado SequenceAcknowledgement.

  • B4002: cuando está habilitado el control de flujo de la mensajería confiable, WCF no necesita que haya un elemento netrm:BufferRemaining en el encabezado SequenceAcknowledgement, tal y como se muestra en el ejemplo siguiente.

    <wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>
    http://fabrikam123.com/abc
  </wsrm:Identifier>
  <wsrm:AcknowledgementRange Upper="1" Lower="1"/>
  <netrm:BufferRemaining>
    8
  </netrm:BufferRemaining>
</wsrm:SequenceAcknowledgement>

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

  • B4004: el servicio de mensajería confiable WCF limita el número de mensajes que se transmiten cuando la aplicación de destino de la mensajería confiable no puede recibir mensajes de forma rápida. El destino de la mensajería de confianza almacena en búfer los mensajes y el valor del elemento cae a 0.

  • 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-Reliable Messaging 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 las solicitudes HTTP para transmitir todos los mensajes del RMS al RMD y la respuesta HTTP para transmitir todos los mensajes del RMD al RMS.

Intercambio de CreateSequence

El iniciador WCF genera un mensaje CreateSequence sin ninguna oferta. El respondedor WCF garantiza que CreateSequence no tenga ninguna oferta antes de la creación de una secuencia. El respondedor WCF responde a la solicitud CreateSequence con un mensaje CreateSequenceResponse.

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 genera una confirmación independiente en respuesta a la secuencia y los mensajesAckRequested.

Mensaje TerminateSequence

WCF trata a TerminateSequence como una operación unidireccional, lo que significa que la respuesta HTTP tiene un cuerpo vacío y un código de estado HTTP 202.

Iniciador unidireccional y direccionable

Enlace

WCF proporciona un patrón de intercambio de mensajes unidireccional mediante una secuencia sobre 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 genera un mensaje CreateSequence sin ninguna oferta. El respondedor WCF garantiza que CreateSequence no tenga ninguna oferta antes de la creación de una secuencia. El respondedor WCF transmite el mensaje CreateSequenceResponse en una solicitud HTTP direccionada con la referencia de punto de conexión ReplyTo.

Iniciador dúplex y direccionable

Enlace

WCF proporciona un patrón de intercambio de mensajes totalmente asincrónico y bidireccional mediante dos secuencias sobre 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 genera un mensaje CreateSequence con una oferta. El respondedor WCF garantiza que CreateSequence tenga una oferta antes de la creación de una secuencia. WCF envía CreateSequenceResponse en la solicitud HTTP que está dirigida a la referencia de punto de conexión de CreateSequenceReplyTo.

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 no direccionable de solicitud-respuesta

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 las solicitudes HTTP para transmitir los mensajes de la secuencia de solicitud y usa las respuestas HTTP para transmitir los mensajes de la secuencia de respuesta.

Intercambio de CreateSequence

El iniciador WCF genera un mensaje CreateSequence con una oferta. El respondedor WCF garantiza que CreateSequence tenga una oferta antes de la creación de una secuencia. El respondedor WCF responde a la solicitud CreateSequence con un mensaje CreateSequenceResponse.

Mensaje unidireccional

Para completar correctamente un protocolo de 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 ese motivo, el iniciador WCF no deja de reintentar un mensaje de secuencia de solicitud cuando este se confirma, sino cuando la respuesta HTTP transmite una confirmación, un mensaje de usuario o un error. El respondedor WCF vuelve a intentar responder en la fase de la solicitud HTTP de la solicitud con la que se pone en correlación la respuesta.

Intercambio de LastMessage

El iniciador WCF genera y transmite un último mensaje con cuerpo vacío en la fase de la solicitud HTTP. WCF necesita una respuesta, pero omite el mensaje de respuesta real. El respondedor WCF responde al último mensaje de cuerpo vacío de la secuencia de solicitud con el último mensaje de cuerpo vacío de la secuencia de respuesta.

Si el respondedor WCF recibe un último mensaje en el que el URI de acción no es http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage, WCF responderá con un último mensaje. En el caso de un protocolo de intercambio de mensajes bidireccional, el último mensaje lleva el mensaje de la aplicación; en el caso de un protocolo de intercambio de mensajes unidireccional, el último mensaje está vacío.

El respondedor WCF no requiere una confirmación para el último mensaje de cuerpo vacío de la secuencia de respuesta.

Intercambio de TerminateSequence

Cuando todas las solicitudes han recibido una respuesta válida, el iniciador WCF genera y transmite el mensaje TerminateSequence de la secuencia de solicitud en la fase de la solicitud HTTP. WCF necesita una respuesta, pero omite el mensaje de respuesta real. El respondedor WCF responde al mensaje TerminateSequence de la secuencia de solicitud con el mensaje TerminateSequence de la secuencia de respuesta.

En una secuencia de apagado normal, ambos mensajes TerminateSequence llevan un SequenceAcknowledgement de intervalo completo.

Iniciador direccionable de solicitud-respuesta

Enlace

WCF proporciona un patrón de intercambio de mensajes de solicitud-respuesta mediante dos secuencias sobre 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 genera un mensaje CreateSequence con una oferta. El respondedor WCF garantiza que CreateSequence tenga una oferta antes de la creación de una secuencia. WCF envía CreateSequenceResponse en la solicitud HTTP que está dirigida a la referencia de punto de conexión de CreateSequenceReplyTo.

Correlación entre solicitud y respuesta

El iniciador WCF garantiza que todos los mensajes de solicitud de la aplicación lleven un MessageId y una referencia de punto de conexión ReplyTo. El iniciador WCF aplica la referencia de punto de conexión ReplyTo del mensaje CreateSequence en cada mensaje de solicitud de la aplicación. El respondedor WCF necesita que los mensajes de solicitud entrantes lleven un MessageId y un ReplyTo. El respondedor WCF garantiza que el URI de la referencia del punto de conexión de CreateSequence y de todos los mensajes de solicitud de la aplicación sean idénticos.