Protocoles de messagerie

La pile de canaux Windows Communication Foundation (WCF) utilise l’encodage et les canaux de transport pour transformer la représentation de message interne dans son format filaire et l’envoyer à l’aide d’un transport particulier. Le transport le plus courant utilisé pour l’interopérabilité des services Web est HTTP et les encodages les plus courants utilisés par les services Web sont SOAP 1.1, SOAP 1.2 et MTOM (Message Transmission Optimization Mechanism).

Cette rubrique décrit les détails de l’implémentation WCF pour les protocoles suivants utilisés par HttpTransportBindingElement.

Spécification/document :

• HTTP 1.1
• Liaison HTTP SOAP 1.1, Section 7
• Liaison HTTP SOAP 1.2 Section 7

Cette rubrique décrit les détails de l’implémentation WCF pour les protocoles suivants qui TextMessageEncodingBindingElement et MtomMessageEncodingBindingElement utilisent.

Spécification/document :

• XML
• SOAP 1.1
• SOAP 1.2 Core
• WS-Addressing 2004/08
• W3C Web Services Addressing 1.0 - Éléments principaux
• W3C Web Services Addressing 1.0 - Liaison SOAP
• W3C Web Services Addressing 1.0 - Liaison WSDL
• W3C Web Services Addressing 1.0 - Métadonnées
• Liaison WSDL SOAP1.1
• Liaison WSDL SOAP1.2

Cette rubrique décrit les détails de l’implémentation WCF pour les protocoles suivants qui MtomMessageEncodingBindingElement utilisent.

Spécification/document :

• XOP
• Liaison MTOM + SOAP 1.2
• Liaison MTOM SOAP 1.1
• Assertion MTOM WS-Policy

Les espaces de noms XML et les préfixes associés suivants sont utilisés dans cette rubrique :

Préfixe	URI (Uniform Resource Identifier) de l'espace de noms
s11	http://schemas.xmlsoap.org/soap/envelope
s12	http://www.w3.org/2003/05/soap-envelope
wsa	http://www.w3.org/2004/08/addressing
wsam	http://www.w3.org/2007/05/addressing/metadata
wsap	http://schemas.xmlsoap.org/ws/2004/09/policy/addressing
wsa10	http://www.w3.org/2005/08/addressing
wsaw10	http://www.w3.org/2006/05/addressing/wsdl
xop	http://www.w3.org/2004/08/xop/include
xmime	http://www.w3.org/2004/06/xmlmime http://www.w3.org/2005/05/xmlmime
DP	http://schemas.microsoft.com/net/2006/06/duplex

SOAP 1.1 et SOAP 1.2

Modèle d’enveloppe et de traitement

WCF implémente le traitement de l’enveloppe SOAP 1.1 suivant le profil de base 1.1 (BP11) et le profil de base 1.0 (SSBP10). Le traitement de l’enveloppe SOAP 1.2 est implémenté après SOAP12-Part1.

Cette section explique certains choix d’implémentation pris par WCF en ce qui concerne BP11 et SOAP12-Part1.

Traitement obligatoire des en-têtes

WCF suit les règles de traitement des en-têtes marqués mustUnderstand décrits dans les spécifications SOAP 1.1 et SOAP 1.2, avec les variantes suivantes.

Un message qui entre dans la pile de canaux WCF est traité par des canaux individuels configurés par des éléments de liaison associés, par exemple, encodage de message texte, sécurité, messagerie fiable et transactions. Chaque canal reconnaît les en-têtes de l'espace de noms associé et les marque comme compris. Une fois qu’un message entre dans le répartiteur, le formateur d’opération lit les en-têtes attendus par le contrat de message/opération correspondant et les marque comme compris. Ensuite, le répartiteur vérifie si des en-têtes restants ne sont pas compris mais marqués comme mustUnderstand et lève une exception. Les messages qui contiennent des en-têtes mustUnderstand ciblant le destinataire ne sont pas traités par le code de l'application destinataire.

Ce traitement en couches permet la séparation entre les couches d’infrastructure et les couches d’application du nœud SOAP :

• B1111 : Les en-têtes qui ne sont pas compris sont détectés après le traitement du message par la pile de canaux d’infrastructure WCF, mais avant qu’ils ne soient traités par l’application

  La mustUnderstand valeur d’en-tête diffère entre SOAP 1.1 et SOAP 1.2. Le profil de base 1.1 nécessite que la mustUnderstand valeur soit 0 ou 1 pour les messages SOAP 1.1. SOAP 1.2 autorise 0, 1 falseet true comme valeurs, mais recommande d’émettre une représentation canonique des xs:boolean valeurs (false, true).

• B1112 : WCF émet des mustUnderstand valeurs 0 et 1 pour les versions SOAP 1.1 et SOAP 1.2 de l’enveloppe SOAP. WCF accepte l'intégralité de l'espace de valeurs de xs:boolean pour l'en-tête mustUnderstand (0, 1, false, true)

Défaillances SOAP

Voici une liste des implémentations d’erreur SOAP spécifiques à WCF.

• B2121 : WCF retourne les codes d’erreur SOAP 1.1 suivants : s11:mustUnderstand, s11:Clientet s11:Server.

• B2122 : WCF retourne les codes d’erreur SOAP 1.2 suivants : s12:MustUnderstand, s12:Senderet s12:Receiver.

Combinaison HTTP

Liaison HTTP SOAP 1.1

WCF implémente la liaison HTTP SOAP1.1 suivant la spécification Basic Profile 1.1 section 3.4 avec les clarifications suivantes :

• B2211 : le service WCF n’implémente pas la redirection des requêtes HTTP POST.

• B2212 : Les clients WCF prennent en charge les cookies HTTP conformément à la version 3.4.8.

Liaison HTTP SOAP 1,2

WCF implémente la liaison HTTP SOAP 1.2, comme décrit dans la spécification SOAP 1.2-part 2 (SOAP12Part2) avec les clarifications suivantes.

SOAP 1.2 a introduit un paramètre d’action facultatif pour le type de application/soap+xml média. Ce paramètre est utile pour optimiser la répartition des messages sans exiger que le corps du message SOAP soit analysé lorsque WS-Addressing n’est pas utilisé.

• R2221 : Le application/soap+xml paramètre d’action, lorsqu’il est présent sur une requête SOAP 1.2, doit correspondre à l’attribut soapAction de l’élément à l’intérieur wsoap12:operation de la liaison WSDL correspondante.

• R222 : Le application/soap+xml paramètre d’action, lorsqu’il est présent sur un message SOAP 1.2, doit correspondre wsa:Action lorsque WS-Addressing 2004/08 ou WS-Addressing 1.0 sont utilisés.

Lorsque WS-Addressing est désactivé et qu’une requête entrante ne contient pas de paramètre d’action, le message Action est considéré comme non spécifié.

WS-Addressing

WCF implémente 3 versions de WS-Addressing :

• WS-Addressing 2004/08

• W3C Web Services Addressing 1.0 Core (ADDR10-CORE) et liaison SOAP (ADDR10-SOAP)

• WS-Addressing 1.0 - Métadonnées

Références de point de terminaison

Toutes les versions de WS-Addressing que WCF implémente utilisent des références de point de terminaison pour décrire les points de terminaison.

Références de point de terminaison et versions de WS-Addressing

WCF implémente un certain nombre de protocoles d’infrastructure qui utilisent WS-Addressing et en particulier l’élément EndpointReference et la classe W3C.WsAddressing.EndpointReferenceType (par exemple, WS-ReliableMessaging, WS-SecureConversation et WS-Trust). WCF prend en charge l’utilisation d’une version de WS-Addressing avec d’autres protocoles d’infrastructure. Les points de terminaison WCF prennent en charge une version de WS-Addressing par point de terminaison.

Pour R3111, l’espace de noms de l’élément ou type EndpointReference utilisé dans les messages échangés avec un point de terminaison WCF doit correspondre à la version de WS-Addressing implémentée par ce dernier.

Par exemple, si un point de terminaison WCF implémente WS-ReliableMessaging, l’en-tête AcksTo retourné par un tel point de terminaison CreateSequenceResponse utilise la version WS-Addressing que l’élément EncodingBinding spécifie pour ce point de terminaison.

Références de point de terminaison et métadonnées

Un certain nombre de scénarios nécessitent la communication des métadonnées ou une référence aux métadonnées pour un point de terminaison donné.

B3121 : WCF utilise des mécanismes décrits dans la spécification WS-MetadataExchange (MEX) section 6 pour inclure des métadonnées pour les références de point de terminaison par valeur ou par référence.

Considérez un scénario dans lequel un service WCF nécessite une authentification à l’aide d’un jeton SAML (Security Assertions Markup Language) émis par l’émetteur de jeton à l’adresse http://sts.fabrikam123.com. Le point de terminaison WCF décrit cette exigence d’authentification à l’aide d’une assertion sp:IssuedToken avec une assertion imbriquée sp:Issuer pointant vers l’émetteur du jeton. Les applications clientes qui accèdent à l’assertion sp:Issuer doivent savoir comment communiquer avec le point de terminaison de l’émetteur de jeton. Le client doit connaître les métadonnées relatives à l’émetteur du jeton. À l’aide des extensions de métadonnées de référence de point de terminaison définies dans MEX, WCF fournit une référence aux métadonnées de l’émetteur de jeton.

<sp:IssuedToken>
  <sp:Issuer>
    <wsa10:Address>
      http://sts.fabrikam123.com
    </wsa10:Address>
    <wsa10:Metadata>
      <mex:Metadata>
        <mex:MetadataSection>
          <mex:MetadataReference>
            <wsa10:Address>
              http://sts.fabrikam123.com/mex
            </wsa10:Address>
          </mex:MetadataReference>
        </mex:MetadataSection>
      </mex:Metadata>
    </wsa10:Metadata>
  </sp:Issuer>
</sp:IssuedToken>

En-têtes d’adressage des messages

En-têtes de message

Pour les deux versions WS-Addressing, WCF utilise les en-têtes de message suivants comme prescrit par les spécifications wsa:To, , wsa:ReplyTo, wsa:Action, wsa:MessageIDet wsa:RelatesTo.

B3211 : Pour toutes les versions WS-Addressing, WCF honore, mais ne produit pas par défaut, les en-têtes de message WS-Addressing wsa:FaultTo et wsa:From.

Les applications qui interagissent avec les applications WCF peuvent ajouter ces en-têtes de message et WCF les traite en conséquence.

Paramètres et propriétés de référence

WCF implémente le traitement des paramètres de référence de point de terminaison et des propriétés de référence conformément aux spécifications respectives.

B3221 : lorsqu’ils sont configurés pour utiliser WS-Addressing 2004/08, les points de terminaison WCF ne font pas la distinction entre le traitement des propriétés de référence et les paramètres de référence.

Modèles d’échange de messages

La séquence de messages impliqués dans l’appel d’opération de service web est appelée modèle d’échange de messages. WCF prend en charge les modèles d’échange de messages unidirectionnel, de demande-réponse et duplex. Cette section précise les exigences WS-Addressing concernant le traitement des messages, selon le modèle d'échange de message utilisé.

Tout au long de cette section, le demandeur envoie le premier message et le répondeur reçoit le premier message.

Message unidirectionnel

Lorsqu’un point de terminaison WCF est configuré pour prendre en charge les messages avec un modèle donné Action pour suivre un modèle unidirectionnel, le point de terminaison WCF suit les comportements et exigences suivants. Sauf indication contraire, les comportements et les règles s’appliquent aux deux versions de WS-Addressing prises en charge dans WCF :

• R3311 : Le demandeur doit inclure wsa:To, wsa:Action et les en-têtes pour tous les paramètres de référence spécifiés par la référence de point de terminaison. Lorsque WS-Addressing 2004/08 est utilisé et [propriétés de référence] sont spécifiées par la référence de point de terminaison, les en-têtes correspondants doivent également être ajoutés au message.

• B3312 : Le demandeur peut inclure les en-têtes MessageID, ReplyTo et FaultTo. L’infrastructure de récepteur les ignore et elle sera transmise à l’application.

• R3313 : Quand HTTP est utilisé et qu’aucun message n’est envoyé sur la jambe de réponse HTTP, le répondeur doit envoyer une réponse HTTP avec un corps vide et un code d’état HTTP 202.

  Lorsque le transport HTTP est utilisé et que le contrat d’opération déclare un message unidirectionnel, la réponse HTTP peut toujours être utilisée pour l’envoi de messages d’infrastructure, par exemple, la messagerie fiable peut envoyer un SequenceAcknowledgement message sur une réponse HTTP.

• B3314 : Le répondeur WCF n’envoie pas de message d’erreur en réponse à un message unidirectionnel.

Demande-réponse

Lorsqu’un point de terminaison WCF est configuré pour un message avec un message donné Action pour suivre le modèle de demande-réponse, le point de terminaison WCF suit les comportements et les exigences ci-dessous. Sauf indication contraire, les comportements et les règles s’appliquent aux deux versions de WS-Addressing prises en charge dans WCF :

• R3321 : Le demandeur doit inclure dans la requête wsa:To, wsa:Actionet wsa:MessageIDles en-têtes pour tous les paramètres de référence ou propriétés de référence (ou les deux) spécifiés par la référence de point de terminaison.

• R3322 : Quand WS-Addressing 2004/08 est utilisé, ReplyTo doit également être inclus dans la demande.

• R3323 : Quand WS-Addressing 1.0 est utilisé et ReplyTo n’est pas présent dans la requête, une référence de point de terminaison par défaut avec la propriété [address] égale à http://www.w3.org/2005/08/addressing/anonymous est utilisée.

• R3324 : Le demandeur doit inclure dans le message de réponse, les en-têtes wsa:To, wsa:Action, et wsa:RelatesTo, ainsi que les en-têtes pour tous les paramètres de référence ou propriétés de référence (ou les deux) spécifiés par le point de terminaison ReplyTo dans la demande.

Erreurs d’adressage des services web

R3411 : WCF produit les erreurs suivantes définies par WS-Addressing 2004/08.

Code	La cause
wsa:DestinationUnreachable	Le message est arrivé avec un ReplyTo différent de l'adresse de réponse établie pour ce canal ; il n'y a aucun point de terminaison qui écoute l'adresse spécifiée dans l'en-tête To.
wsa:ActionNotSupported	les canaux de l'infrastructure ou le répartiteur associé au point de terminaison ne reconnaissent pas l'action spécifiée dans l'en-tête Action.

R3412 : WCF génère les erreurs suivantes définies par WS-Addressing 1.0.

Code	La cause
wsa10:InvalidAddressingHeader	Dupliquer wsa:To, wsa:ReplyTowsa:From ou wsa:MessageID. Dupliquer wsa:RelatesTo avec le même RelationshipType.
wsa10:MessageAddressingHeaderRequired	L’en-tête d’adressage requis est manquant.
wsa10:DestinationUnreachable	Le message est arrivé avec une ReplyTo adresse de réponse différente de l’adresse de réponse établie pour ce canal. Il n'y a aucun point de terminaison qui écoute l'adresse spécifiée dans l'en-tête To.
wsa10:ActionNotSupported	Une action spécifiée dans l’en-tête Action n’est pas reconnue par les canaux d’infrastructure ou le répartiteur associé au point de terminaison.
wsa10:EndpointUnavailable	Le canal RM renvoie cette erreur, ce qui indique que le point de terminaison ne pourra pas traiter la séquence après l’examen des en-têtes d’adressage contenus dans le message CreateSequence.

Le code dans les tableaux précédents correspond à FaultCode dans SOAP 1.1 et à SubCode dans SOAP 1.2 (avec Code=Sender).

Liaison WSDL 1.1 et assertions de WS-Policy

Indication de l’utilisation de WS-Addressing

WCF utilise des assertions de stratégie pour indiquer la prise en charge d’un point de terminaison pour une version particulière de WS-Addressing.

L’assertion de stratégie suivante définit l’objet de stratégie de point de terminaison [WS-PA] et précise que les messages envoyés et reçus depuis le point de terminaison doivent utiliser WS-Addressing 2004/08.

<wsap:UsingAddressing />

Cette assertion de stratégie augmente la spécification WS-Addressing 2004/08.

L’assertion de stratégie suivante indique que les messages envoyés/reçus doivent utiliser WS-Addressing 1.0.

<wsam:Addressing/>

L’assertion de stratégie suivante a un objet de stratégie de point de terminaison [WS-PA] et indique que les messages envoyés et reçus du point de terminaison doivent utiliser WS-Addressing 2004/08.

<wsaw10:UsingAddressing />

L’élément wsaw10:UsingAddressing est emprunté à [WS-Addressing-WSDL] et est utilisé dans le contexte de WS-Policy conformément à cette spécification, section 3.1.2.

L’utilisation de l’adressage ne modifie pas la sémantique des liaisons HTTP WSDL 1.1, SOAP 1.1 et SOAP 1.2. Par exemple, si une réponse est attendue pour une demande envoyée à un point de terminaison qui utilise l'Adressage et la liaison HTTP de WSDL SOAP 1.x, la réponse doit être envoyée via la réponse HTTP.

Pour les réponses envoyées sur la réponse http, l’assertion WS-AM est la suivante :

<wsam:AnonymousResponses/>

L’assertion de stratégie complète peut ressembler à ceci :

<wsam:Addressing>
    <wsp:Policy>
        <wsam:AnonymousResponses />
    </wsp:Policy>
</wsam:Addressing>

Toutefois, il existe des modèles d’échange de messages qui bénéficient de deux connexions HTTP indépendantes établies entre le demandeur et le répondeur, par exemple, des messages unidirectionnel non sollicités envoyés par le répondeur.

WCF offre une fonctionnalité par laquelle deux canaux de transport sous-jacents peuvent former un canal duplex composite, où un canal est utilisé pour les messages d’entrée et l’autre est utilisé pour les messages de sortie. Dans le cas du transport HTTP, Composite Duplex fournit deux connexions HTTP inverses. Le demandeur utilise une connexion pour envoyer des messages au répondeur, et le répondeur utilise l’autre pour renvoyer des messages au demandeur.

Pour les réponses envoyées sur des requêtes http distinctes, l’assertion ws-am est

<wsam:NonAnonymousResponses/>

L’assertion de stratégie complète peut ressembler à ceci :

<wsam:Addressing>
    <wsp:Policy>
        <wsam:NonAnonymousResponses />
    </wsp:Policy>
</wsam:Addressing>

Pour utiliser l'assertion suivante, qui possède un objet de stratégie de point de terminaison [WS-PA] sur les points de terminaison qui utilisent des liaisons HTTP WSDL 1.1 SOAP 1.x, il est nécessaire d'utiliser deux connexions HTTP réciproques séparées pour transmettre des messages du demandeur au répondeur et du répondeur au demandeur, respectivement.

<cdp:CompositeDuplex/>

L’instruction précédente entraîne les exigences suivantes sur l’en-tête wsa:ReplyTo des messages de requête :

• R3514 : Les messages de requête envoyés à un point de terminaison doivent avoir un ReplyTo en-tête avec la propriété [address] non égale à http://www.w3.org/2005/08/addressing/anonymous si le point de terminaison utilise une liaison HTTP SOAP 1.1 WSDL 1.x et a une alternative de stratégie avec une assertion wsap10:UsingAddressing ou wsap:UsingAddressing couplée à cdp:CompositeDuplex attachée.

• R3515 : Les messages de requête envoyés à un point de terminaison doivent avoir un ReplyTo en-tête avec la [address] propriété égale à http://www.w3.org/2005/08/addressing/anonymous, ou n’ont pas d’en-tête ReplyTo du tout, si le point de terminaison utilise une liaison HTTP WSDL 1.1 SOAP 1.x et a une alternative de stratégie avec wsap10:UsingAddressing assertion et aucune cdp:CompositeDuplex assertion attachée.

• R3516 : Les messages de requête envoyés à un point de terminaison doivent inclure un en-tête avec une propriété ReplyTo égale à [address] si le point de terminaison utilise une liaison HTTP selon le WSDL 1.1 et le SOAP 1.x, et a une alternative de stratégie comportant une assertion http://www.w3.org/2005/08/addressing/anonymous sans assertion wsap:UsingAddressing attachée.

La spécification WSDL de WS-Addressing tente de décrire des liaisons de protocole semblables en présentant un élément <wsaw:Anonymous/> avec trois valeurs textuelles (obligatoire, facultatif et a interdit) pour indiquer des besoins sur l’en-tête wsa:ReplyTo (section 3.2). Malheureusement, cette définition d’élément n’est pas particulièrement utilisable en tant qu’assertion dans le contexte de WS-Policy, car elle nécessite des extensions spécifiques au domaine pour prendre en charge l’intersection d’alternatives utilisant un tel élément comme une assertion. Cette définition d’élément indique également la valeur de l’en-tête ReplyTo par opposition au comportement du point de terminaison sur le câble, ce qui le rend spécifique au transport HTTP.

Définition d’action

WS-Addressing 2004/08 définit un wsa:Action attribut pour les wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] éléments. La liaison WS-Addressing 1.0 WSDL (WS-ADDR10-WSDL) définit un attribut semblable, wsaw10:Action.

La seule différence entre les deux est la sémantique de modèle d’action par défaut décrite dans la section 3.3.2 de WS-ADDR et la section 4.4.4 de WS-ADDR10-WSDL, respectivement.

Il est raisonnable d’avoir deux points de terminaison qui partagent le même portType (ou contrat, dans la terminologie WCF), mais qui utilisent différentes versions de WS-Addressing. Toutefois, étant donné que l’action est définie par l’action portType et ne doit pas changer entre les points de terminaison qui implémentent le portType, il devient impossible de prendre en charge les deux modèles d’action par défaut.

Pour résoudre cette controverse, WCF prend en charge une seule version de l’attribut Action .

B3521 : WCF utilise l’attribut wsaw10:Action sur wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] les éléments tels que définis dans WS-ADDR10-WSDL pour déterminer l’URI Action des messages correspondants, quelle que soit la version WS-Addressing utilisée par le point de terminaison.

Utiliser la référence de point de terminaison à l’intérieur du port WSDL

La section 4.1 de WS-ADDR10-WSDL étend l'élément wsdl:port de manière à inclure l'élément enfant <wsa10:EndpointReference…/> et décrire le point de terminaison en des termes propres à WS-Addressing. WCF développe cet utilitaire sur WS-Addressing 2004/08, ce qui permet <wsa:EndpointReference…/> d’apparaître en tant qu’élément enfant de wsdl:port.

• R3531 : si un point de terminaison possède une alternative de stratégie attachée avec une assertion de la stratégie <wsaw10:UsingAddressing/>, l'élément wsdl:port correspondant peut contenir un élément enfant <wsa10:EndpointReference …/>.

• R3532 : Si un wsdl:port contient un élément enfant <wsa10:EndpointReference …/>, la valeur de l’élément enfant wsa10:EndpointReference/wsa10:Address doit correspondre à la valeur de l’attribut @address de l’élément frère wsdl:port/wsdl:location.

• R3533 : si un point de terminaison possède une alternative de stratégie attachée avec une assertion de la stratégie <wsap:UsingAddressing/>, l'élément wsdl:port correspondant peut contenir un élément enfant <wsa:EndpointReference …/>.

• R3534 : Si un wsdl:port contient un élément enfant <wsa:EndpointReference …/>, la valeur de l’élément enfant wsa:EndpointReference/wsa:Address doit correspondre à la valeur de l’attribut @address de l’élément frère wsdl:port/wsdl:location.

Composition avec WS-Security

Selon les sections relatives aux considérations de sécurité dans WS-ADDR et WS-ADDR10, il est recommandé que tous les en-têtes de message d’adressage soient signés avec le corps du message, afin de les lier ensemble.

Lorsque WS-Security est utilisé pour la protection de l’intégrité des messages, WS-Addressing en-têtes de message ainsi que les en-têtes résultant des paramètres de référence ou des propriétés (ou les deux) doivent être signés avec le corps du message.

Exemples

Message unidirectionnel

Dans ce scénario, l’expéditeur envoie un message unidirectionnel au destinataire. SOAP 1.2, HTTP 1.1 et W3C WS-Addressing 1.0 sont utilisés.

Structure du message de requête : les en-têtes de message incluent les éléments wsa10:To et wsa10:Action. Le corps du message inclut un élément spécifique <app:Ping> de l’espace de noms de l’application.

En-têtes HTTP : la destination dans POST correspond à l’URI de l’élément wsa10:To .

L’en-tête Content-Type a la valeur requise application/soap+xml par SOAP 1.2. Les paramètres charset et action sont inclus. Le paramètre d’en-tête action Content-Type correspond à la valeur de l’en-tête du message wsa10:Action.

POST http://fabrikam123.com/Service HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8;  
              action="http://fabrikam123.com/Service/OneWay"
Host: 131.107.72.15
Content-Length: 1501
Expect: 100-continue
Proxy-Connection: Keep-Alive
<s12:Envelope>
  <s12:Header>
    <wsa10:To s12:mustUnderstand="1">
        http://fabrikam123.com/Service
    </wsa10:To>
    <wsa10:Action s12:mustUnderstand="1">
        http://fabrikam123.com/Service/OneWay
    </wsa10:Action>
  </s12:Header>
  <s12:Body>
    <Ping xmlns="http://fabrikam123.com/Service/">
      <Text>Hello World</Text>
    </Ping>
  </s12:Body>
</s12:Envelope>

Le récepteur répond avec une réponse HTTP vide et l’état 202. Exemple de réponse HTTP :

HTTP/1.1 202 Accepted
Date: Fri, 15 Jul 2005 08:56:07 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50215
Cache-Control: private
Content-Length: 0

Mécanisme d’optimisation de la transmission des messages SOAP

Cette section décrit les détails de l’implémentation WCF pour http SOAP MTOM. La technologie MTOM est un mécanisme d’encodage de message SOAP de la même classe que l’encodage texte/XML traditionnel ou l’encodage binaire WCF. MTOM inclut les éléments suivants :

• Mécanisme d’encodage et d’empaquetage XML décrit par [XOP] qui optimise les éléments d’informations XML contenant des données binaires codées en base64 dans des parties binaires distinctes.

• Encapsulation MIME du package XOP qui sérialise l’ensemble d’informations XML et chaque partie binaire du package XOP dans une partie MIME distincte.

• Encodage MIME XOP appliqué à l’enveloppe SOAP 1.x.

• Liaison de transport HTTP.

Il est possible d’utiliser MTOM avec des transports non HTTP avec WCF. Toutefois, dans cette rubrique, nous allons nous concentrer sur HTTP.

Le format MTOM tire parti d’un grand ensemble de spécifications couvrant MTOM lui-même, XOP et MIME. La modularité de cet ensemble de spécifications complique quelque peu la reconstruction des exigences exactes sur la sémantique de format et de traitement. Cette section décrit les exigences de format et de traitement pour la liaison HTTP MTOM.

Encodage de message MTOM

Génération de messages MTOM

La section [XOP] 3.1 décrit le processus d’encodage XML avec des éléments d’information qui contiennent des valeurs base64 dans un package XOP défini de manière abstraite.

La séquence d’étapes suivante décrit le processus d’encodage spécifique à MTOM :

1. Vérifiez que l’enveloppe SOAP à encoder ne contient aucun élément d’information avec un [namespace name]http://www.w3.org/2004/08/xop/include et un [local name]Include.

2. Créez un package MIME vide.

3. Identifiez dans l’ensemble d’informations XML d’origine les éléments d’informations à optimiser. Pour que les éléments soient optimisés, les caractères qui composent l’élément [children] d’informations doivent se trouver sous la forme canonique de xs:base64Binary (voir XSD-2, 3.2.16 base64Binary) et ne doivent contenir aucun espace blanc précédant, inline avec ou suivant le contenu d’espace non blanc.

4. Créez une enveloppe SOAP XOP qui est une copie de l'enveloppe SOAP d'origine, mais en remplaçant les enfants de chaque élément d'information identifiés à l'étape précédente par un élément d'information xop:Include construit comme suit :

   1. Transformez les caractères remplacés en données binaires en les traitant en données codées en base64.

   2. Générez une valeur d’en-tête Content-ID unique qui répond aux exigences R3133 et R3134.

   3. Générez un en-tête MIME Content-Transfer-Encoding avec la valeur binaire.

   4. Si l'élément d'information qui est optimisé (le [parent] de l'élément d'information xop:Include inséré) a un élément d'information d'attribut xmime:contentType, générez un en-tête MIME Content-type avec la valeur de l'attribut xmime:contentType.

   5. Générez une nouvelle partie MIME binaire avec le contenu formé par les données binaires décodées des caractères remplacés traités en Base64, l'en-tête Content-ID de l'étape 4b, l'en-tête Content-Transfer-Encoding de l'étape 4c, l'en-tête Content-Type si généré à l'étape 4d.

   6. Ajoutez un href attribut à l’élément xop:Include avec la valeur cid : URI dérivé de la valeur d’en-tête Content-ID générée à l’étape 4b. Supprimez les caractères englobants « < » et « > », utilisez des caractères d’échappement URL pour la chaîne restante, et ajoutez le préfixe cid:. Le jeu de caractères minimum suivant est requis pour un échappement par RFC1738 et RFC2396. D'autres caractères peuvent faire l'objet d'une séquence d'échappement.

      Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
      "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"
      

5. Créez une partie MIME racine avec l’enveloppe SOAP XOP à l’étape 4.

6. Écrivez les en-têtes HTTP, y compris l’en-tête HTTP Content-Type.

7. Écrivez le package MIME.

Traitement des messages MTOM

Le traitement d’un message MTOM est l’inverse exact du processus décrit dans la section précédente « Génération de messages MTOM » :

1. Vérifiez que le composant MIME racine a le type application/xop+xmlde contenu .

2. Construisez une enveloppe SOAP en analysant la partie MIME racine du package en tant que document XML. L’encodage de caractères est déterminé par le charset paramètre du type de contenu du composant MIME racine.

3. Pour chaque élément d'information dans l'enveloppe SOAP construite, qui a comme seul membre de sa propriété [enfant] un élément d'information xop:Include :

   1. Supprimez le préfixe cid: préfixent et annulez toutes les séquences d'échappement d'URI (RFC 2396) dans la valeur de l'attribut @href de l'élément xop:Include. Placez la chaîne de résultat dans "<" et ">".

   2. Recherchez la partie MIME avec la valeur d’en-tête Content-ID qui correspond à la chaîne dérivée à l’étape 3a.

   3. Remplacez l’élément xop:Include d’informations d’élément qui apparaît dans la children propriété de chaque élément par les éléments d’informations de caractère qui représentent l’encodage base64 canonique (voir XSD-2, 3.2.16 base64Binary) du corps d’entité de la partie MIME identifiée à l’étape 3b (remplacez efficacement l’élément xop:Include d’informations d’élément par les données reconstruites à partir du composant package).

En-tête HTTP Content-Type

Voici une liste de clarifications WCF pour le format de l’en-tête HTTP Content-Type d’un message encodé SOAP 1.x MTOM dérivé des exigences indiquées dans la spécification MTOM elle-même et dérivées de MTOM et RFC 2387.

• R4131 : un en-tête HTTP Content-Type doit avoir la valeur de multipart/related (non sensible à la casse) et ses paramètres. Les noms des paramètres ne respectent pas la casse. L’ordre des paramètres n’est pas significatif.

• Le formulaire complet Backus-Naur (BNF) de l’en-tête Content-Type pour les messages MIME est répertorié dans RFC 2045, section 5.1.

• R4132 : un en-tête HTTP Content-Type doit avoir un paramètre de type avec la valeur application/xop+xml placée entre guillemets doubles.

Bien que l’obligation d’utiliser des guillemets doubles n’est pas explicite dans RFC 2387, le texte observe que tous les paramètres de type multimédia multipart/associé contiennent probablement des caractères réservés tels que « @ » ou « / » et ont donc besoin de guillemets doubles.

• R4133 : Un en-tête HTTP Content-Type doit avoir un paramètre de début avec la valeur de l’en-tête Content-ID de la partie MIME qui contient l’enveloppe SOAP 1.x, placée entre guillemets doubles. Si le paramètre de début est omis, la première partie MIME doit contenir l’enveloppe SOAP 1.x.

• R4134 : Un en-tête HTTP Content-Type pour un message encodé SOAP 1.1 MTOM doit inclure le paramètre d’informations de démarrage avec la valeur de texte/xml, placé entre guillemets doubles.

• R4135 : Un en-tête HTTP Content-Type pour un message encodé en MTOM SOAP 1.2 doit inclure le paramètre 'start-info' avec la valeur application/soap+xml, placée entre guillemets doubles.

• R4136 : L’en-tête HTTP Content-Type pour un message codé MTOM SOAP 1.x doit avoir le paramètre de limite avec la valeur (entre guillemets doubles) qui correspond à la limite MIME BNF définie dans RFC 2046, section 5.1.1

  boundary := 0*69<bchars> bcharsnospace
  bchars := bcharsnospace / " "
  bcharsnospace :=    DIGIT / ALPHA / "'" / "(" / ")" / "+"
                      / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"
  

  Exemples:

  CORRECT

  Content-Type: multipart/related; type="application/xop+xml";start=" <part0@tempuri.org>";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1";start-info="text/xml"
  

  CORRECT

  Content-Type: Multipart/Related; type="application/xop+xml";start-info="text/xml";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"
  

  INCORRECT

  Content-Type: Multipart/Related; type=application/xop+xml;start=" <part0@tempuri.org>";start-info="text/xml";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"
  

Partie MIME d'ensemble d'informations

L’enveloppe SOAP 1.x est encapsulée comme partie racine du package MIME XOP et est souvent appelée la partie infoset.

• R4141 : L’enveloppe SOAP 1.x doit être encapsulée en tant que partie racine du package MIME XOP, appelée partie infoset et référencée à partir du type de contenu HTTP.

• R4142 : La partie SOAP Infoset doit inclure les en-têtes MIME suivants : Content-ID, Content-Transfer-Encodinget Content-Type.

Le format de l’en-tête Content-ID est défini par RFC 2045 en tant que

"Content-ID" ":" msg-id

où msg-id est défini dans RFC 2822 (qui remplace RFC 822, référencé dans RFC 2045) comme suit :

msg-id    =       [CFWS] "<" id-left "@" id-right ">" [CFWS]

et est effectivement une adresse e-mail entre «< » et «> ». Le préfixe et le [CFWS] suffixe ont été ajoutés dans RFC 2822 pour porter des commentaires et ne doivent pas être utilisés pour préserver l’interopérabilité.

R4143 : la valeur de l'en-tête Content-ID pour la partie MIME de l'ensemble d'informations doit suivre la production msg-id de RFC 2822 avec les parties [CFWS] préfixe et suffixe omises.

Un certain nombre d’implémentations MIME ont assoupli les exigences relatives à la valeur comprise entre «< » et «> » comme adresse e-mail et utilisée absoluteURI entre «< » et «> » en plus de l’adresse e-mail. Cette version de WCF utilise des valeurs de l’en-tête MIME Content-ID sous la forme de :

Content-ID: <http://tempuri.org/0>

R4144 : Les processeurs MTOM doivent accepter les valeurs d’en-tête Content-ID qui correspondent aux spécifications assouplies msg-id suivantes.

msg-id-relaxed =     [CFWS] "<" (absoluteURI | mail-address) ">" [CFWS]
mail-address   =     id-left "@" id-right

MIME (RFC 2045) fournit l’en-tête Content-Transfer-Encoding pour communiquer l’encodage du contenu du composant MIME. La valeur par défaut définie pour Content-Transfer-Encoding est 7 bits, ce qui n’est pas adapté à la plupart des messages SOAP, de sorte que l’en-tête Content-Transfer-Encoding est nécessaire pour une meilleure interopérabilité :

• R4145 : la partie de l'ensemble d'informations SOAP doit contenir l'en-tête Content-Transfer-Encoding.

• R4146 : Si l’encodage de caractères d’enveloppe SOAP est UTF-8, la valeur de l’en-tête Content-Transfer-Encoding doit être 8 bits.

• R4147 : Si l’encodage de caractères d’enveloppe SOAP est UTF-16, la valeur de l’en-tête Content-Transfer-Encoding doit être binaire.

• Selon [XOP] section 5,

• R4148 : le composant Infoset SOAP1.1 doit contenir un en-tête Content-Type avec le type de média application/xop+xml et les paramètres type="text/xml" et charset.

  Content-Type: application/xop+xml;
                charset=utf-8;type="text/xml"
  

• R4149 : la partie Infoset SOAP 1.2 doit contenir l’en-tête Content-Type avec le type application/xop+xml de média et les paramètres type="application/soap+xml » et charset.

  Content-Type: application/xop+xml;
                charset=utf-8;type="application/soap+xml"
  

  Bien que XOP définisse le paramètre charset de application/xop+xml comme facultatif, il est nécessaire pour l'interopérabilité, similaire à l'exigence BP 1.1 concernant le paramètre charset pour le type de média text/xml.

• R41410 : Les paramètres type et charset doivent être présents sur l’en-tête Content-Type de la partie Infoset SOAP 1.x.

Prise en charge des points de terminaison WCF pour MTOM

L’objectif de MTOM est d’encoder un message SOAP pour optimiser les données encodées en base64. Voici une liste de contraintes :

• R4151 : tout élément d’information d’élément qui contient des données encodées en base64 peut être optimisé.

• B4152 : WCF optimise les éléments d’informations d’élément qui contiennent des données encodées en base64 et dépassent 1024 octets de longueur.

Un point de terminaison WCF configuré pour utiliser MTOM envoie toujours des messages encodés MTOM. Même si aucune partie ne répond aux critères requis, le message est toujours encodé en MTOM (sérialisé en tant que package MIME avec une seule partie MIME contenant l’enveloppe SOAP).

Assertion de WS-Policy pour MTOM

WCF utilise l’assertion de stratégie suivante pour indiquer l’utilisation de MTOM par point de terminaison :

<wsoma:OptimizedMimeSerialization />

• R4211 : L’assertion de stratégie précédente a un objet de stratégie de point de terminaison et spécifie que tous les messages envoyés et reçus à partir du point de terminaison doivent être optimisés à l’aide de MTOM.

• B4212 : en cas de configuration pour utiliser l’optimisation MTOM, un point de terminaison WCF ajoute une assertion de stratégie MTOM à la stratégie jointe à la wsdl:binding correspondante.

Composition avec WS-Security

MTOM est un mécanisme d’encodage similaire au text/xml xml binaire WCF. MTOM offre une composition naturelle avec WS-Security et d’autres protocoles WS-* : un message sécurisé à l’aide de WS-Security peut être optimisé à l’aide de MTOM.

Exemples

Message WCF SOAP 1.1 encodé à l’aide de MTOM

POST http://131.107.72.15/Mtom/svc/service.svc/Soap11MtomUTF8 HTTP/1.1
SOAPAction: "http://xmlsoap.org/echoBinaryAsString"
Content-Type: multipart/related;type="application/xop+xml";
              start="<http://tempuri.org/0>";start-info="text/xml";
       boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"
Host: 131.107.72.15
Content-Length: 1501
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <EchoBinaryAsString xmlns="http://xmlsoap.org/Ping">
      <array>
        <xop:Include
         href="cid:http%3A%2F%2Ftempuri.org%2F1%2F632618206521093670"
         xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
      </array>
    </EchoBinaryAsString>
  </s:Body>
</s:Envelope>
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1
Content-ID: <http://tempuri.org/1/632618206521093670>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
…Binary Content..
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1

Message WCF Secure SOAP 1.2 encodé à l’aide de MTOM

Dans cet exemple, un message est encodé à l’aide de MTOM et SOAP 1.2 qui est protégé à l’aide de WS-Security. Les parties binaires identifiées pour l’encodage sont le contenu du BinarySecurityToken, CipherValue du EncryptedData correspondants à la signature chiffrée et au corps chiffré. Notez que le CipherValue de l’EncryptedKey n’a pas été identifié pour l’optimisation par WCF, car sa longueur est inférieure à 1 024 octets.

POST http://131.107.72.15/Mtom/service.svc/Soap12MtomSecureSignEncrypt HTTP/1.1
Content-Type: multipart/related; type="application/xop+xml";
              start="<http://tempuri.org/0>";
            boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3";
              start-info="application/soap+xml";
              action="http://xmlsoap.org/echoBinaryAsString"
Host: 131.107.72.15
Content-Length: 1941
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="application/soap+xml"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <u:Timestamp u:Id="uuid-4d4ee765-5717-4d53-9ac9-99bddc07df6c-5">
        <u:Created>2005-09-09T06:57:32.488Z</u:Created>
        <u:Expires>2005-09-09T07:02:32.488Z</u:Expires>
      </u:Timestamp>
      <o:BinarySecurityToken u:Id="uuid-4d4ee765-5717-4d53-9ac9-99bddc07df6c-2" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
        <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F1%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
      </o:BinarySecurityToken>
      <e:EncryptedKey Id="_1" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <o:SecurityTokenReference>
            <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">Xeg55vRyK3ZhAEhEf+YT0z986L0=</o:KeyIdentifier>
          </o:SecurityTokenReference>
        </KeyInfo>
        <e:CipherData>          <e:CipherValue>oQfpxwT8/SAGyZQzKE2b4yO6dXuQj7pwJ+5CGL3Rf7C06bQ5ttMoQ9GLJcQYkXTzin+WwHEgs5bj5ml9HKTW9QAU5JJ6lksdymmQvWP5ZtGPBVchO4sofEGoCKmBiZL/DYS/cnbzgnc/3a6NYnc10y2fWGaGLiqa00zijAw7o0Y=</e:CipherValue>
        </e:CipherData>
      </e:EncryptedKey>
      <c:DerivedKeyToken u:Id="_2" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
        <o:SecurityTokenReference>
          <o:Reference URI="#_1"/>
        </o:SecurityTokenReference>
        <c:Nonce>OrEPRX7fISIS4sXYWPMv3g==</c:Nonce>
      </c:DerivedKeyToken>
      <e:ReferenceList xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:DataReference URI="#_3"/>
        <e:DataReference URI="#_4"/>
      </e:ReferenceList>
      <e:EncryptedData Id="_4" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <o:SecurityTokenReference>
            <o:Reference URI="#_2"/>
          </o:SecurityTokenReference>
        </KeyInfo>
        <e:CipherData>
          <e:CipherValue>
            <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F2%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
          </e:CipherValue>
        </e:CipherData>
      </e:EncryptedData>
    </o:Security>
  </s:Header>
  <s:Body u:Id="_0">
    <e:EncryptedData Id="_3" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
      <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
          <o:Reference URI="#_2"/>
        </o:SecurityTokenReference>
      </KeyInfo>
      <e:CipherData>
        <e:CipherValue>
          <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F3%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
        </e:CipherValue>
      </e:CipherData>
    </e:EncryptedData>
  </s:Body>
</s:Envelope>
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/1/632618206525089430>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
...Binary content of BinarySecurityToken - X509 Certificate...
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/2/632618206525089430>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
...Binary serialization of the encrypted primary signature...
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/3/632618206525089430>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
...Binary serialization of the encrypted Body...
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3--