Partager via

Protocole de messagerie fiable version 1,1

  • Article

Cette rubrique couvre en détail l’implémentation Windows Communication Foundation (WCF) pour le protocole WS-ReliableMessaging de février 2007 (version 1.1) 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.1 est implémenté à partir de .NET Framework 3.5.

Le protocole WS-ReliableMessaging de février 2007 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 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://docs.oasis-open.org/ws-rx/wsrm/200702
netrm http://schemas.microsoft.com/ws/2006/05/rm
s http://www.w3.org/2003/05/soap-envelope
wsa http://schemas.xmlsoap.org/ws/2005/08/addressing
wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wssecurity-secext-1.0.xsd
wsrmp http://docs.oasis-open.org/ws-rx/wsrmp/200702
netrmp http://schemas.microsoft.com/ws-rx/wsrmp/200702
wsp (WS-Policy 1.2 ou WS-Policy 1.5)

Messagerie

Création de la séquence

WCF implémente des messages CreateSequence et CreateSequenceResponse 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 les références ReplyTo, AcksTo et Offer/Endpoint du message CreateSequence.

  • R1102 : les références de point de terminaison AcksTo, ReplyTo et Offer/Endpoint dans le message CreateSequence doivent avoir des valeurs d'adresse avec des représentations sous forme de chaîne identiques qui correspondent à l'octet.

    • Le répondeur WCF vérifie que la partie URI des références de point de terminaison AcksTo, ReplyTo et Endpoint est identique 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 jeu 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 Expires ou Offer/Expires facultatif dans le message CreateSequence.

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

  • B1106 : quand il accède au message CreateSequenceResponse, l'initiateur WCF lit la valeur Expires facultative, mais il ne l'utilise pas.

  • B1107 : l'initiateur et le répondeur WCF génèrent toujours l'élément IncompleteSequenceBehavior facultatif 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 mécanisme Offer pour établir deux séquences corrélées réciproques qui forment une session.

  • B1109 : si CreateSequence contient un élément Offer, le répondeur WCF unidirectionnel rejette la séquence présentée en retournant un CreateSequenceResponse sans élément Accept comme réponse.

  • B1110 : si un répondeur de messagerie fiable rejette la séquence présentée, l'initiateur WCF fait échouer la nouvelle séquence établie.

  • B1111 : si CreateSequence ne contient pas d'élément Offer, le répondeur WCF bidirectionnel rejette la séquence présentée en retournant une erreur CreateSequenceRefused comme réponse.

  • 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 réciproques sont établies à l'aide du mécanisme Offer, tous les messages sur les deux séquences circulant de l'initiateur au 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 et CreateSequenceResponse vous permet d'établir deux séquences réciproques corrélées et 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 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.

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>

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 messagerie fiable WCF ne lance pas d'arrêt, et la source de messagerie fiable WCF ne prend pas en charge l’arrêt lancé par la destination de messagerie fiable. Les contraintes suivantes s’appliquent :

  • B1201 : la source de messagerie fiable WCF envoie toujours un message CloseSequence 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 LastMsgNumber facultatif sauf si la séquence ne contient pas de messages.

  • R1204 : la destination de messagerie fiable ne doit pas initier l'arrêt en envoyant un message CloseSequence.

  • B1205 : à la réception d'un message CloseSequence, la source de messagerie fiable WCF considère que la séquence est incomplète et retourne une erreur.

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 message CloseSequenceResponse :

<s:Envelope>
  <s:Header>
    <wsrm:SequenceAcknowledgement>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:AcknowledgementRange Lower="1" Upper="30"></wsrm:AcknowledgementRange>
      <wsrm:Final></wsrm:Final>
      <netrm:BufferRemaining>8</netrm:BufferRemaining>
    </wsrm:SequenceAcknowledgement>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CloseSequenceResponse</wsa:Action>
    <wsa:RelatesTo>urn:uuid:6ce1d4c3-e1c1-474f-a8c9-4210e37f7877</wsa:RelatesTo>
    <wsa:To s:mustUnderstand="1">http://Business456.com/clientA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CloseSequenceResponse>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
    </wsrm:CloseSequenceResponse>
  </s:Body>
</s:Envelope>

Séquence d'arrêt

WCF utilise essentiellement l’établissement de la liaison TerminateSequence/TerminateSequenceResponse après l’achèvement de l’établissement de la liaison CloseSequence/CloseSequenceResponse. 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 envoie seulement le message TerminateSequence une fois la liaison CloseSequence/CloseSequenceResponse établie.

  • R1302 : WCF vérifie que l'élément LastMsgNumber est cohérent sur tous les messages CloseSequence et TerminateSequence pour une séquence donnée. Cela signifie que LastMsgNumber est soit absent sur tous les messages CloseSequence et TerminateSequence, soit 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 message TerminateSequence, la destination de messagerie fiable sait sans doute que la séquence se termine, et libère immédiatement les ressources.

  • B1304 : à la réception d'un message TerminateSequence avant l’établissement de la liaison CloseSequence/CloseSequenceResponse, la destination de messagerie fiable WCF retourne un message TerminateSequenceResponse comme réponse. Si la destination de messagerie fiable détermine que la séquence ne contient aucune incohérence, elle attend l'heure spécifiée par la destination d'une application avant de libérer des ressources afin de permettre au client de recevoir l'accusé de réception final. Sinon, la destination de messagerie fiable libère immédiatement des ressources et indique à la destination d'application que la séquence se termine en déclenchant l'événement Faulted.

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 message TerminateSequenceResponse :

<s:Envelope>
  <s:Header>
    <wsrm:SequenceAcknowledgement>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:AcknowledgementRange Lower="1" Upper="30"></wsrm:AcknowledgementRange>
      <wsrm:Final></wsrm:Final>
      <netrm:BufferRemaining>8</netrm:BufferRemaining>
    </wsrm:SequenceAcknowledgement>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequenceResponse</wsa:Action>
    <wsa:RelatesTo>urn:uuid:3597a398-4f3c-40f4-9335-8f1515572fdf</wsa:RelatesTo>
    <wsa:To s:mustUnderstand="1">://Business456.com/clientA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:TerminateSequenceResponse>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
    </wsrm:TerminateSequenceResponse>
  </s:Body>
</s:Envelope>

Séquences

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

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

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 un mécanisme persistant.

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 réciproques sont établies au moyen du mécanisme Offer, l'en-tête SequenceAcknowledgement peut être inclus dans tout message d'application transmis au destinataire souhaité. 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 vérifie que chaque élément Nack contient un numéro de séquence, mais sinon ignore l'élément Nack et sa 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 des contraintes qui s'appliquent à l'implémentation WCF des erreurs WS-ReliableMessaging. Les contraintes suivantes s’appliquent :

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

  • 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 CreateSequenceRefused imbriqué, netrm:ConnectionLimitReached, comme indiqué 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 WCF de WS-ReliableMessaging peut générer et transmettre des erreurs WS-Addressing. Cette section traite des erreurs WS-Addressing que WCF génère et transmet explicitement au niveau de la couche WS-ReliableMessaging :

  • B1801 : WCF génère et transmet l'erreur Message Addressing Header Required lorsque l'une des conditions suivantes est satisfaite :

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

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

    • Il manque un en-tête CreateSequenceResponse à un message CloseSequenceResponse, TerminateSequenceResponse ou 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 Recommendations [WS-ADDR-CORE] et [WS-ADDR-SOAP].

Si la spécification WS-ReliableMessaging mentionne WS-Addressing 2004/08 uniquement, elle ne limite pas la version WS-Addressing à utiliser. Voici une liste des contraintes qui s'appliquent à WCF :

  • R2101 : WS-Addressing 2004/08 et WS-Addressing 1.0 peuvent être utilisés ensemble 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 une paire de séquences réciproques corrélées à l'aide du mécanisme 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. Le protocole WS-ReliableMessaging 1.1, WS-Security 1.1 et le protocole WS-Secure Conversation 1.3 doivent être utilisés ensemble. 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 l'établissement de la ou des séquences WS-ReliableMessaging.

  • R2303 : si la durée de vie de la séquence WS-ReliableMessaging 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 de renouvellement WS-Secure Conversation correspondante.

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

  • R2305 : lorsqu'il est composé avec WS-Secure Conversation, le répondeur WCF requiert que le message CreateSequence 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 les 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 de message CreateSequence avec un en-tête wsrm:UsesSequenceSSL à 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 des contraintes qui s'appliquent à WCF :

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

  • B3002 : WCF ne génère jamais l’étiquette wsp:Optional.

  • 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 les 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 de remise wsrmp:ExactlyOnce.

  • B3007 : WCF génère et lit les propriétés suivantes de l'assertion WS-ReliableMessaging, et assure leur contrôle sur l’élément WCF ReliableSessionBindingElement :

    • netrmp:InactivityTimeout

    • netrmp:AcknowledgementInterval

    Exemple de RMAssertion.

    <wsrmp:RMAssertion>
  <wsp:Policy>
    <wsrmp:SequenceSTR/>
    <wsrmp:DeliveryAssurance>
      <wsp:Policy>
        <wsrmp:ExactlyOnce/>
        <wsrmp:InOrder/>
      </wsp:Policy>
    </wsrmp:DeliveryAssurance>
  </wsp:Policy>
  <netrmp:InactivityTimeout Milliseconds="600000"/>
  <netrmp:AcknowledgementInterval Milliseconds="200"/>
</wsrmp:RMAssertion>

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, 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 requiert pas d'élément netrm:BufferRemaining dans l'en-tête SequenceAcknowledgement.

  • B4003 : la destination de messagerie fiable WCF utilise netrm:BufferRemaining pour spécifier le nombre de nouveaux messages pouvant être mis 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 netrm:BufferRemaining pour limiter la transmission de 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 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 uniquement des messages à celui-ci 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 de l'initiateur au répondeur, et les réponses HTTP pour transmettre tous les messages du répondeur à l'initiateur.

Échange CreateSequence

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

Échange TerminateSequence

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

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

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. Ce modèle d’échange de messages peut être combiné avec le modèle d’échange de messages initiateur Request/Reply, Addressable d’une 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 le code d'état HTTP 202.

Échange CreateSequence

L'initiateur WCF transmet un message CreateSequence avec un élément Offer sur une requête HTTP. Le répondeur WCF vérifie que le message CreateSequence contient un élément Offer, puis il crée une séquence et transmet le message CreateSequenceResponse avec un élément Accept.

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

Échange CreateSequence

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

Message unidirectionnel

Pour réussir un é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 élément SequenceAcknowledgement, une réponse d'application ou une erreur. Le répondeur WCF refait des tentatives de réponse sur la réponse HTTP de la demande à laquelle la réponse est corrélée.

Échange CloseSequence

Après réception de tous les messages de séquence de réponse et accusés de réception pour tous les messages de séquence de demande unidirectionnels, l'initiateur WCF transmet un message CloseSequence pour la séquence de demande sur une requête HTTP et attend le message CloseSequenceResponse sur la réponse HTTP.

La fermeture de la séquence de demande ferme implicitement 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 CloseSequence et que la séquence de réponse n'a pas d'échange CloseSequence.

Le répondeur WCF s'assure que toutes les réponses ont fait l’objet d’un accusé de réception, puis il transmet le message CloseSequenceResponse 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, terminer la séquence de demande termine implicitement 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 message TerminateSequenceResponse sur la réponse HTTP.

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. Ce modèle d'échange de messages peut être combiné avec le modèle d'échange de messages initiateur Duplex, Addressable d'une 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 le code d'état HTTP 202.

Échange CreateSequence

L'initiateur WCF transmet un message CreateSequence avec un élément Offer sur une requête HTTP. Le répondeur WCF vérifie que le message CreateSequence contient un élément Offer, puis il crée une séquence et transmet le message CreateSequenceResponse avec un élément Accept.

Corrélation demande/réponse

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

  • WCF s'assure que tous les messages de demande d'application contiennent une référence de point de terminaison ReplyTo et un élément MessageId.

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

  • WCF vérifie que les messages de demande entrants contiennent un élément MessageId et un élément ReplyTo.

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

  • WCF vérifie que toutes les réponses contiennent les en-têtes RelatesTo et To appropriés conformément aux règles de corrélation demande-réponse wsa.