Partager via

Protocole de Messagerie Fiable version 1.1

Cette rubrique décrit les détails de l’implémentation de Windows Communication Foundation (WCF) pour le protocole WS-ReliableMessaging février 2007 (version 1.1) nécessaire pour l’interopérabilité à l’aide du transport HTTP. WCF suit la spécification WS-ReliableMessaging avec les contraintes et les clarifications expliquées dans cette rubrique. Notez que le protocole WS-ReliableMessaging version 1.1 est implémenté à partir de .NET Framework 3.5.

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

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

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

  • Répondeur : 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://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
Fssf (WS-Policy 1.2 ou WS-Policy 1.5)

Messagerie

Création de séquences

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

  • B1101 : L'initiateur WCF utilise la même référence de point de terminaison que le CreateSequence du message ReplyTo, AcksTo et Offer/Endpoint.

  • R1102 : Les références de point de terminaison AcksTo, ReplyTo et Offer/Endpoint dans le message CreateSequence doivent avoir des valeurs d'adresse dont les représentations sous forme de chaîne sont identiques, de sorte qu'elles correspondent octet par octet.

    • Le répondeur WCF vérifie que la partie URI des références de point de terminaison AcksTo, ReplyTo et Endpoint sont identiques avant de créer une séquence.

  • R1103 : Les références de point de terminaison AcksTo, ReplyTo et Offer/Endpoint dans le message CreateSequence doivent avoir le même ensemble de paramètres de référence.

    • WCF n'applique pas, mais suppose que les paramètres de référence des références de point de terminaison AcksTo, ReplyTo et Offer/Endpoint sur CreateSequence sont identiques. Il utilise les paramètres de la référence de point de terminaison ReplyTo pour les accusés de réception et les messages de séquences réciproques.

  • B1104 : L’initiateur WCF ne génère pas l’élément facultatif Expires ou Offer/Expires dans le message CreateSequence.

  • B1105 : Lors de l’accès au message CreateSequence, le répondeur WCF utilise la valeur du Expires dans l’élément CreateSequence comme valeur du Expires dans l’élément CreateSequenceResponse. Sinon, le répondeur WCF lit et ignore les valeurs Expires et Offer/Expires.

  • B1106 : Lors de l’accès au CreateSequenceResponse message, l’initiateur WCF lit la valeur facultative Expires , mais ne l’utilise pas.

  • B1107 : L’initiateur et le répondeur WCF génèrent toujours l’élément facultatif IncompleteSequenceBehavior dans les éléments CreateSequence/Offer et CreateSequenceResponse.

  • B1108 : WCF utilise uniquement les valeurs DiscardFollowingFirstGap et NoDiscard dans l'élément IncompleteSequenceBehavior.

    • WS-ReliableMessaging utilise le Offer mécanisme pour établir les deux séquences corrélées inverses qui forment une session.

  • B1109 : Si CreateSequence contient un élément Offer, le répondeur unidirectionnel WCF rejette la séquence proposée en répondant avec un CreateSequenceResponse sans élément Accept.

  • B1110 : Si un répondeur de messagerie fiable rejette la séquence proposée, l’initiateur WCF génère une erreur dans la séquence nouvellement établie.

  • B1111 : Si CreateSequence ne contient pas d’élément Offer, le répondeur WCF bidirectionnel rejette la séquence proposée en répondant avec une faute CreateSequenceRefused.

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

  • R1113 : Lorsque deux séquences inverses sont établies à l’aide du Offer mécanisme, tous les messages sur les deux séquences qui circulent de l’initiateur vers 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 de WS-ReliableMessaging WCF fournit une session fiable pour les modèles de messagerie duplex unidirectionnelle, de demande-réponse et de messagerie duplex complète. Le mécanisme WS-ReliableMessaging Offer sur CreateSequence et CreateSequenceResponse vous permet d’établir deux séquences de conversation corrélées et fournit un protocole de session adapté à tous les points de terminaison de messages. É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 autorise également la « superposition » des accusés de réception de séquence sur les messages d'application. Par conséquent, les contraintes R1102, R1112 et R1113 s’appliquent à WCF.

Un exemple de message CreateSequence.

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequence</wsa:Action>
    <wsa:MessageID>urn:uuid:949cca61-8813-42ff-ab33-18d9e3fa82fa</wsa:MessageID>
    <wsa:ReplyTo>
        <wsa:Address>http://Business456.com/clientA</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CreateSequence>
      <wsrm:AcksTo>
        <wsa:Address>http://Business456.com/clientA</wsa:Address>
      </wsrm:AcksTo>
      <wsrm:Offer>
        <wsrm:Identifier>urn:uuid:066b4730-fc82-458a-a5c1-210be4fb4e4e</wsrm:Identifier>
        <wsrm:Endpoint>
          <wsa:Address>http://Business456.com/clientA</wsa:Address>
        </wsrm:Endpoint>
        <wsrm:IncompleteSequenceBehavior>DiscardFollowingFirstGap</wsrm:IncompleteSequenceBehavior>
      </wsrm:Offer>
    </wsrm:CreateSequence>
  </s:Body>
</s:Envelope>

Un exemple de message CreateSequenceResponse.

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequenceResponse</wsa:Action>
    <wsa:RelatesTo>urn:uuid:949cca61-8813-42ff-ab33-18d9e3fa82fa</wsa:RelatesTo>
    <wsa:To s:mustUnderstand="1">http://Business456.com/clientA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CreateSequenceResponse>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:IncompleteSequenceBehavior>DiscardFollowingFirstGap</wsrm:IncompleteSequenceBehavior>
      <wsrm:Accept>
        <wsrm:AcksTo>
          <wsa:Address>http://BusinessABC.com/serviceA</wsa:Address>
        </wsrm:AcksTo>
      </wsrm:Accept>
    </wsrm:CreateSequenceResponse>
  </s:Body>
</s:Envelope>

Fermeture d’une séquence

WCF utilise les messages CloseSequence et CloseSequenceResponse pour un arrêt lancé par la source de messagerie fiable. La destination de la messagerie fiable WCF ne déclenche pas l'arrêt, et la source de messagerie fiable WCF ne prend pas en charge un arrêt initié par la destination de messagerie fiable. Les contraintes suivantes s’appliquent :

  • B1201 : La source de messagerie fiable WCF envoie toujours un CloseSequence message pour arrêter la séquence.

  • B1202 : la source de la messagerie fiable attend l'accusé de réception de l'ensemble complet des messages de séquence avant d'envoyer le message CloseSequence.

  • B1203 : La source De messagerie fiable inclut toujours l’élément facultatif LastMsgNumber , sauf si la séquence ne contient pas de messages.

  • R1204 : La destination de la Messagerie Fiable ne doit pas lancer l’arrêt en envoyant un message CloseSequence.

  • B1205 : Lors de la réception d’un CloseSequence message, la source de messagerie fiable WCF considère la séquence incomplète et envoie une erreur.

Un exemple de message CloseSequence.

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CloseSequence</wsa:Action>
    <wsa:MessageID>urn:uuid:6ce1d4c3-e1c1-474f-a8c9-4210e37f7877</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://Business456.com/clientA</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CloseSequence>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:LastMsgNumber>30</wsrm:LastMsgNumber>
    </wsrm:CloseSequence>
  </s:Body>
</s:Envelope>

Exemple de CloseSequenceResponse message :

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

Arrêt de séquence

WCF utilise principalement la TerminateSequence/TerminateSequenceResponse poignée de main après avoir terminé la CloseSequence/CloseSequenceResponse poignée de main. La destination de messagerie fiable WCF ne lance pas d'arrêt, et la source de messagerie fiable ne prend pas en charge l’arrêt lancé par la destination de messagerie fiable. Les contraintes suivantes s’appliquent :

  • B1301 : L’initiateur WCF n'envoie le message TerminateSequence qu'après la réussite de la poignée de main CloseSequence/CloseSequenceResponse.

  • R1302 : WCF vérifie que l’élément LastMsgNumber est cohérent dans tous les messages CloseSequence et TerminateSequence d’une séquence donnée. Cela signifie que LastMsgNumber n’est pas présent sur tous les messages CloseSequence et TerminateSequence, ou qu’il est présent et identique sur tous les messages CloseSequence et TerminateSequence.

  • B1303 : à la réception d'un message TerminateSequence après la négociation de sécurité CloseSequence/CloseSequenceResponse, la destination de messagerie fiable répond avec un message TerminateSequenceResponse. Étant donné que la source de Messagerie Fiable a l’accusé de réception final avant d’envoyer le TerminateSequence message, la destination de Messagerie Fiable sait sans aucun doute que la séquence se termine et récupère immédiatement les ressources.

  • B1304 : Lors de la réception d’un TerminateSequence message avant la CloseSequence/CloseSequenceResponse poignée de main, la destination WCF de messagerie fiable répond avec un TerminateSequenceResponse message. Si la destination de la messagerie fiable détermine qu’il n’y a pas d’incohérences dans la séquence, la destination de la messagerie fiable attend une heure spécifiée par la destination de l’application avant de récupérer des ressources, pour permettre au client de recevoir l’accusé de réception final. Dans le cas contraire, la destination de Messagerie Fiable libère immédiatement les ressources et indique à la destination de l'application que la séquence se termine avec incertitude en générant l’événement Faulted.

Un exemple de message TerminateSequence.

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequence</wsa:Action>
    <wsa:MessageID>urn:uuid:3597a398-4f3c-40f4-9335-8f1515572fdf</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://Business456.com/clientA</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:TerminateSequence>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:LastMsgNumber>30</wsrm:LastMsgNumber>
      </wsrm:TerminateSequence>
  </s:Body>
</s:Envelope>

Exemple de TerminateSequenceResponse message :

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

Séquences

Voici une liste de contraintes qui s’appliquent aux séquences :

  • B1401 : WCF génère et accède aux numéros de séquence qui ne dépassent pas la valeur maximale inclusive de xs:long, soit 9223372036854775807.

Exemple d’en-tête Sequence .

<wsrm:Sequence s:mustUnderstand="1">
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
  <wsrm:MessageNumber>1</wsrm:MessageNumber>
</wsrm:Sequence>

Demander un accusé de réception

WCF utilise l’en-tête AckRequested comme mécanisme de maintien en vie.

Un exemple d’en-tête AckRequested.

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

SequenceAcknowledgement

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

  • R1601 : Lorsque deux séquences inverses sont établies à l’aide du Offer mécanisme, l’en-tête SequenceAcknowledgement peut être inclus dans tout message d’application transmis au destinataire prévu. Le point de terminaison distant doit être en mesure d'accéder à un en-tête SequenceAcknowledgement superposé.

  • B1602 : WCF ne génère pas les en-têtes SequenceAcknowledgement qui contiennent des éléments Nack. WCF valide que chaque Nack élément contient un numéro de séquence, mais ignore sinon l’élément et la Nack valeur.

Exemple d’en-tête SequenceAcknowledgement .

<wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
  <wsrm:AcknowledgementRange Lower="1" Upper="1"></wsrm:AcknowledgementRange>
</wsrm:SequenceAcknowledgement>

Erreurs de la messagerie WS-Reliable

Voici une liste de contraintes qui s'appliquent aux défaillances WS-ReliableMessaging dans l'implémentation WCF. Les contraintes suivantes s’appliquent :

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

  • B1702 : sur SOAP 1.2, 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 imbriqué CreateSequenceRefused , netrm:ConnectionLimitReachedcomme illustré dans l’exemple suivant.

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

Erreurs WS-Addressing

Étant donné que WS-ReliableMessaging utilise WS-Addressing, l’implémentation du WS-ReliableMessaging WCF peut générer et transmettre des erreurs WS-Addressing. Cette section décrit les erreurs WS-Addressing générées et transmises explicitement par WCF au niveau de la couche WS-ReliableMessaging :

  • B1801 :WCF génère et transmet l’erreur Message Addressing Header Required quand l’une des valeurs suivantes est true :

    • Un message CreateSequence, CloseSequence ou TerminateSequence manque un en-tête MessageId.

    • Un message CreateSequence, CloseSequence ou TerminateSequence manque un en-tête ReplyTo.

    • Un message de CreateSequenceResponse, CloseSequenceResponse ou TerminateSequenceResponse manque un en-tête RelatesTo.

  • B1802 : WCF génère et transmet l'erreur Endpoint Unavailable pour indiquer qu'il n'y a aucun point de terminaison en cours d'écoute pour traiter la séquence en fonction de l'analyse des en-têtes d'adressage dans le 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 Recommandations [WS-ADDR-CORE] et [WS-ADDR-SOAP].

Bien que la spécification WS-ReliableMessaging 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 WS-ReliableMessaging donnée ou une paire de séquences inverses corrélées à l’aide du 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 WS-ReliableMessaging à l’aide du transport sécurisé (HTTPS), de la composition avec WS-Security et de la composition avec WS-Secure Conversation. Le protocole WS-ReliableMessaging 1.1, WS-Security 1.1 et WS-Secure Conversation 1.3 doivent être utilisés ensemble. Voici une liste de contraintes qui s’appliquent à WCF :

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

  • R2302 : La session de conversationAWS-Secure doit être établie avant d’établir la séquence WS-ReliableMessaging.

  • R2303 : Si la durée de vie de la séquence WS-ReliableMessaging dépasse la durée de vie de la session de conversation WS-Secure, la SecurityContextToken établie en utilisant WS-Secure Conversation doit être renouvelée à l'aide de la liaison de renouvellement de conversation WS-Secure correspondante.

  • B2304 : une séquenceWS-ReliableMessaging ou une paire de séquences inverses corrélées sont toujours associées à une seule session WS-SecureConversation.

  • R2305: Lorsqu’il est composé avec WS-Secure Conversation, le répondeur WCF exige que le CreateSequence message contienne l’élément wsse:SecurityTokenReference et l’en-tête wsrm:UsesSequenceSTR.

Exemple d’en-tête UsesSequenceSTR .

<wsrm:UsesSequenceSTR></wsrm:UsesSequenceSTR>

Composition avec des sessions SSL/TLS

WCF ne prend pas en charge la composition avec les sessions SSL/TLS :

  • B2401 : WCF ne génère pas l’en-tête wsrm:UsesSequenceSSL .

  • R2402 : un initiateur de messagerie fiable ne doit pas envoyer un CreateSequence message avec un wsrm:UsesSequenceSSL en-tête à un répondeur WCF.

Composition avec WS-Policy

WCF prend en charge deux versions de WS-Policy : WS-Policy 1.2 et WS-Policy 1.5.

Assertion WS-Policy de la messagerie WS-ReliableMessaging

WCF utilise l'assertion WS-Policy wsrm:RMAssertion de WS-ReliableMessaging 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 wsrmn:RMAssertion aux éléments wsdl:binding. WCF prend en charge les pièces jointes aux éléments wsdl:binding et wsdl:port.

  • B3002 : WCF ne génère jamais la wsp:Optional balise.

  • B3003 : quand il accède à l’assertion WS-Policy wsrmp:RMAssertion, WCF ignore l’étiquette wsp:Optional et traite la stratégie WS-RM comme obligatoire.

  • R3004 : Étant donné que WCF ne compose pas avec des sessions SSL/TLS, WCF n’accepte pas la stratégie qui spécifie wsrmp:SequenceTransportSecurity.

  • B3005 : WCF génère toujours l’élément wsrmp:DeliveryAssurance .

  • B3006 : WCF spécifie toujours l’assurance wsrmp:ExactlyOnce de remise.

  • B3007 : WCF génère et lit les propriétés suivantes de l’assertion WS-ReliableMessaging et fournit un contrôle sur ces propriétés dans WCFReliableSessionBindingElement :

    • netrmp:InactivityTimeout

    • netrmp:AcknowledgementInterval

    Exemple d’un 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>

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

WCF utilise l'extensibilité de WS-ReliableMessaging pour fournir un contrôle facultatif plus strict sur le flux de messages 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 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, comme indiqué dans l'exemple suivant.

    <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 : Même lorsque le contrôle de flux de messagerie fiable est activé, WCF ne nécessite pas d’élément netrm:BufferRemaining dans l’en-tête SequenceAcknowledgement .

  • B4003 : Destination de messagerie fiable WCF utilise netrm:BufferRemaining pour indiquer le nombre de nouveaux messages qu’il peut mettre en mémoire tampon.

  • B4004 : Lorsque le contrôle de flux de messagerie fiable est activé, la source de messagerie fiable WCF utilise la valeur de netrm:BufferRemaining pour réguler la transmission des messages.

  • 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-ReliableMessaging est utilisé 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 un 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 des requêtes HTTP pour transmettre tous les messages de l’initiateur au répondeur et aux réponses HTTP pour transmettre tous les messages du répondeur à l’initiateur.

CreateSequence Exchange

L’initiateur WCF transmet un CreateSequence message sans Offer élément sur une requête HTTP et attend le CreateSequenceResponse message sur la réponse HTTP. Le répondeur WCF crée une séquence et transmet le CreateSequenceResponse message sans Accept élément sur la réponse HTTP.

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 transmet toujours un accusé de réception autonome sur la réponse HTTP à toutes les séquences et à tous les messages AckRequested.

Échange CloseSequence

L’initiateur WCF transmet un CloseSequence message sur une requête HTTP et attend le CreateSequenceResponse message sur la réponse HTTP. Le répondeur WCF transmet le CloseSequenceResponse message sur la réponse HTTP.

Échange TerminateSequence

L’initiateur WCF transmet un TerminateSequence message sur une requête HTTP et attend le TerminateSequenceResponse message sur la réponse HTTP. Le répondeur WCF transmet le TerminateSequenceResponse message sur la réponse HTTP.

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 transmet un CreateSequence message sans Offer élément sur une requête HTTP. Le répondeur WCF crée une séquence et transmet le CreateSequenceResponse message sans Accept élément sur une requête HTTP.

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. Ce modèle d’échange de messages peut être mélangé avec le Request/ReplyAddressable modèle d’échange de messages initiateur d’une manière limitée. WCF utilise des 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 transmet un message CreateSequence avec un élément Offer sur une requête HTTP. Le répondeur WCF garantit que l’élément CreateSequence possède un Offer élément, puis crée une séquence et transmet le CreateSequenceResponse message avec un Accept élément.

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, unidirectionnel et 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 des requêtes HTTP pour transmettre tous les messages de l’initiateur au répondeur et aux réponses HTTP pour transmettre tous les messages du répondeur à l’initiateur.

CreateSequence Exchange

L'initiateur WCF transmet un message CreateSequence avec un élément Offer dans une requête HTTP et attend le message CreateSequenceResponse dans la réponse HTTP. Le répondeur WCF crée une séquence et transmet le CreateSequenceResponse message avec un Accept élément sur la réponse HTTP.

Message unidirectionnel

Pour effectuer un é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 ne cesse pas de réessayer un message de séquence de requête lorsque ce dernier est reconnu, mais seulement lorsque la réponse HTTP contient un SequenceAcknowledgement, une réponse d'application ou une erreur. Le répondeur WCF retente les réponses sur la réponse HTTP de la requête à laquelle la réponse est corrélée.

Échange CloseSequence

Après avoir reçu tous les messages de séquence de réponse et les accusés de réception pour tous les messages de séquence de requêtes unidirectionnels, l’initiateur WCF transmet un CloseSequence message pour la séquence de requêtes sur une requête HTTP et attend une CloseSequenceResponse réponse HTTP.

La fermeture de la séquence de requêtes ferme implicitement la séquence de réponse. Cela signifie que l'initiateur WCF inclut le dernier SequenceAcknowledgement de la séquence de réponse dans le message CloseSequence et que la séquence de réponse n'a pas d'échange CloseSequence.

Le répondeur WCF garantit que toutes les réponses sont acceptées et transmettent le CloseSequenceResponse message sur la réponse HTTP.

Échange TerminateSequence

Après réception du message CloseSequenceResponse, l'initiateur WCF transmet un message TerminateSequence pour la séquence de demande sur une requête HTTP, puis il attend le message TerminateSequenceResponse sur la réponse HTTP.

Comme l’échange CloseSequence , la fin de la séquence de requêtes met implicitement fin à la séquence de réponse. Cela signifie que l'initiateur WCF inclut le message SequenceAcknowledgement final de la séquence de réponse sur le message TerminateSequence et que la séquence de réponse n'a pas d'échange TerminateSequence.

Le répondeur WCF transmet le TerminateSequenceResponse message sur la réponse HTTP.

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. Ce modèle d’échange de messages peut être mélangé au Duplex, Addressable modèle d’échange de messages initiateur de manière limitée. 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 transmet un message CreateSequence avec un élément Offer sur une requête HTTP. Le répondeur WCF garantit que le CreateSequence dispose d’un Offer élément crée ensuite une séquence et transmet le CreateSequenceResponse message avec un Accept élément.

Corrélation de demande/réponse

Les éléments suivants s’appliquent à toutes les demandes et réponses corrélées :

  • WCF garantit que tous les messages de demande d’application portent une ReplyTo référence de point de terminaison et un MessageId.

  • WCF applique la référence de point de terminaison local à chaque message de demande d'application ReplyTo. La référence de point de terminaison local est le message CreateSequence de l’initiateur ReplyTo et le message CreateSequence du répondeur To.

  • WCF garantit que les messages de requête entrants portent un MessageId et un ReplyTo.

  • WCF garantit que l’URI de la ReplyTo référence de point de terminaison de tous les messages de demande d’application correspond à la référence de point de terminaison local telle que définie précédemment.

  • WCF garantit que toutes les réponses portent les en-têtes corrects RelatesTo et To selon les règles de corrélation de requête/réponse wsa.

  • Last updated on