Partager via

Reliable Messaging Protocol version 1.0

Cette rubrique traite des détails de l’implémentation de Windows Communication Foundation (WCF) pour le protocole WS-Reliable Messaging Février 2005 (version 1.0) nécessaire pour l’interopérabilité à l’aide du transport HTTP. WCF suit la spécification WS-Reliable Messaging avec les contraintes et les clarifications expliquées dans cette rubrique. Notez que le protocole WS-ReliableMessaging version 1.0 est implémenté à partir de WinFX.

Le protocole WS-Reliable Messaging février 2005 est implémenté dans WCF par le ReliableSessionBindingElement.

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

  • Initiateur : le client qui lance WS-Reliable création de séquence de messages

  • Répondeur : le service qui reçoit les demandes de l’initiateur

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

Préfixe Namespace
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équences

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

  • B1101 : L’initiateur WCF ne génère pas l’élément Expire facultatif dans le CreateSequence message ou, dans les cas où le CreateSequence message contient un Offer élément, l’élément facultatif Expires dans l’élément Offer .

  • B1102 : Lors de l’accès au CreateSequence message, wcfResponder envoie et reçoit les deux Expires éléments s’ils existent, mais n’utilise pas leurs valeurs.

WS-Reliable Messaging introduit le Offer mécanisme permettant d’établir les deux séquences corrélées inverses qui forment une session.

  • R1103 : Si CreateSequence contient un Offer élément, le répondeur de messagerie fiable doit accepter la séquence et répondre avec CreateSequenceResponse cet wsrm:Accept élément, former deux séquences inverses corrélées ou rejeter la CreateSequence demande.

  • R1104 : SequenceAcknowledgement et les messages d’application qui circulent sur la séquence inverse doivent être envoyés à la référence de ReplyTo point de terminaison du CreateSequence.

  • R1105 : AcksTo et ReplyTo les références de point de terminaison dans le CreateSequence fichier doivent avoir des valeurs d’adresse qui correspondent aux octets.

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

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

    WCF ne s’applique pas, mais suppose que [paramètres de référence] sont AcksToReplyToCreateSequence identiques et utilisent [paramètres de référence] à partir de la référence de point de ReplyTo terminaison pour les accusés de réception et les messages de séquence inverse.

  • R1107 : Lorsque deux séquences inverses sont établies à l’aide du Offer mécanisme, SequenceAcknowledgement et que les messages d’application qui circulent sur des séquences inverses doivent être envoyés à la ReplyTo référence de point de terminaison du CreateSequence.

  • R1108 : Lorsque deux séquences inverses sont établies à l’aide du mécanisme Offer, la [address] propriété de l’élément wsrm:AcksTo Enfant Endpoint Reference de l’élément wsrm:AcceptCreateSequenceResponse doit correspondre en octets à l’URI de destination du CreateSequence.

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

    WCF utilise WS-Reliable Messagerie pour établir des sessions fiables entre l’initiateur et le répondeur. L’implémentation de la messagerie WS-Reliable WCF fournit une session fiable pour les modèles de messagerie unidirectionnelle, de demande-réponse et de messagerie duplex complète. Le mécanisme de messagerie WS-Reliable Offer vous CreateSequence/CreateSequenceResponse permet d’établir deux séquences inverses corrélées et fournit un protocole de session adapté à tous les points de terminaison de message. Étant donné que WCF fournit une garantie de sécurité pour une telle session, y compris la protection de bout en bout pour l’intégrité de session, il est pratique de s’assurer que les messages destinés à la même partie arrivent à la même destination. Cela permet également un stockage piggy 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.

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

Un 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 de contraintes qui s’appliquent aux séquences :

  • B1201 :WCF génère et accède aux numéros de séquence pas plus élevés que xs:longla valeur inclusive maximale, 9223372036854775807.

  • B1202 :WCF génère toujours un dernier message vide avec l’URI d’action de 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 LastMessage élément tant que l’URI d’action n’est pas http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage.

Exemple d’en-tête de séquence.

<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 AckRequested l’en-tête comme mécanisme keep-alive. WCF ne génère pas l’élément facultatif MessageNumber . Lors de la réception d’un message avec un AckRequested en-tête qui contient l’élément MessageNumber , WCF ignore la valeur de l’élément MessageNumber , comme illustré dans l’exemple suivant.

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

En-tête SequenceAcknowledgement

WCF utilise le mécanisme piggy-back pour les accusés de réception de séquence fournis dans WS-Reliable Messaging.

  • R1401 : Lorsque deux séquences inverses sont établies à l’aide du Offer mécanisme, l’en-tête SequenceAcknowledgement peut être inclus dans n’importe quel message d’application transmis au destinataire prévu.

  • B1402 : Lorsque WCF doit générer un accusé de réception avant de recevoir des messages de séquence (par exemple, pour satisfaire un AckRequested message), WCF génère un SequenceAcknowledgement en-tête qui contient la plage 0-0, comme illustré 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 SequenceAcknowledgement pas d’en-têtes qui contiennent un Nack élément, mais prend en charge Nack les éléments.

Erreurs de la messagerie WS-Reliable

Voici une liste de contraintes qui s’appliquent à l’implémentation WCF des erreurs de messagerie WS-Reliable :

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

  • Le point de terminaison B1502 :WCF peut générer CreateSequenceRefused des erreurs, comme 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 supplémentaire CreateSequenceRefused , netrm:ConnectionLimitReachedcomme illustré 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-Reliable Messaging utilise L’adressage WS, l’implémentation de la messagerie WS-Reliable WCF peut générer des erreurs WS-Addressing. Cette section décrit les erreurs WS-Addressing générées explicitement par WCF au niveau de la couche de messagerie WS-Reliable :

  • B1601 :WCF génère l’en-tête d’adressage de message d’erreur requis quand l’une des valeurs suivantes est true :

    • Un message manque un Sequence en-tête et un Action en-tête.

    • Un CreateSequence message est manquant dans un MessageId en-tête.

    • Un CreateSequence message est manquant dans un ReplyTo en-tête.

  • B1602 :WCF génère l’action d’erreur non prise en charge en réponse à un message manquant d’un Sequence en-tête et dont Action l’en-tête n’est pas reconnu dans la spécification de messagerie WS-Reliable.

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

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 Recommandations [WS-ADDR-CORE] et [WS-ADDR-SOAP].

Bien que la spécification WS-Reliable Messaging mentionne uniquement WS-Addressing 2004/08, elle ne limite pas la version WS-Addressing à utiliser. Voici une liste de contraintes qui s’appliquent à WCF :

  • R2101 :Les deux WS-Addressing 2004/08 et WS-Addressing 1.0 peuvent être utilisés avec WS-Reliable Messaging.

  • R2102 :Une seule version de WS-Addressing doit être utilisée dans une séquence de messagerie WS-Reliable donnée ou une paire de séquences inverses corrélées à l’aide du wsrm:Offer mécanisme.

Composition avec SOAP

WCF prend en charge l’utilisation de SOAP 1.1 et SOAP 1.2 avec la messagerie WS-Reliable.

Composition avec WS-Security et WS-SecureConversation

WCF offre une protection pour les séquences de messagerie WS-Reliable à l’aide du transport sécurisé (HTTPS), de la composition avec WS-Security et de la composition avec WS-Secure Conversation. Voici une liste de contraintes qui s’appliquent à WCF :

  • R2301 :Pour protéger l’intégrité d’une séquence de messagerie WS-Reliable en plus de l’intégrité et de la confidentialité des messages individuels, WCF exige que WS-Secure Conversation soit utilisée.

  • R2302 :AWS-Secure session conversation doit être établie avant d’établir WS-Reliable séquences de messagerie.

  • R2303 : si la durée de vie de la séquence de messagerie WS-Reliable dépasse la durée de vie de la session conversation WS-Secure, l’établissement SecurityContextToken à l’aide de WS-Secure Conversation doit être renouvelé à l’aide de la liaison de renouvellement de conversation WS-Secure correspondante.

  • B2304 :WS-Reliable séquence de messagerie ou une paire de séquences inverses corrélées sont toujours liées à une session WS-SecureConversation unique.

    La source WCF génère l’élément wsse:SecurityTokenReference dans la section d’extensibilité de l’élément du CreateSequence message.

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

assertion de WS-Reliable messagerie WS-Policy

WCF utilise WS-Reliable Messaging WS-Policy Assertion wsrm:RMAssertion pour décrire les fonctionnalités des points de terminaison. Voici une liste de contraintes qui s’appliquent à WCF :

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

  • B3002 : WCF prend en charge les propriétés facultatives suivantes d’assertion de messagerie WS-Reliable et fournit un contrôle sur ces propriétés sur wcfReliableMessagingBindingElement :

    • wsrm:InactivityTimeout

    • wsrm:AcknowledgementInterval

    Voici un exemple.

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

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

WCF utilise WS-Reliable extensibilité de la messagerie pour fournir un contrôle plus strict facultatif sur le flux de message de séquence.

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

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

  • B4002 : Lorsque le contrôle de flux de messagerie fiable est activé, WCF ne nécessite pas qu’un netrm:BufferRemaining élément soit présent dans l’en-tête SequenceAcknowledgement , comme illustré 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 indiquer le nombre de nouveaux messages que la destination de messagerie fiable peut mettre en mémoire tampon.

  • B4004 :Le service de messagerie fiable WCF limite le nombre de messages transmis lorsque l’application de destination de messagerie fiable ne peut pas recevoir rapidement des messages. La destination de la messagerie fiable met en mémoire tampon les messages et la valeur de l’élément passe à 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 xs:int 214748364 pour maxInclusive.

Modèles d’échange de messages

Cette section décrit le comportement de WCF lorsque WS-Reliable Messagerie est utilisée pour différents modèles d’échange de messages. Pour chaque modèle d’échange de messages, les deux scénarios de déploiement suivants sont pris en compte :

  • Initiateur non adressable : l’initiateur se trouve derrière le pare-feu ; Le répondeur peut remettre des messages à l’initiateur uniquement sur les réponses HTTP.

  • Initiateur adressable : l’initiateur et le répondeur peuvent tous deux être envoyés des requêtes HTTP ; en d’autres termes, deux connexions HTTP inverses peuvent être établies.

Initiateur unidirectionnel non adressable

Reliure

WCF fournit un modèle d’échange de messages unidirectionnel à l’aide d’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.

CreateSequence Exchange

L’initiateur WCF génère un CreateSequence message sans offre. Le répondeur WCF garantit que l’offre CreateSequence n’a pas d’offre avant de créer une séquence. Le répondeur WCF répond à la CreateSequence demande avec un CreateSequenceResponse message.

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 fois à la séquence et AckRequested aux messages.

Message TerminateSequence

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

Initiateur unidirectionnel, adressable

Reliure

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

CreateSequence Exchange

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

Initiateur duplex, adressable

Reliure

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

CreateSequence Exchange

L’initiateur WCF génère un CreateSequence message avec une offre. Le répondeur WCF garantit que l’offre CreateSequence est proposée avant de créer une séquence. WCF envoie la CreateSequenceResponse requête HTTP adressée à la CreateSequenceréférence de point de terminaison.ReplyTo

Durée de vie de séquence

WCF traite les deux séquences comme une session entièrement duplex.

Lors de la génération d'une erreur qui perturbe une séquence, WCF s'attend à ce que le point de terminaison distant perturbe les deux séquences. Lors de la lecture d'un défaut qui affecte une séquence, WCF affecte les deux séquences.

WCF peut fermer sa séquence sortante et continuer à traiter les messages sur sa séquence entrante. À l’inverse, WCF peut traiter la fermeture de la séquence entrante et continuer à envoyer des messages sur sa séquence sortante.

Initiateur demande-réponse, non adressable

Reliure

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

CreateSequence Exchange

L’initiateur WCF génère un CreateSequence message avec une offre. Le répondeur WCF garantit que l’offre CreateSequence est proposée avant de créer une séquence. Le répondeur WCF répond à la CreateSequence demande avec un CreateSequenceResponse message.

Message unidirectionnel

Pour terminer un protocole d’échange de messages unidirectionnel, l’initiateur WCF transmet un message de séquence de requêtes sur la requête HTTP et reçoit un message autonome SequenceAcknowledgement sur la réponse HTTP. Le SequenceAcknowledgement doit accuser réception du message.

Le répondeur WCF peut répondre à la demande avec un accusé de réception, une erreur ou une réponse avec un corps vide et un code d’état HTTP 202.

Messages bidirectionnels

Pour terminer correctement un protocole d’échange de messages bidirectionnel, l’initiateur WCF transmet un message de séquence de requêtes 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 porter un SequenceAcknowledgement accusé de réception du message de séquence de requête transmis.

Le répondeur WCF peut répondre à la demande avec une réponse d’application, une erreur ou une réponse avec un corps vide et un code d’état HTTP 202.

En raison de la présence de messages unidirectionnels et de la synchronisation des réponses de l'application, le numéro de séquence des messages de requête séquentielle et le numéro de séquence des messages de réponse séquentielle n'ont aucune corrélation.

Nouvelles tentatives de réponses

WCF s’appuie sur la corrélation de requête-réponse HTTP pour la corrélation de protocole d’échange de messages bidirectionnel. En raison de cela, l’initiateur WCF n’arrête pas de réessayer un message de séquence de requêtes lorsque le message de séquence de requête est reconnu, mais plutôt lorsque la réponse HTTP porte un accusé de réception, un message utilisateur ou une erreur. Le répondeur WCF retente les réponses sur la partie de requête HTTP de la requête à laquelle la réponse est corrélée.

LastMessage Exchange

L’initiateur WCF génère et transmet un dernier message vide sur la jambe de requête HTTP. WCF nécessite une réponse, mais ignore le message de réponse réel. Le répondeur WCF répond au dernier message vide de la séquence de requête avec le dernier message vide de la séquence de réponse.

Si le répondeur WCF reçoit un dernier message dans lequel l’URI d’action n’est pas http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage, WCF répond avec un dernier message. Dans le cas d’un protocole d’échange de messages bidirectionnel, le dernier message porte le message de l’application ; dans le cas d’un protocole d’échange de messages unidirectionnel, le dernier message est vide.

Le répondeur WCF ne nécessite pas d’accusé de réception pour le dernier message 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 de la séquence de TerminateSequence requêtes sur la jambe de requête HTTP. WCF nécessite une réponse, mais ignore le message de réponse réel. Le répondeur WCF répond au message de la séquence de TerminateSequence requêtes avec le message de la séquence de TerminateSequence réponse.

Dans une séquence d’arrêt normale, les deux TerminateSequence messages portent une plage SequenceAcknowledgementcomplète.

Initiateur demande/réponse, adressable

Reliure

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

CreateSequence Exchange

L’initiateur WCF génère un CreateSequence message avec une offre. Le répondeur WCF garantit que l’offre CreateSequence est proposée avant de créer une séquence. WCF envoie la CreateSequenceResponse requête HTTP adressée à la CreateSequenceréférence de point de terminaison.ReplyTo

Corrélation de demande/réponse

L’initiateur WCF garantit que tous les messages de demande d’application portent une MessageId référence de point de terminaison et de ReplyTo point de terminaison. L’initiateur WCF applique la CreateSequence référence de point de terminaison du ReplyTo message sur chaque message de demande d’application. Le répondeur WCF nécessite que les messages de requête entrants portent un MessageId et un ReplyTo. Le répondeur WCF garantit que l’URI de la référence de point de terminaison des messages de requête de l’application et de CreateSequence tous les messages de demande d’application sont identiques.

  • Last updated on