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
• Services web W3C adressage 1.0 - Core
• Services web W3C adressage 1.0 - Liaison SOAP
• W3C Web Services Addressing 1.0 - Liaison WSDL
• Services web W3C adressage 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
• MTOM WS-Policy Assertion

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

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 de l’en-tête

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 les en-têtes restants ne sont pas compris, mais marqués comme mustUnderstand et lèvent une exception. Les messages qui contiennent mustUnderstand des en-têtes ciblés au destinataire ne sont pas traités par le code d’application du 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’espace de valeur entier de xs:boolean l’en-tête mustUnderstand (0, 1, false, true)

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

Liaison 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 et W3C.WsAddressing.EndpointReferenceType la EndpointReference classe (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 du EndpointReference type utilisé dans les messages échangés avec un point de terminaison WCF doit correspondre à la version de WS-Addressing implémentée par ce point de terminaison.

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 sp:IssuedToken d’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 à partir de la boîte de dialogue, WS-Addressing en-têtes wsa:FaultTo de message 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 WS-Addressing exigences relatives au traitement des messages en fonction du modèle d’échange de messages utilisé.

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

message One-Way

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:Actionet 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 MessageID, ReplyToet FaultTo les en-têtes. 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.

Request-Reply

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 wsa:To, wsa:Actionet wsa:RelatesTo les en-têtes dans le message de réponse, 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 la référence de ReplyTo point de terminaison dans la demande.

Erreurs d’adressage des services web

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

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

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

Liaisons 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 des points de terminaison pour une version WS-Addressing particulière.

L’assertion de stratégie suivante a l’objet de la 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.

<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 censée être envoyée à une demande envoyée à un point de terminaison qui utilise la liaison HTTP Adressage et WSDL SOAP 1.x, la réponse doit être envoyée à l’aide de 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>

L’utilisation de l’assertion suivante qui a l’objet de la stratégie de point de terminaison [WS-PA] sur les points de terminaison qui utilisent des liaisons HTTP SOAP 1.1.x SOAP 1.x nécessite que deux connexions HTTP inverses distinctes soient utilisées pour les messages transmis du demandeur au répondeur et au répondeur, 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 [address] propriété non égale si http://www.w3.org/2005/08/addressing/anonymous le point de terminaison utilise une liaison HTTP SOAP 1.1 WSDL 1.x et a une alternative de stratégie avec une wsap10:UsingAddressing ou wsap:UsingAddressing une assertion 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 avoir un en-tête avec une ReplyTo[address] propriété égale si http://www.w3.org/2005/08/addressing/anonymous le point de terminaison utilise une liaison HTTP SOAP 1.1 SOAP 1.x et a une alternative de stratégie avec wsap:UsingAddressing assertion et aucune cdp:CompositeDuplex assertion attachée.

La spécification WSDL d’adressage WSDL tente de décrire des liaisons de protocole similaires en introduisant un élément <wsaw:Anonymous/> avec trois valeurs textuelles (obligatoires, facultatives et interdites) pour indiquer les exigences de 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. WS-Addressing liaison WSDL 1.0 (WS-ADDR10-WSDL) définit un attribut similaire. 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

WS -ADDR10-WSDL section 4.1 étend l’élément wsdl:port pour inclure l’élément <wsa10:EndpointReference…/> enfant pour décrire le point de terminaison en termes 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 a une autre stratégie jointe avec une <wsaw10:UsingAddressing/> assertion de stratégie, l’élément correspondant wsdl:port peut contenir un élément <wsa10:EndpointReference …/>enfant.

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

• R3533 : si un point de terminaison a une autre stratégie jointe avec <wsap:UsingAddressing/> l’assertion de stratégie, l’élément correspondant wsdl:port peut contenir un élément <wsa:EndpointReference …/>enfant.

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

Composition avec WS-Security

Selon les sections relatives à la sécurité dans WS-ADDR et WS-ADDR10, tous les en-têtes de message d’adressage sont recommandés pour être signés avec le corps du message pour 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 One-Way

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 et wsa10:Action les wsa10:To éléments. 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 action paramètre de l’en-tête Content-Type correspond à la valeur de l’en-tête de wsa10:Action message.

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. Assurez-vous que l’enveloppe SOAP à encoder ne contient aucun élément d’information d’élément avec un [namespace name] ou http://www.w3.org/2004/08/xop/include plusieurs [local name] éléments 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 avec les enfants de chaque élément d’information identifié à l’étape précédente remplacée 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 CONTENT-Transfer-Encoding MIME avec le binaire de valeur.

   4. Si l’élément d’informations d’élément optimisé (le [parent] de l’élément d’informations d’élément nouvellement inséré xop:Include ) a un élément d’informations xmime:contentType d’attribut, 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 des données binaires décodées à partir des caractères remplacés traités en tant qu’en-tête Base64, Content-ID de 4b, Content-Transfer-Encoding de 4c, En-tête Content-Type s’il est 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 «< » et «> » englobants, l’échappement URL de la chaîne restante et ajoutez le préfixe cid:. Le jeu de caractères minimal suivant doit être échappé par RFC1738 et RFC2396. D’autres caractères peuvent être échappés.

      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’informations dans l’enveloppe SOAP construite, qui a, en tant que seul membre de sa propriété [children], un élément d’information xop:Include d’élément :

   1. Supprimez le cid: préfixe et unscape 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 « »,< «> ».

   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 de type de contenu HTTP

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 plusieurs parties/connexes (sans respect de la casse) et de ses paramètres. Les noms de 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 d’informations de démarrage avec la valeur , application/soap+xmlplacé 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:

  C’EST BIEN ÇA

  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"
  

  C’EST BIEN ÇA

  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"
  

Composant MIME Infoset

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

• 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 le composant MIME Infoset doit suivre msg-id la production de RFC 2822 avec le [CFWS] préfixe et les parties de 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 du formulaire :

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

R4144 : Les processeurs MTOM doivent accepter les valeurs d’en-tête Content-ID qui correspondent aux éléments détendus msg-idsuivants.

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 : le composant Infoset 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 application de type multimédia/xop+xml et parameters 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éfinit le charset paramètre pour application/xop+xml qu’il soit facultatif, il est nécessaire pour l’interopérabilité similaire à la condition BP 1.1 sur le charset paramètre du text/xml type de média.

• R41410 : Les type paramètres et charset les paramètres 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 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 : lorsqu’il est configuré pour utiliser l’optimisation MTOM, un point de terminaison WCF ajoute une assertion de stratégie MTOM à la stratégie attachée à la stratégie correspondante wsdl:binding.

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 corps chiffré et de la signature chiffrée. Notez que la CipherValue valeur de l’objet EncryptedKey n’a pas été identifiée 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--