Partager via

Protocole de messagerie fiable version 1.0

  • Article

Cette rubrique couvre en détail l’implémentation Windows Communication Foundation (WCF) pour le protocole WS-ReliableMessaging de février 2005 (version 1.0) qui est nécessaire pour l'interopérabilité en utilisant le transport HTTP. WCF suit la spécification WS-ReliableMessaging avec les contraintes et les éclaircissements présentés dans cette rubrique. Notez que le protocole WS-ReliableMessaging version 1.0 est implémenté à partir de WinFX.

Le protocole WS-ReliableMessaging de février 2005 est implémenté dans WCF par ReliableSessionBindingElement.

Pour plus de simplicité, la rubrique utilise les rôles suivants :

  • Initiateur : client qui initialise la création de la séquence de message WS-Reliable.

  • Répondeur : service qui reçoit les demandes de l'initiateur.

Ce document utilise les préfixes et les espaces de noms répertoriés dans le tableau suivant.

Préfixe Espace de noms
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

Messagerie

Messages d'établissement de séquence

WCF implémente les messages CreateSequence et CreateSequenceResponse pour établir une séquence de messagerie fiable. Les contraintes suivantes s’appliquent :

  • B1101 : l'initiateur WCF ne génère pas l'élément Expires facultatif dans le message CreateSequence ou, lorsque le message CreateSequence contient un élément Offer, l'élément Expires facultatif dans l'élément Offer.

  • B1102 : quand il accède au message CreateSequence, le Responder WCF envoie et reçoit les deux éléments Expires s'ils existent, mais il n'utilise pas leurs valeurs.

La messagerie WS-Reliable introduit le mécanisme Offer pour établir deux séquences corrélées réciproques qui forment une session.

  • R1103 : si CreateSequence contient un élément Offer, le répondeur de messagerie fiable doit soit accepter la séquence et répondre avec CreateSequenceResponse contenant un élément wsrm:Accept, formant deux séquences réciproques corrélées, soit rejeter la demande CreateSequence.

  • R1104 : l'SequenceAcknowledgement et les messages d'application qui passent sur la séquence réciproque doivent être envoyés à la référence de point de terminaison ReplyTo de CreateSequence.

  • R1105 : les références de point de terminaison AcksTo et ReplyTo dans CreateSequence doivent avoir des valeurs d'adresse qui correspondent au niveau des octets.

    Le répondeur WCF vérifie que la partie URI des ERP AcksTo et ReplyTo est identique avant de créer une séquence.

  • R1106 : les références de point de terminaison AcksTo et ReplyTo dans CreateSequence doivent avoir le même jeu de paramètres de référence.

    WCF n'applique pas, mais suppose que les [paramètres de référence] de AcksTo et ReplyTo sur CreateSequence sont identiques. Il utilise les [paramètres de référence] de la référence de point de terminaison ReplyTo pour les accusés de réception et les messages de séquence réciproque.

  • R1107 : lorsque deux séquences réciproques sont établies à l'aide du mécanisme Offer, l'SequenceAcknowledgement et les messages d'application qui traversent les séquences réciproques doivent être envoyés à la référence de point de terminaison ReplyTo de CreateSequence.

  • R1108 : lorsque deux séquences réciproques sont établies à l'aide du mécanisme Offer, la propriété [address] de l'élément enfant wsrm:AcksTo de la référence de point de terminaison de l'élément wsrm:Accept de la CreateSequenceResponse doit correspondre octet par octet à l'URI de destination de CreateSequence.

  • R1109 : lorsque deux séquences réciproques sont établies à l'aide du mécanisme Offer, les messages envoyés par l'initiateur et les accusés de réception des messages envoyés par le répondeur doivent être envoyés à la même référence de point de terminaison.

    WCF utilise WS-ReliableMessaging pour établir des sessions fiables entre l'initiateur et le répondeur. L’implémentation WCF de WS-ReliableMessaging fournit une session fiable pour les modèles de messagerie de type duplex intégral, demande-réponse et unidirectionnels. Le mécanisme WS-ReliableMessaging Offer sur CreateSequence/CreateSequenceResponse vous permet d'établir deux séquences réciproques corrélées. Il fournit un protocole de session qui convient à tous les points de terminaison de message. Comme WCF fournit une garantie de sécurité pour ce type de session incluant la protection de bout en bout de l'intégrité de la session, c’est un moyen pratique de s'assurer que les messages prévus pour la même partie arrivent à la même destination. Cela permet également la superposition des accusés de réception de séquence sur les messages d'application. Par conséquent, les contraintes R1104, R1105 et R1108 s’appliquent à WCF.

Exemple de message 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>

Exemple de message 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>

Séquence

Voici une liste des contraintes qui s'appliquent aux séquences :

  • B1201 : WCF génère des numéros de séquence et accède à ceux qui ne dépassent pas la valeur maximale de xs:long, à savoir 9223372036854775807.

  • B1202: WCF génère toujours un dernier message au corps vide et l’URI d’action http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage.

  • B1203 : WCF reçoit et remet un message avec un en-tête Sequence qui contient un élément LastMessage tant que l'URI d’action n'est pas http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage.

Exemple d'en-tête Sequence.

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

En-tête AckRequested

WCF utilise l'en-tête AckRequested comme un mécanisme persistant. WCF ne génère pas l'élément facultatif MessageNumber. Quand il reçoit un message avec un en-tête AckRequested contenant l'élément MessageNumber, WCF ignore la valeur de l'élément MessageNumber, comme le montre l'exemple suivant.

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

En-tête SequenceAcknowledgement

WCF utilise un mécanisme de portage (« piggy-back ») pour les accusés de réception de séquence fournis dans WS-ReliableMessaging.

  • R1401 : lorsque deux séquences réciproques sont établies à l'aide du mécanisme Offer, l'en-tête SequenceAcknowledgement peut être inclus dans tout message d'application transmis au destinataire souhaité.

  • B1402 : lorsque WCF doit générer un accusé de réception avant de recevoir un message de séquence (par exemple, pour satisfaire à un message AckRequested), WCF génère un en-tête SequenceAcknowledgement qui contient la plage 0-0, comme indiqué dans l'exemple suivant.

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

  • B1403 : WCF ne génère pas d'en-têtes SequenceAcknowledgement contenant un élément Nack, mais prend en charge les éléments Nack.

Erreurs de la messagerie WS-Reliable

Voici une liste des contraintes qui s'appliquent à l'implémentation WCF des erreurs WS-ReliableMessaging :

  • B1501 : WCF ne génère pas d'erreurs MessageNumberRollover.

  • B1502 : le point de terminaison WCF peut générer des erreurs CreateSequenceRefused comme cela est décrit dans la spécification.

  • B1503 : lorsque le point de terminaison de service atteint sa limite de connexion et ne peut pas traiter de nouvelles connexions, WCF génère un sous-code d'erreur CreateSequenceRefused supplémentaire, netrm:ConnectionLimitReached, comme indiqué dans l'exemple suivant.

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

Erreurs WS-Addressing

Étant donné que WS-ReliableMessaging utilise WS-Addressing, l'implémentation WCF de WS-ReliableMessaging peut générer des erreurs WS-Addressing. Cette section traite des erreurs WS-Addressing que WCF génère explicitement au niveau de la couche WS-ReliableMessaging :

  • B1601 : WCF génère l'erreur Message Addressing Header Required quand l'une des conditions suivantes est vraie :

    • Un message n'a pas d'en-tête Sequence ni d'en-tête Action.

    • Un message CreateSequence n'a pas d'en-tête MessageId.

    • Un message CreateSequence n'a pas d'en-tête ReplyTo.

  • B1602 : WCF génère l'erreur Action Not Supported en réponse à un message qui n'a pas d'en-tête Sequence et a un en-tête Action non reconnu dans la spécification WS-ReliableMessaging.

  • B1603 : WCF génère l'erreur Endpoint Unavailable pour indiquer que le point de terminaison ne traite pas la séquence au terme de l'examen des en-têtes d'adressage du message CreateSequence.

Composition du protocole

Composition avec WS-Addressing

WCF prend en charge deux versions de WS-Addressing : WS-Addressing 2004/08 [WS-ADDR] et W3C WS-Addressing 1.0 Recommendations [WS-ADDR-CORE] et [WS-ADDR-SOAP].

Bien que la spécification de la messagerie WS-Reliable mentionne WS-Addressing 2004/08 uniquement, cela ne constitue pas une restriction en ce qui concerne la version WS-Addressing à utiliser. Voici une liste des contraintes qui s'appliquent à WCF :

  • R2101 : aussi bien WS-Addressing 2004/08 que WS-Addressing 1.0 peuvent être utilisés avec la messagerie WS-Reliable.

  • R2102 : une version unique de WS-Addressing doit être utilisée dans l'ensemble d'une séquence WS-ReliableMessaging ou dans une paire de séquences réciproques corrélées à l'aide du mécanisme wsrm:Offer.

Composition avec SOAP

WCF prend en charge l'utilisation combinée de SOAP 1.1 et SOAP 1.2 avec WS-ReliableMessaging.

Composition avec WS-Security et WS-SecureConversation

WCF protège les séquences WS-ReliableMessaging en utilisant le transport sécurisé (HTTPS), la composition avec WS-Security et la composition avec WS-Secure Conversation. Voici une liste des contraintes qui s'appliquent à WCF :

  • R2301 : pour protéger l'intégrité d'une séquence WS-ReliableMessaging en plus de l'intégrité et de la confidentialité des messages individuels, WCF requiert l'utilisation de WS-Secure Conversation.

  • R2302 :unesession WS-Secure Conversation doit être établie avant d'établir la ou les séquences de messagerie WS-Reliable.

  • R2303 : si la durée de vie de la séquence de messagerie WS-Reliable dépasse celle de la session WS-Secure Conversation, le SecurityContextToken établi à l'aide de WS-Secure Conversation doit être renouvelé par le biais de la liaison WS-Secure Conversation Renewal correspondante.

  • B2304 :la séquence de messagerie WS-Reliable ou une paire de séquences réciproques corrélées est toujours liée à une session WS-SecureConversation unique.

    La source WCF génère l'élément wsse:SecurityTokenReference dans la section extensibilité des éléments du message CreateSequence.

  • R2305 : lorsqu'il est composé avec WS-Secure Conversation, un message CreateSequence doit contenir l'élément wsse:SecurityTokenReference.

Assertion WS-Policy de la messagerie WS-Reliable

WCF utilise l'assertion WS-Policy wsrm:RMAssertion de WS-ReliableMessaging pour décrire les fonctionnalités des points de terminaison. Voici une liste des contraintes qui s'appliquent à WCF :

  • B3001 : WCF attache l'assertion WS-Policy wsrm:RMAssertion aux éléments wsdl:binding. WCF prend en charge les attachements aux éléments wsdl:binding et wsdl:port.

  • B3002 : WCF prend en charge les propriétés facultatives suivantes de l'assertion WS-ReliableMessaging, et assure leur contrôle sur l’élément WCF ReliableMessagingBindingElement :

    • wsrm:InactivityTimeout

    • wsrm:AcknowledgementInterval

    Voici un exemple.

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

Extension de messagerie WS-Reliable pour le contrôle de flux

WCF utilise l'extensibilité de WS-ReliableMessaging pour fournir un moyen facultatif de contrôle plus poussé sur le flux des messages de séquence.

Le contrôle de flux s’active en définissant la propriété ReliableSessionBindingElement.FlowControlEnabled à la valeur true. Voici une liste des contraintes qui s'appliquent à WCF :

  • B4001 : lorsque le contrôle de flux de la messagerie fiable est activé, WCF génère un élément netrm:BufferRemaining dans la section extensibilité des éléments de l'en-tête SequenceAcknowledgement.

  • B4002 : lorsque le contrôle de flux de la messagerie fiable est activé, WCF n’exige pas la présence d'un élément netrm:BufferRemaining dans l'en-tête SequenceAcknowledgement, comme indiqué dans l'exemple suivant.

    <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 utilise netrm:BufferRemaining pour spécifier le nombre de nouveaux messages que la destination de messagerie fiable peut mettre en mémoire tampon.

  • B4004 : le service de messagerie fiable de WCF limite le nombre de messages transmis lorsque la destination de messagerie fiable ne peut pas recevoir les messages rapidement. La destination de la messagerie fiable met en mémoire tampon les messages et la valeur de l’élément tombe à 0.

  • B4005 : WCF génère des valeurs entières netrm:BufferRemaining comprises dans la plage inclusive de 0 à 4096 et lit des valeurs entières comprises dans la plage inclusive de 0 à la valeur maxInclusive 214748364 pour xs:int.

Modèles d’échange de messages

Cette section décrit le comportement de WCF lorsque WS-ReliableMessaging est utilisé dans différents modèles d’échange de messages. Pour chaque modèle d'échange de messages, les deux scénarios de déploiements suivants sont considérés :

  • Initiateur non adressable : l'initiateur est derrière un pare-feu ; le répondeur peut remettre des messages à celui-ci uniquement sur les réponses HTTP.

  • Initiateur adressable : l'initiateur et le répondeur peuvent tous les deux recevoir des requêtes HTTP ; en d'autres termes, deux connexions HTTP réciproques peuvent être établies.

Initiateur unidirectionnel, non adressable

Liaison

WCF fournit un modèle unidirectionnel d'échange de messages qui utilise une séquence sur un canal HTTP. WCF utilise les requêtes HTTP pour transmettre tous les messages du RMS au RMD, et la réponse HTTP pour transmettre tous les messages du RMD au RMS.

Échange CreateSequence

L'initiateur WCF génère un message CreateSequence sans offre. Le répondeur WCF s'assure que CreateSequence ne contient pas d’offre avant de créer une séquence. Le répondeur WCF retourne un message CreateSequenceResponse en réponse à la requête HTTP CreateSequence.

SequenceAcknowledgement

L'initiateur WCF traite les accusés de réception sur la réponse de tous les messages à l’exception du message CreateSequence et des messages d'erreur. Le répondeur WCF génère toujours un accusé de réception autonome dans la réponse à la séquence et aux messages AckRequested.

Message TerminateSequence

WCF traite TerminateSequence comme une opération unidirectionnelle, ce qui signifie que la réponse HTTP présente un corps vide et le code d'état HTTP 202.

Initiateur unidirectionnel, adressable

Liaison

WCF fournit un modèle unidirectionnel d'échange de messages qui utilise une séquence sur un canal HTTP entrant et un sortant. WCF utilise les requêtes HTTP pour transmettre tous les messages. Toutes les réponses HTTP ont un corps vide et le code d'état HTTP 202.

Échange CreateSequence

L'initiateur WCF génère un message CreateSequence sans offre. Le répondeur WCF s'assure que CreateSequence ne contient pas d’offre avant de créer une séquence. Le répondeur WCF transmet le message CreateSequenceResponse sur une requête HTTP adressée avec la référence de point de terminaison ReplyTo.

Initiateur duplex, adressable

Liaison

WCF fournit un modèle d'échange de messages bidirectionnel et entièrement asynchrone qui utilise deux séquences sur un canal HTTP entrant et un sortant. WCF utilise les requêtes HTTP pour transmettre tous les messages. Toutes les réponses HTTP ont un corps vide et le code d'état HTTP 202.

Échange CreateSequence

L'initiateur WCF génère un message CreateSequence avec une offre. Le répondeur WCF s'assure que CreateSequence contient une offre avant de créer une séquence. WCF envoie le message CreateSequenceResponse sur la requête HTTP adressée à la référence de point de terminaison ReplyTo de CreateSequence.

Durée de vie de séquence

WCF traite les deux séquences comme une seule session duplex intégral.

Lorsqu’une erreur est générée et fait échouer une séquence, WCF s'attend à ce que le point de terminaison distant mette les deux séquences en échec. À la lecture d'une erreur qui fait échouer une séquence, WCF met les deux séquences en échec.

WCF peut fermer sa séquence sortante et poursuivre le traitement des messages sur sa séquence entrante. Inversement, WCF peut traiter la fermeture de la séquence entrante et continuer d’envoyer des messages sur sa séquence sortante.

Initiateur demande-réponse, non adressable

Liaison

WCF fournit un modèle unidirectionnel d'échange de messages de type demande-réponse qui utilise deux séquences sur un canal HTTP. WCF utilise les requêtes HTTP pour transmettre les messages de la séquence de demande, et les réponses HTTP pour transmettre les messages de la séquence de réponse.

Échange CreateSequence

L'initiateur WCF génère un message CreateSequence avec une offre. Le répondeur WCF s'assure que CreateSequence contient une offre avant de créer une séquence. Le répondeur WCF retourne un message CreateSequenceResponse en réponse à la requête HTTP CreateSequence.

Message unidirectionnel

Pour réussir un protocole d’échange de messages unidirectionnel, l'initiateur WCF transmet un message de séquence de demande sur la requête HTTP et reçoit un message SequenceAcknowledgement autonome sur la réponse HTTP. SequenceAcknowledgement doit accepter le message transmis.

Le répondeur WCF peut répondre à la demande en retournant un accusé de réception, une erreur ou bien une réponse présentant un corps vide et le code d'état HTTP 202.

Messages bidirectionnels

Pour réussir un échange de messages bidirectionnel, l'initiateur WCF transmet un message de séquence de demande sur la requête HTTP et reçoit un message de séquence de réponse sur la réponse HTTP. La réponse doit contenir un SequenceAcknowledgement qui accuse réception du message de séquence de demande transmis.

Le répondeur WCF peut répondre à la demande en retournant une réponse d'application, une erreur ou bien une réponse présentant un corps vide et le code d'état HTTP 202.

En raison de la présence de messages unidirectionnels et du délai d'attente des réponses d'application, le numéro de séquence du message de séquence de demande et le numéro de séquence du message de réponse n'ont aucune corrélation.

Nouvelles tentatives de réponses

WCF repose sur la corrélation demande-réponse HTTP pour la corrélation de protocole d'échange de messages bidirectionnel. De ce fait, l'initiateur WCF n’arrête pas les tentatives de transmission d’un message de séquence de demande lorsque ce message a fait l’objet d’un accusé de réception, mais les arrête quand la réponse HTTP contient un accusé de réception, un message utilisateur ou une erreur. Le répondeur WCF refait des tentatives de réponse sur le tronçon de requête HTTP de la demande à laquelle la réponse est corrélée.

Échange LastMessage

L'initiateur WCF génère et transmet un dernier message au corps vide sur le tronçon de requête HTTP. WCF requiert une réponse, mais ignore le message de réponse réel. Le répondeur WCF répond au dernier message au corps vide de la séquence de demande en retournant le dernier message au corps vide de la séquence de réponse.

Si le répondeur WCF reçoit un dernier message qui ne contient pas l'URI d’action http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage, il retourne un dernier message en réponse. Dans le cas d'un protocole d'échange de messages bidirectionnel, le dernier message contient le message d'application ; dans le cas d'un protocole d'échange de messages unidirectionnel, le dernier message est vide.

Le répondeur WCF ne requiert pas d'accusé de réception pour le dernier message au corps vide de la séquence de réponse.

Échange TerminateSequence

Lorsque toutes les demandes ont reçu une réponse valide, l'initiateur WCF génère et transmet le message TerminateSequence de la séquence de demande sur le tronçon de requête HTTP. WCF requiert une réponse, mais ignore le message de réponse réel. Le répondeur WCF répond au message TerminateSequence de la séquence de demande en retournant le message TerminateSequence de la séquence de réponse.

Dans une séquence d'arrêt normale, les deux messages TerminateSequence incluent un SequenceAcknowledgement complet.

Initiateur demande/réponse, adressable

Liaison

WCF fournit un modèle d'échange de messages de type demande-réponse qui utilise deux séquences sur un canal HTTP entrant et un sortant. WCF utilise les requêtes HTTP pour transmettre tous les messages. Toutes les réponses HTTP ont un corps vide et le code d'état HTTP 202.

Échange CreateSequence

L'initiateur WCF génère un message CreateSequence avec une offre. Le répondeur WCF s'assure que CreateSequence contient une offre avant de créer une séquence. WCF envoie le message CreateSequenceResponse sur la requête HTTP adressée à la référence de point de terminaison ReplyTo de CreateSequence.

Corrélation demande/réponse

L’initiateur WCF s'assure que tous les messages de demande d'application contiennent un élément MessageId et une référence de point de terminaison ReplyTo. L'initiateur WCF applique la référence de point de terminaison ReplyTo du message CreateSequence sur chaque message de demande d'application. Le répondeur WCF requiert que les messages de demande entrants contiennent un élément MessageId et un élément ReplyTo. Le répondeur WCF s'assure que l'URI de la référence de point de terminaison du message CreateSequence et de tous les messages de demande d'application est identique.