Lisez-moi S.V.P. 

W3C

Langage de description de services web (WSDL) version 2.0 tome 2 — Compléments

Recommandation du W3C du 26 juin 2007

Cette version :
http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626
Dernière version :
http://www.w3.org/TR/wsdl20-adjuncts
Version précédente :
http://www.w3.org/TR/2007/PR-wsdl20-adjuncts-20070523
Rédacteurs :
Roberto Chinnici, Sun Microsystems
Hugo Haas, W3C
Amelia A. Lewis, TIBCO Software
Jean-Jacques Moreau, Canon
David Orchard, BEA Systems
Sanjiva Weerawarana, WSO2

Veuillez consulter la page des errata de ce document, laquelle peut contenir des corrections normatives.

Ce document est également disponible dans les formats non normatifs suivants : PDF, PostScript, XML et texte ordinaire.

Cf. également d'éventuelles traductions.


Résumé

Le langage WSDL 2.0 est un langage XML de description de services web. Ce document, intitulé « Langage de description de services web (WSDL) version 2.0 tome 2 — Compléments », définit des extensions prédéfinies à utiliser dans WSDL 2.0 :

Statut de ce document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On peut trouver la liste des publications actuelles du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à l'adresse http://www.w3.org/TR/.

Il s'agit de la recommandation du W3C du Langage de description de services web (WSDL) version 2.0 tome 2 — Compléments examinée par les membres du W3C et les tiers intéressés. Elle est produite par le groupe de travail Web Services Description, sous l'égide de l'activité Web Services du W3C.

Veuillez envoyer les commentaires concernant ce document à la liste de diffusion publique public-ws-desc-comments@w3.org (archives publiques).

Le groupe de travail a publié une suite de tests en même temps qu'un rapport de mise en œuvre. Une version annotée en différence avec la version précédente de ce document est disponible.

Ce document a été examiné par les membres du W3C, par des développeurs de logiciels et par d'autres groupes du W3C et des tiers intéressés, et approuvé par le Directeur comme recommandation du W3C. C'est un document stable pouvant être utilisé comme document de référence ou cité par un autre document. Le rôle du W3C en produisant la recommandation est d'attirer l'attention sur la spécification et d'en promouvoir le large déploiement. Cela participe à améliorer la fonctionnalité et l'interopérabilité du web.

Ce document est régi par la politique de brevets du W3C de janvier 2002 telle que corrigée par la procédure de transition de politique de brevets du W3C. Le W3C tient une liste publique des divulgations de brevets effectuées en rapport avec les produits livrables du groupe ; cette page contient également des instructions pour la divulgation d'un brevet. Quiconque a connaissance réelle d'un brevet qu'il estime contenir des revendications essentielles doit divulguer cette information conformément à la section 6 de la politique de brevets du W3C.

Table des matières

Annexes


1. Introduction

Le langage de description de services web version 2.0 (WSDL 2.0) [WSDL 2.0 Core Language] fournit un modèle et un format XML pour décrire des services web. WSDL 2.0 permet de séparer la description de la fonctionnalité abstraite offerte par un service des détails concrets d'une description de service tels que « comment » et « où » cette fonctionnalité est offerte.

Ce document (Langage de description de services web (WSDL) version 2.0 tome 2 — Compléments) spécifie les extensions prédéfinies à utiliser dans WSDL 2.0 :

Ce document dépend du Langage de description de sercices web (WSDL) Version 2.0 tome 1 — Cœur du langage [WSDL 2.0 Core Language]. Cf. également le Langage de description de services web (WSDL) version 2.0 tome 0 — Introduction [WSDL 2.0 Primer] pour plus d'informations et des exemples.

1.1 Conventions d'écriture

Les mots-clés DOIT, NE DOIT PAS, OBLIGATOIRE, DEVRA, NE DEVRA PAS, DEVRAIT, NE DEVRAIT PAS, RECOMMANDÉ, PEUT et OPTIONNEL dans ce document doivent être interprétés selon le RFC 2119 [IETF RFC 2119].

Cette spécification utilise tout du long plusieurs préfixes d'espace de noms, qui sont listés dans le tableau 1-1. Notez que le choix d'un préfixe d'espace de noms est arbitraire et n'a pas d'importance sémantique (cf. [XML Namespaces]).

Tableau 1-1. Préfixes et espaces de noms utilisés dans cette spécification
Préfixe Espace de noms Notes
wsdl "http://www.w3.org/ns/wsdl" Cet espace de noms est défini dans [WSDL 2.0 Core Language]. On peut trouver le document XML Schema normatif [XML Schema Structures], [XML Schema Datatypes] de l'espace de noms "http://www.w3.org/ns/wsdl" à http://www.w3.org/ns/wsdl. C'est l'espace de noms par défaut à travers cette spécification.
wsdlx "http://www.w3.org/ns/wsdl-extensions" Cette spécification étend, dans la section 3. Extensions prédéfinies, l'espace de noms "http://www.w3.org/ns/wsdl-extensions" défini dans [WSDL 2.0 Core Language]. On peut trouver un document XML Schema [XML Schema Structures], [XML Schema Datatypes] pour l'espace de noms "http://www.w3.org/ns/wsdl-extensions" à http://www.w3.org/ns/wsdl-extensions.
wsoap "http://www.w3.org/ns/wsdl/soap" Défini par cette spécification. On peut trouver le document XML Schema normatif [XML Schema Structures], [XML Schema Datatypes] de l'espace de noms "http://www.w3.org/ns/wsdl/soap" à http://www.w3.org/ns/wsdl/soap.
whttp "http://www.w3.org/ns/wsdl/http" Défini par cette spécification. On peut trouver le document XML Schema normatif [XML Schema Structures], [XML Schema Datatypes] de l'espace de noms "http://www.w3.org/ns/wsdl/http" à http://www.w3.org/ns/wsdl/http.
wrpc "http://www.w3.org/ns/wsdl/rpc" Défini par cette spécification. On peut trouver le document XML Schema normatif [XML Schema Structures], [XML Schema Datatypes] de l'espace de noms "http://www.w3.org/ns/wsdl/rpc" à http://www.w3.org/ns/wsdl/rpc.
xs "http://www.w3.org/2001/XMLSchema" Défini dans la spécification XML Schema du W3C [XML Schema Structures], [XML Schema Datatypes].

Les noms d'espace de noms de la forme générale "http://example.org/..." ou "http://example.com/..." représentent des adresses URI d'application ou dépendantes du contexte [IETF RFC 3986].

Toutes les parties de cette spécification sont normatives, à l'exception des remarques, des pseudo-schémas, des exemples et des sections marquées explicitement comme non normatives. Des pseudo-schémas sont fournis pour chaque composant, avant la description du composant. Ils fournissent une aide visuelle pour la sérialisation XML [XML 1.0]. La syntaxe des pseudo-schémas BNF est la même que celle employée dans [WSDL 2.0 Core Language].

1.2 Assertions

Les assertions concernant des documents et des composants WSDL 2.0 que le schéma XML de WSDL 2.0 ne fait pas valoir (non enforced) sont signalées par une croix « † » en fin de phrase. À chaque assertion est affecté un identificateur unique composé d'un préfixe textuel descriptif et d'un suffixe numérique unique. Les suffixes numériques sont attribués successivement et jamais réutilisés ; il peut donc y avoir des trous dans la succession. Les identificateurs d'assertion PEUVENT être utilisés par les mises en œuvre de cette spécification quel qu'en soit le but, par exemple pour l'identification d'erreurs (error reporting).

Les assertions et leurs identificateurs sont repris dans la section C. Récapitulatif des assertions.

2. Modèles d'échange de messages prédéfinis

Les modèles d'échange de messages (message exchange patterns) WSDL, appelés ci-dessous des « modèles », définissent la séquence et la cardinalité des messages abstraits listés dans une opération. Les modèles d'échange de messages définissent aussi quels autres nœuds envoient des messages au service, réalisant l'opération, et en reçoivent.

Un nœud (node) est un agent (section 2.3.2.2 Agent dans [Web Services Architecture]) qui peut transmettre ou recevoir un message (ou des messages) décrit(s) dans une description WSDL (ou des descriptions), et les traiter.

Remarque :

Un nœud PEUT être accessible au travers de plus d'une adresse physique ou d'un transport .

Les modèles d'échange de messages décrivent l'interaction au niveau abstrait (de l'interface), qui peut être différent du modèle utilisé par la liaison du protocole sous-jacent (par exemple, des modèles d'échange de messages SOAP ; la section 5.10.3 Règles de liaison SOAP 1.2 contient des règles de liaison pour la sélection d'un modèle d'échange de messages SOAP 1.2, fondées sur le modèle d'échange de messages WSDL en vigueur pour l'extension de liaison SOAP définie à la section 5. Extension de liaison SOAP WSDL).

Par conception, les modèles d'échange de messages WSDL abstraient (abstract out) des types de message spécifiques. Les modèles identifient les paramètres fictifs (placeholders) des messages, et l'opération associe les paramètres fictifs à des types de message spécifiques en utilisant le modèle.

Sauf indication contraire explicite, les modèles d'échange de messages WSDL abstraient les informations spécifiques d'une liaison telles que la coordination (timing) entre les messages, que le modèle soit synchrone ou asynchrone, et que les messages soient envoyés sur un seul canal ou sur des canaux multiples.

Comme les interfaces et les opérations, les modèles d'échange de messages WSDL ne décrivent pas exhaustivement l'ensemble des messages échangés entre un service et d'autres nœuds ; par un accord préalable, un autre nœud ou le service PEUVENT envoyer des messages (l'un à l'autre ou à d'autres nœuds) qui ne sont pas décrits par le modèle . Ainsi, même si un modèle peut définir un seul message envoyé d'un service à un seul autre nœud, le service web peut en pratique effectuer une diffusion groupée (multicast) de ce message à d'autres nœuds.

Pour optimiser la réutilisation, les modèles d'échange de messages WSDL identifient un contrat minimal entre les tiers et les services web, et contiennent seulement des informations pertinentes pour le service web et un tiers.

Cette spécification définit plusieurs modèles d'échange de messages à utiliser avec la spécification WSDL version 2.0 tome 1 — Cœur du langage [WSDL 2.0 Core Language]. D'autres modèles non normatifs sont disponibles dans [WSDL 2.0 Additional MEPs].

2.1 Gabarit des modèles d'échange de messages

Une organisation peut définir d'autres modèles d'échange de messages si elle en est capable et qu'elle le souhaite. Il est recommandé d'utiliser pour les modèles le gabarit général (general template) fourni dans la section 2.1.1 Nom du modèle, après étude des modèles prédéfinis existants.

2.1.1 Nom du modèle

This pattern consists of [number] message[s, in order] as follows:

[enumeration, specifying, for each message] A[n optional] message:

  1. indicated by an Interface Message Reference component whose {message label} is "[label]" and {direction} is "[direction]"

  2. [received from|sent to] ['some' if first mention] node [node identifier]

This pattern uses the rule [fault ruleset reference].

An Interface Operation using this message exchange pattern has a {message exchange pattern} property with the value "[pattern IRI]".

Ce modèle comprend [nombre] message[s, en ordre] comme suit :

[énumeration, définissant chaque message] Un message [optionnel] :

  1. indiqué par un composant Interface Message Reference dont la propriété {message label} est "[intitulé]" et la propriété {direction} est "[direction]"

  2. [reçu|envoyé] [(du|au), ou (d'un|à un) si première mention] nœud [identificateur du nœud]

Ce modèle utilise la règle [référence de règlement d'incident].

Un composant Interface Operation utilisant ce modèle d'échange de messages a une propriété {message exchange pattern} avec la valeur "[adresse IRI du modèle]".

Remarque :
Dans le gabarit, les articles entre crochets indiquent une substitution. Substituer les termes corrects pour chaque article entre crochets.

Remarque :
Les « reçu de » et « envoyé à » sont toujours du point de vue du service, et les nœuds participants hormis le service sont implicitement identifiés comme les expéditeurs ou les destinataires des messages dans l'échange.

2.2 Règles de propagation d'incident

Les modèles WSDL définissent leur modèle de propagation d'incident (fault propagation model) en utilisant les règlements standards (standard rulesets) pour indiquer où les incidents peuvent survenir. Les modèles les plus courants pour la propagation d'incident sont définis dans les sous-sections suivantes et référencés par les modèles de la section 2.3 Modèles d'échange de messages. La « propagation » est définie comme étant une tentative au mieux (best-effort attempt) de transmettre le message d'incident à son destinataire désigné.

Les modèles WSDL définissent la propagation des incidents, pas leur génération. Les nœuds qui génèrent les incidents DOIVENT essayer de propager les incidents conformément au règlement en vigueur, mais il est entendu que la livraison d'un message de réseau est au mieux, elle n'est pas garantie . Les règlements établissent la direction du message d'incident et le destinataire de l'incident ; ils n'assurent aucune fiabilité ou autres garanties de livraison. Lorsqu'un incident est généré, le nœud générateur DOIT essayer de propager l'incident, et il DOIT le faire dans la direction et au destinataire indiqués par le règlement . Par contre, les extensions et les extensions de liaison PEUVENT modifier ces règlements . Par exemple, l'adressage WS-Addressing [WSA 1.0 Core] définit une adresse "FaultTo" pour les messages, qui est utilisée à la place du destinataire indiqué par le règlement.

La génération d'un incident, indépendamment du règlement, termine l'échange .

Des extensions de liaison, des caractéristiques ou des définitions d'extension peuvent écraser la sémantique d'un règlement de propagation d'incident mais cette pratique est fortement déconseillée.

2.2.1 Règle de propagation Fault Replaces Message

Lorsque la règle de propagation Fault Replaces Message est en vigueur, tout message après le premier dans le modèle PEUT être remplacé par un message d'incident, lequel DOIT avoir une direction identique . Le message d'incident DOIT être livré au même nœud cible que le message qu'il remplace, sauf indication contraire par une extension ou une extension de liaison. S'il n'y a pas de chemin vers ce nœud, l'incident DOIT être jeté .

La règle de propagation Fault Replaces Message est identifiée par l'adresse URI suivante : http://www.w3.org/ns/wsdl/fault-replaces-message

2.2.2 Règle de propagation Message Triggers Fault

Lorsque la règle de propagation Message Triggers Fault est en vigueur, tout message y compris le premier dans le modèle PEUT déclencher un message d'incident, lequel DOIT avoir une direction opposée . Le message d'incident DOIT être livré à l'émetteur du message de déclenchement, sauf indication contraire par une extension ou une extension de liaison. Tout nœud PEUT propager un message d'incident, et il NE DOIT PAS le faire plus d'une fois pour chaque message de déclenchement. S'il n'y a pas de chemin vers l'émetteur, l'incident DOIT être jeté .

La règle de propagation Message Triggers Fault est identifié par l'adresse URI suivante : http://www.w3.org/ns/wsdl/message-triggers-fault

2.2.3 Règle de propagation No Faults

Lorsque la règle de propagation No Faults est en vigueur, les incidents NE DOIVENT PAS être propagés .

La règle de propagation No Faults est identifiée par l'adresse URI suivante : http://www.w3.org/ns/wsdl/no-faults

2.3 Modèles d'échange de messages

Les modèles WSDL sont décrits en fonction du modèle de composants WSDL, spécifiquement les composants Interface Message Reference et Interface Fault Reference.

2.3.1 Modèle d'échange de messages In-Only

Le modèle d'échange de message in-only comprend un seul message exactement , comme suit :

  1. Un message :

Le modèle d'échange de messages in-only utilise la règle 2.2.3 Règle de propagation No Faults .

Une opération utilisant ce modèle d'échange de messages a une propriété {message exchange pattern} avec la valeur "http://www.w3.org/ns/wsdl/in-only".

2.3.2 Modèle d'échange de messages Robust In-Only

Le modèle d'échange de message robust-in-only comprend un seul message exactement , comme suit :

  1. Un message :

Le modèle d'échange de messages robust-in-only utilise la règle 2.2.2 Règle de propagation Message Triggers Fault .

Une opération utilisant ce modèle d'échange de messages a une propriété {message exchange pattern} avec la valeur "http://www.w3.org/ns/wsdl/robust-in-only".

2.3.3 Modèle d'échange de messages In-Out

Le modèle d'échange de messages in-out comprend deux messages exactement, en ordre , comme suit :

  1. Un message :

  2. Un message :

Le modèle d'échange de messages in-out utilise la règle 2.2.1 Règle de propagation Fault Replaces Message .

Une opération utilisant ce modèle d'échange de messages a une propriété {message exchange pattern} avec la valeur "http://www.w3.org/ns/wsdl/in-out".

2.4 Observations concernant la sécurité

Notez que plusieurs des modèles d'échange de messages définis ci-dessus décrivent les réponses à un message initial (soit un message de réponse normal, soit un incident).

De telles réponses peuvent être utilisées lors de tentatives pour interrompre, attaquer ou cartographier un réseau, un hôte ou des services. Lorsque ces réponses sont dirigées vers une autre adresse que celle de l'expéditeur du message initial, la source d'une attaque peut être cachée, ou une culpabilité attribuée à un tiers, ou des attaques par saturation (denial-of-service attacks) peuvent être activées ou exacerbées.

Les mécanismes de sécurité veillant à de telles attaques peuvent empêcher la livraison des messages de réponse au nœud récepteur. La conformité au modèle d'échange de messages se mesure avant l'application de ces mécanismes de sécurité.

3. Extensions prédéfinies

3.1 Sûreté des opérations

Cette section définit une extension de WSDL 2.0 [WSDL 2.0 Core Language] qui permet de marquer une opération comme étant une interaction sûre, comme définie à la section 3.4. Interactions sûres dans [Web Architecture].

Cette extension PEUT être utilisée pour établir les valeurs par défaut dans les liaisons, comme dans la liaison HTTP (cf. la section 6.5.5 Correspondance de la représentation XML aux propriétés de composant).

3.1.1 Relation avec le modèle de composants WSDL

L'extension de sûreté ajoute les propriétés suivantes au modèle de composant Interface Operation (défini dans [WSDL 2.0 Core Language]) :

  • {safe}, OBLIGATOIRE. Un type xs:boolean indiquant si l'invocation de l'opération est certifiée sûre pour les utilisateurs. Si cette propriété est "false", aucune déclaration n'a alors été faite à propos de la sûreté de l'opération, ainsi l'opération PEUT ou non être sûre Toutefois, une opération DEVRAIT être marquée comme sûre si elle satisfait aux critères d'interaction sûre définis à la section 3.4 dans [Web Architecture.

3.1.2 Représentation XML

<description>
 <interface>
   <operation name="xs:NCName" pattern="xs:anyURI"
              wsdlx:safe="xs:boolean"? >
  </operation>
 </interface>
</description>

La représentation XML de l'extension de sûreté est un item d'information d'attribut (attribute information item) avec les propriétés d'ensemble d'information (Infoset) suivantes :

  • un item d'information d'attribut safe OPTIONNEL avec les propriétés d'ensemble d'information suivantes  :

    • un nom local [local name] de safe ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl-extensions" ;

    • un type de xs:boolean.

3.1.3 Correspondance de la représentation XML aux propriétés de composant

Cf.  le tableau 3-1.

Tableau 3-1. Correspondance de la représentation XML aux propriétés d'extension du composant Interface Operation
Propriété Valeur
{safe} La valeur réelle (actual value) de l'item d'information d'attribut safe, si présent ; sinon la valeur "false".

4. Styles d'opération prédéfinis

Cette section définit les styles d'operation utilisables pour placer des contraintes sur les composants Interface Operation, notamment en ce qui concerne le format des messages auxquels ils se rapportent. Les formats de sérialisation définis à la section 6.8 Format de sérialisation des données d'instance exigent des composants Interface Operation liés qu'ils aient un ou plusieurs des styles définis dans cette section.

4.1 Style RPC

Le style RPC (Remote Procedure Call) est sélectionné en attribuant la valeur "http://www.w3.org/ns/wsdl/style/rpc" à la propriété {style} d'un composant Interface Operation.

Un composant Interface Operation conforme au style RPC DOIT obéir aux contraintes listées ci-dessous. Également, si l'extension wrpc:signature est engagée simultanément, l'item d'information d'attribut correspondant DOIT être valide selon le schéma de l'extension et, de plus, DOIT obéir aux contraintes listées aux sections 4.1.1 Extension wrpc:signature et 4.1.2 Représentation XML de l'extension wrpc:signature.

En outre, les messages associés DOIVENT se conformer aux règles ci-dessous, décrites en utilisant le langage XML Schema [XML Schema Structures]. Notez que les opérations contenant des messages décrits par d'autres systèmes de typage peuvent aussi indiquer l'utilisation du style RPC, à condition d'être structurées de façon à suivre ces règles.

Si un composant Interface Operation utilise le style RPC, alors sa propriété {message exchange pattern} DOIT avoir pour valeur soit "http://www.w3.org/ns/wsdl/in-only", soit "http://www.w3.org/ns/wsdl/in-out" .

Si la propriété {message exchange pattern} du composant Interface Operation indique l'utilisation d'un modèle pour lequel il n'y a pas d'élément de sortie, c'est-à-dire "http://www.w3.org/ns/wsdl/in-only", alors les conditions énoncées ci-dessous concernant des éléments de sortie DOIVENT être considérées comme étant implicitement satisfaites.

  • La valeur de la propriété {message content model} des composants Interface Message Reference de la propriété {interface message references} DOIT être "#element"  ;

  • Le modèle de contenu des déclarations d'élément {element declaration} des élément d'entrée et de sortie DOIT être défini en utilisant un type complexe qui contient une séquence du schéma XML  ;

  • La séquence d'entrée ne DOIT contenir que des éléments et des éléments génériques (element wildcards) . Elle NE DOIT PAS contenir d'autres structures telles que xs:choice. La séquence d'entrée NE DOIT PAS contenir plus d'un seul élément générique . L'élément générique, si présent, DOIT apparaître après tous les éléments  ;

  • La séquence de sortie ne DOIT contenir que des éléments . Elle NE DOIT PAS contenir d'autres structures telles que xs:choice ;

  • Les séquences d'entrée et de sortie ne DOIVENT contenir que des sous-éléments d'élément local . Notez que ces sous-éléments PEUVENT contenir les attributs suivants : nillable, minOccurs et maxOccurs ;

  • Le nom local du nom qualifié QName de l'élément input DOIT être le même que celui du composant Interface Operation  ;

  • Les éléments input et output DOIVENT se trouver dans le même espace de noms  ;

  • Le type complexe qui définit le corps d'un élément input ou output NE DOIT PAS contenir d'attributs locaux . Les attributs d'extension sont permis pour les besoins de gestion de l'infrastructure du message (par exemple, en ajoutant des identificateurs pour faciliter la signature numérique du contenu du message). On ne doit pas les considérer comme faisant partie des données d'application communiquées par le message. Ils ne sont donc jamais inclus dans une signature RPC (cf. la section 4.1.1 Extension wrpc:signature) ;

  • Si des éléments avec le même nom qualifié apparaissent comme sous-éléments à la fois des éléments input et output, alors ils DOIVENT tous être déclarés en utilisant le même type de nom  ;

  • La séquence input ou output NE DOIT PAS contenir plusieurs sous-éléments déclarés avec le même nom .

4.1.1 Extension wrpc:signature

L'item d'information d'attribut d'extension wrpc:signature PEUT être utilisé conjointement au style RPC pour décrire la signature exacte de la fonction représentée par une opération utilisant le style RPC.

Si présente, l'extension wrpc:signature apporte la propriété suivante au composant Interface Operation auquel elle s'applique :

  • {rpc signature} OPTIONNELLE, mais DOIT être présente lorsque c'est le style RPC . Une liste de couples (qt), dont le premier composant est de type xs:QName et le deuxième de type xs:token. La valeur du deuxième composant DOIT être choisie parmi les quatre suivantes : "#in", "#out", "#inout" et "#return" .

La valeur de la propriété {rpc signature} DOIT satisfaire aux conditions suivantes :

  • La valeur du premier composant de chaque couple (qt) DOIT être unique dans la liste  ;

  • Pour chaque sous-élément des messages d'entrée et de sortie de l'opération, un couple (qt), dont le premier composant q est égal au nom qualifié de cet élément, DOIT être présent dans la liste, à la restriction que les éléments apparaissant avec une cardinalité supérieure à un DOIVENT être traités comme un seul élément  ;

  • Pour chaque couple (q, #in), il DOIT y avoir un sous-élément de l'élément input avec le nom q. Il NE DOIT PAS y avoir de sous-élément de l'élément output avec le nom q  ;

  • Pour chaque couple (q, #out), il DOIT y avoir un sous-élément de l'élément output avec le nom q. Il NE DOIT PAS y avoir de sous-élément de l'élément input avec le nom q  ;

  • Pour chaque couple (q, #inout), il DOIT y avoir un sous-élément de l'élément input avec le nom q. Il NE DOIT PAS y avoir de sous-élément de l'élément output avec le nom q  ;

  • Pour chaque couple (q, #return), il DOIT y avoir un sous-élément de l'élément output avec le nom q. Il NE DOIT PAS y avoir de sous-élément de l'élément input avec le nom q .

La signature de fonction définie par une extension wrpc:signature se détermine comme suit :

  1. Commencer avec la valeur de la propriété {rpc signature}, une liste (éventuellement vide) de couples de la forme suivante :

    [(q0, t0), (q1, t1), ...]

  2. Trier les éléments de cette liste en deux liste : la première (L1) comprenant les couples dont le composant t est l'un parmi {#in, #out, #inout}, la deuxième (L2) comprenant les couples dont le composant t vaut #return. Pour la composition des listes L1 et L2, l'ordre relatif des membres dans la liste originale DOIT être conservé.

    Pour aider la visualisation, notons les deux listes respectives ainsi :

    (L1) [(a0, u0), (a1, u1), ...]

    et :

    (L2) [(r0, #return), (r1, #return), ...]

  3. Ensuite, si la séquence d'entrée se termine par un élément générique, la signature formelle de la fonction est :

    f([d0] a0, [d1] a1, ..., rest) => (r0, r1, ...)

    rest est un paramètre formel représentant les éléments dans le message d'entrée filtrés par l'élément générique.

    Sinon la signature formelle de la fonction est :

    f([d0] a0, [d1] a1, ...) => (r0, r1, ...)

    c'est-à-dire que :

    • la liste des arguments formels de la fonction est [a0, a1, ...] ;

    • la direction d de chaque argument formel a est l'une parmi [in], [out] et [inout], déterminée conformément à la valeur de son atome u correspondant ;

    • la liste des paramètres de retour formels de la fonction est [r0, r1, ...] ;

    • chaque argument formel et paramètre de retour formel est typé conformément au type du sous-élément identifié par la signature (lequel est unique selon les conditions indiquées précédemment).

Remarque :

L'extension wrpc:signature permet la définition de valeurs de retour multiples pour une opération. Plusieurs langages de programmation populaires gèrent des fonctions à valeurs de retour multiples. En outre, pour les langages qui ne le permettent pas, la charge sur les développeurs devrait être minime, puisque les valeurs de retour multiples seront typiquement associées à une seule valeur de retour d'un type de structure — ou son équivalent le plus proche spécifique du langage).

4.1.2 Représentation XML de l'extension wrpc:signature

La représentation XML de l'extension de signature RPC est un item d'information d'attribut avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de signature ;

  • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/rpc".

L'item d'information d'attribut signature est un type de liste dont le type d'élément est l'union d'un type xs:QName et d'un sous-type de xs:token limité aux quatre valeurs suivantes : "#in", "#out", "#inout" et "#return". Cf. l'exemple 4-1 pour un extrait de la définition de schéma normative de ce type.

En plus, chaque élément de numéro pair (0, 2, 4, ...) dans la liste DOIT être de type xs:QName et chaque élément de numéro impair (1, 3, 5, ...) dans la liste DOIT être du sous-type de xs:token décrit au paragraphe précédent .

Exemple 4-1. Définition de l'extension wrpc:signature

<xs:attribute name="signature" type="wrpc:signatureType"/>

<xs:simpleType name="signatureType">
  <xs:list itemType="wrpc:signatureItemType"/>
</xs:simpleType>

<xs:simpleType name="signatureItemType">
  <xs:union memberTypes="xs:QName wrpc:directionToken"/>
</xs:simpleType>

<xs:simpleType name="directionToken">
  <xs:restriction base="xs:token">
    <xs:enumeration value="#in"/>
    <xs:enumeration value="#out"/>
    <xs:enumeration value="#inout"/>
    <xs:enumeration value="#return"/>
  </xs:restriction>
</xs:simpleType>

4.1.3 Correspondance de l'extension wrpc:signature aux propriétés d'un composant Interface Operation

Un item d'information d'attribut d'extension wrpc:signature est associé à la propriété suivante du composant Interface Operation défini par son possesseur [owner].

Tableau 4-1. Correspondance d'une extension wrpc:signature aux propriétés d'un composant Interface Operation
Propriété Valeur
{rpc signature} Une liste de couples (xs:QName, xs:token) formés en regroupant les éléments présents dans la valeur réelle de l'item d'information d'attribut wrpc:signature dans l'ordre où ceux-ci y apparaissent.

4.2 Style IRI

Le style IRI est sélectionné en attribuant la valeur "http://www.w3.org/ns/wsdl/style/iri" à la propriété {style} d'un composant Interface Operation.

Lorsqu'on utilise ce style, la valeur de la propriété {message content model} du composant Interface Message Reference correspondant au message initial du modèle d'échange de messages DOIT être "#element" .

Cette valeur indique que le langage XML Schema [XML Schema Structures] a été utilisé pour définir le schéma de la propriété {element declaration} du composant Interface Message Reference du composant Interface Operation correspondant au message initial du modèle d'échange de messages. Ce schéma DOIT adhérer aux règles suivantes :

  • Le modèle de contenu de cet élément est défini à l'aide d'un type complexe contenant une séquence provenant de XML Schema ;

  • La séquence ne DOIT contenir que des éléments . Elle NE DOIT PAS contenir d'autres structures telles que xs:choice. Il n'y a aucune contrainte d'apparition sur la séquence ;

  • La séquence ne DOIT contenir que des sous-éléments d'élément local . Notez que ces sous-éléments peuvent contenir l'attribut nillable ;

  • La partie locale (localPart) du nom qualifié QName de l'élément DOIT être la même que celle de la propriété {name} du composant Interface Operation  ;

  • Le type complexe qui définit le corps de l'élément ou ses sous-éléments NE DOIT PAS contenir d'attributs  ;

  • Les sous-éléments de la séquence DOIVENT dériver du type xs:simpleType, et NE DOIVENT PAS être ou dériver d'un type xs:QName, xs:NOTATION, xs:hexBinary ou xs:base64Binary .

4.3 Style multipart

Le style multipart est sélectionné en attribuant la valeur "http://www.w3.org/ns/wsdl/style/multipart" à la propriété {style} d'un composant Interface Operation.

Lorsqu'on utilise ce style, la valeur de la propriété {message content model} du composant Interface Message Reference correspondant au message initial du modèle d'échange de messages DOIT être "#element" .

Cette valeur indique que le langage XML Schema [XML Schema Structures] a été utilisé pour définir le schéma de la propriété {element declaration} du composant Interface Message Reference du composant Interface Operation correspondant au message initial du modèle d'échange de messages. Ce schéma DOIT adhérer aux règles suivantes :

  • Le modèle de contenu de cet élément est défini à l'aide d'un type complexe contenant une séquence provenant de XML Schema ;

  • La séquence ne DOIT contenir que des éléments . Elle NE DOIT PAS contenir d'autres structures telles que xs:choice ;

  • La séquence ne DOIT contenir que des sous-éléments d'élément local . Les attributs minOccurs et maxOccurs de ces sous-éléments DOIVENT avoir une valeur de "1. Notez que ces sous-éléments peuvent contenir l'attribut nillable ;

  • La partie locale (localPart) du nom qualifié QName de l'élément DOIT être la même que la propriété {name} du composant Interface Operation  ;

  • Le type complexe qui définit le corps de l'élément ou ses sous-éléments NE DOIT PAS contenir d'attributs  ;

  • La séquence NE DOIT PAS contenir plusieurs sous-éléments déclarés avec le même nom local .

5. Extension de liaison SOAP WSDL

L'extension de liaison SOAP décrite dans cette section est une extension du langage [WSDL 2.0 Core Language] permettant aux applications de services web d'utiliser SOAP. Cette extension de liaison est indépendante de la version SOAP ("1.2" ainsi que les autres versions) et étend WSDL 2.0 en ajoutant des propriétés au composant Binding et ses composants liés, comme définis dans [WSDL 2.0 Core Language]. Une représentation dans l'ensemble d'information XML (XML Infoset) de ces propriétés supplémentaires est en outre fournie, en même temps qu'une correspondance de cette représentation aux diverses propriétés de composant.

Comme permis dans [WSDL 2.0 Core Language], un composant Binding peut exister sans indiquer de composant Interface auquel il s'applique. Auquel cas, aucun composant Binding Operation ou Binding Fault ne peut être présent dans le composant Binding.

L'extension de liaison SOAP est conçue dans le but de minimiser ce qu'il faut déclarer explicitement dans les cas courants. Cela est obtenu en définissant un ensemble de règles par défaut qui affectent tous les composants Interface Operation d'un composant Interface auquel l'extension de liaison SOAP est appliquée, à moins d'être spécifiquement surclassée (overridden) par un composant Binding Operation. Ainsi, si un composant Interface Operation donné n'est pas spécifiquement référencé par un composant Binding Operation, alors toutes les règles par défaut s'appliquent à ce composant Interface Operation. En conséquence, conformément aux exigences de [WSDL 2.0 Core Language], toutes les opérations d'un composant Interface seront liées par cette extension de liaison.

Remarque : Comme ailleurs dans cette spécification, on aurait pu se passer de propriétés « par défaut » au niveau du modèle de composants et fixer la valeur des propriétés correspondantes, celles non par défaut, dans la section de la correspondance XML. Par contre, les propriétés par défaut sont nécessaires pour une liaison sans interface (interface-less binding). En effet, une liaison sans interface n'a aucun moyen d'établir la version non par défaut de la propriété au niveau de l'opération. La correspondance doit donc être réalisée ailleurs.

Un sous-ensemble des propriétés HTTP indiquées dans l'extension de liaison HTTP, définie à la section 6. Extension de liaison HTTP WSDL, est présent dans une liaison SOAP lorsque celle-ci utilise HTTP comme protocole sous-jacent, par exemple, lorsque la valeur de la propriété {soap underlying protocol} du composant Binding est "http://www.w3.org/2003/05/soap/bindings/HTTP/". Ces propriétés NE DOIVENT PAS être utilisées sauf si le protocole sous-jacent est HTTP . Les propriétés autorisées sont celles qui décrivent le protocole sous-jacent (HTTP) :

5.1 Récapitulatif de la syntaxe SOAP (non normatif)

<description>
  <binding name="xs:NCName" interface="xs:QName"?
           type="http://www.w3.org/ns/wsdl/soap"
           whttp:queryParameterSeparatorDefault="xs:string"??
           whttp:contentEncodingDefault="xs:string"??
           whttp:cookies="xs:boolean"?
           wsoap:version="xs:string"?
           wsoap:protocol="xs:anyURI"
           wsoap:mepDefault="xs:anyURI"? >
    <documentation />*

    <wsoap:module ref="xs:anyURI" required="xs:boolean"? >
      <documentation />*
    </wsoap:module>*
    
    <fault ref="xs:QName"
           wsoap:code="union de xs:QName, xs:token"?
           wsoap:subcodes="union de (liste de xs:QName), xs:token"?
           whttp:contentEncoding="xs:string"?? >

      <documentation />*

      <wsoap:module ... />*
      <wsoap:header element="xs:QName" mustUnderstand="xs:boolean"?
                    required="xs:boolean"? >
        <documentation />*
      </wsoap:header>*
      <whttp:header ... />*??

    </fault>*

    <operation ref="xs:QName" 
               whttp:location="xs:anyURI"??
               whttp:contentEncodingDefault="xs:string"??
               whttp:queryParameterSeparator="xs:string"??
               whttp:ignoreUncited="xs:boolean"??
               wsoap:mep="xs:anyURI"?
               wsoap:action="xs:anyURI"? >

      <documentation />*

      <wsoap:module ... />*

      <input messageLabel="xs:NCName"?
             whttp:contentEncoding="xs:string"?? >
        <documentation />*
        <wsoap:module ... />*
        <wsoap:header ... />*
        <whttp:header ... />*??
      </input>*

      <output messageLabel="xs:NCName"?
             whttp:contentEncoding="xs:string"?? >
        <documentation />*
        <wsoap:module ... />*
        <wsoap:header ... />*
        <whttp:header ... />*??
      </output>*

      <infault ref="xs:QName"
                  messageLabel="xs:NCName"?>
        <documentation />*
        <wsoap:module ... />*
      </infault>*

      <outfault ref="xs:QName"
                   messageLabel="xs:NCName"?>
        <documentation />*
        <wsoap:module ... />*
      </outfault>*

    </operation>*

  </binding>

  <service>
    <endpoint name="xs:NCName" binding="xs:QName" address="xs:anyURI"?
              whttp:authenticationScheme="xs:token"?? 
              whttp:authenticationRealm="xs:string"?? >
      <documentation />*
    </endpoint>
  </service>
</description>

Remarque :

Les points d'interrogation doubles ("??") après les attributs dans l'espace de noms whttp indiquent que ces attributs n'ont de sens que lorsque la liaison SOAP utilise HTTP comme protocole sous-jacent, par exemple, lorsque la valeur de l'attribut wsoap:protocol est "http://www.w3.org/2003/05/soap/bindings/HTTP/".

5.2 Identification de l'utilisation de la liaison SOAP

Un composant Binding, défini dans [WSDL 2.0 Core Language], est identifié comme liaison SOAP en affectant la valeur "http://www.w3.org/ns/wsdl/soap" à la propriété {type} du composant Binding.

5.3 Règles de la liaison SOAP

  • Construction de la charge utile. Lors de la formulation de l'enveloppe SOAP à transmettre, le contenu de la charge utile (c'est-à-dire le contenu de l'item d'information d'élément SOAP Body de l'enveloppe SOAP) DOIT être ce qui est défini par le composant Interface Message Reference correspondant . Celle-ci subit ensuite une optimisation par une fonction en vigueur qui affecte la sérialisation, telle que le mécanisme d'optimisation MTOM [SOAP Message Transmission Optimization Mechanism]. Les règles de liaison suivantes DOIVENT être respectées :

    Remarque :

    Cette extension de liaison SOAP n'admet qu'un seul élément dans le composant SOAP Body.

  • Construction de l'en-tête SOAP. Si la propriété {soap headers} telle que définie à la section 5.9 Déclaration des blocs d'en-tête SOAP existe dans un composant Binding Message Reference ou Binding Fault, et n'est pas vide, alors un item d'information d'élément conforme à la déclaration d'élément de la propriété {element declaration} d'un composant SOAP Header Block, dans la propriété {soap headers}, PEUT être transformé en un bloc d'en-tête SOAP pour le message correspondant.

    Si la valeur de la propriété {required} d'un composant SOAP Header Block est "true", l'inclusion de ce bloc d'en-tête SOAP est OBLIGATOIRE ; sinon elle est OPTIONNELLE.

    Et, si la propriété {mustUnderstand} du composant SOAP Header Block est présente et que sa valeur est "true", ce bloc d'en-tête SOAP particulier DOIT être marqué d'un item d'information d'attribut mustUnderstand avec une valeur de "true" ou "1", selon la spécification SOAP.

    Les autres blocs d'en-tête SOAP que ceux déclarés dans la propriété {soap headers} peuvent être présents à l'exécution (run-time), ainsi les blocs d'en-tête SOAP résultant de modules SOAP déclarés comme expliqué à la section 5.8 Déclaration des modules SOAP.

5.4 Indication de la version SOAP

5.4.1 Description

Chaque liaison SOAP DOIT indiquer quelle version de SOAP est utilisée pour les opérations de l'interface à laquelle cette liaison s'applique .

Par défaut, c'est SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework (Second Edition)] qui est utilisé.

5.4.2 Relation avec le modèle de composants WSDL

La spécification du protocole SOAP ajoute la propriété suivante au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

5.4.3 Représentation XML

<description>
  <binding  name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
            wsoap:version="xs:string"? >
    ...
  </binding>
</description>

La représentation XML pour indiquer la version SOAP est un item d'information d'attribut avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de version ;

  • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/soap" ;

  • un type de xs:string.

5.4.4 Correspondance de la représentation XML aux propriétés de composant

Cf. le tableau 5-1.

Tableau 5-1. Correspondance de la représentation XML aux propriétés d'extension du composant Binding
Propriété Valeur
{soap version} La valeur réelle de l'item d'information d'attribut wsoap:version, si présent ; sinon "1.2".

5.5 Indication du protocole sous-jacent de SOAP

5.5.1 Description

Chaque liaison SOAP DOIT indiquer quel protocole sous-jacent est utilisé .

5.5.2 Relation avec le modèle de composants WSDL

La spécification du protocole SOAP ajoute la propriété suivante au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

5.5.3 Représentation XML

<description>
  <binding  name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
            wsoap:protocol="xs:anyURI" >
    ...
  </binding>
</description>

La représentation XML pour indiquer le protocole SOAP est un item d'information d'attribut OBLIGATOIRE avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de protocol ;

  • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/soap" ;

  • un type de xs:anyURI.

5.5.4 Correspondance de la représentation XML aux propriétés de composant

Cf. le tableau 5-2.

Tableau 5-2. Correspondance de la représentation XML aux propriétés d'extension du composant Binding
Propriété Valeur
{soap underlying protocol} La valeur réelle de l'item d'information d'attribut wsoap:protocol.

5.6 Incidents de liaison

5.6.1 Description

Pour chaque composant Interface Fault contenu dans un composant Interface, une correspondance à un composant SOAP Fault DOIT être décrite . Cette définition d'extension de liaison permet à l'utilisateur d'indiquer les code et sous-codes d'incident SOAP (SOAP Fault) transmis pour un composant Interface Fault donné.

5.6.2 Relation avec le modèle de composants WSDL

L'extension de liaison d'incident SOAP ajoute les propriétés suivantes au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

  • {soap fault code}, OBLIGATOIRE. L'union d'un type xs:QName et d'un type xs:token ; propriété ajoutée au composant Binding Fault, où :

    La valeur de cette propriété identifie un composant SOAP Fault possible pour les opérations visées. Si la valeur de cette propriété est "#any", on ne fait aucune assertion à propos de la valeur possible du code d'incident SOAP.

  • {soap fault subcodes}, OBLIGATOIRE. L'union d'une liste de types xs:QName et d'un type xs:token, où la valeur d'atome permise est "#any" ; propriété ajoutée au composant Binding Fault. La valeur de cette propriété identifie un ou plusieurs sous-codes pour ce composant SOAP Fault. La liste des sous-codes est la séquence nichée (nested sequence) de sous-codes. Une liste vide représente un code d'incident sans sous-code.

5.6.3 Représentation XML

<description>
  <binding >
    <fault ref="xs:QName"
           wsoap:code="union de xs:QName, xs:token"?
           wsoap:subcodes="union de (liste de xs:QName), xs:token"? >
      <documentation />*
    </fault>*
  </binding>
</description>

La représentation XML de liaison d'un incident SOAP comporte deux items d'information d'attribut avec les propriétés d'ensemble d'information suivantes :

  • un item d'information d'attribut wsoap:code OPTIONNEL ;

    • un nom local [local name] de code ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/soap" ;

    • un type d'union de xs:QName et xs:token, où la valeur d'atome permise est "#any".

  • un item d'information d'attribut wsoap:subcodes OPTIONNEL ;

    • un nom local [local name] de subcodes ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/soap" ;

    • un type d'union d'une liste de xs:QName et de xs:token, où la valeur d'atome permise est "#any".

5.6.4 Correspondance de la représentation XML aux propriétés de composant

Cf. le tableau 5-3.

Tableau 5-3. Correspondance de la représentation XML aux propriétés du composant SOAP Fault
Propriété Valeur
{soap fault code} La valeur réelle de l'item d'information d'attribut code, si présent ; sinon "#any".
{soap fault subcodes} La valeur réelle de l'item d'information d'attribut subcodes, si présent ; sinon "#any".

5.7 Opérations de liaison

5.7.1 Description

Pour chaque composant Interface Operation contenu dans un composant Interface, en plus des règles de liaison (pour SOAP 1.2, cf. la section 5.10.3 Règles de liaison SOAP 1.2), des informations de liaison supplémentaires peuvent être définies. Cette spécification d'extension de liaison permet à l'utilisateur d'indiquer le modèle d'échange de messages SOAP (SOAP Message Exchange Pattern) et une valeur de la caractéristique d'action SOAP (SOAP Action Feature) pour chaque opération.

5.7.2 Relation avec le modèle de composants WSDL

La spécification d'extension de liaison d'opération SOAP ajoute la propriété suivante au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

  • {soap mep default}, OPTIONNEL. Un type xs:anyURI, qui est une adresse IRI absolue comme définie par [IETF RFC 3987] ; propriété ajoutée au composant Binding . La valeur de cette propriété identifie le modèle d'échange de messages SOAP par défaut de tous les composants Interface Operation d'un composant Interface auquel ce composant Binding est appliqué ;

  • {soap mep}, OPTIONNEL. Un type xs:anyURI, qui est une adresse IRI absolue comme définie par [IETF RFC 3987] ; propriété ajoutée au composant Binding Operation . La valeur de cette propriété identifie le modèle d'échange de messages SOAP de cette opération spécifique (cf. la section 5.10.3 Règles de liaison SOAP 1.2, paragraphe intitulé « Sélection du modèle d'échange de messages SOAP », pour les contraintes des liaisons) ;

  • {soap action}, OPTIONNEL. Un type xs:anyURI, qui est une adresse IRI absolue comme définie par [IETF RFC 3987] ; propriété ajoutée au composant Binding Operation . La valeur de cette propriété identifie la valeur de la caractéristique d'action SOAP du message initial du modèle d'échange de messages du composant Interface Operation lié, telle qu'indiquée dans les règles de liaison des liaisons à des versions spécifiques de SOAP (cf. la section 5.10.3 Règles de liaison SOAP 1.2 de la liaison SOAP 1.2 lorsque la valeur de la propriété {soap version} du composant Binding est "1.2").

5.7.3 Représentation XML

<description>
  <binding wsoap:mepDefault="xs:anyURI"? >
    <operation ref="xs:QName" 
               wsoap:mep="xs:anyURI"?
               wsoap:action="xs:anyURI"? >
    </operation>
  </binding>
</description>

La représentation XML pour lier un composant Binding Operation comporte deux items d'information d'attribut avec les propriété d'ensemble d'information suivantes :

  • un item d'information d'attribut wsoap:mep OPTIONNEL ;

    • un nom local [local name] de mep ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/soap" ;

    • un type de xs:anyURI.

  • un item d'information d'attribut wsoap:action OPTIONNEL ;

    • un nom local [local name] de action ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/soap" ;

    • un type de xs:anyURI.

L'item d'information d'attribut suivant est défini pour l'item d'information d'élément binding :

  • un item d'information d'attribut wsoap:mepDefault OPTIONNEL ;

    • un nom local [local name] de mepDefault ;

    • un nom d'espace de noms [namespace name] de " http://www.w3.org/ns/wsdl/soap" ;

    • un type de xs:anyURI.

5.7.4 Correspondance de la représentation XML aux propriétés de composant

Cf. le tableau 5-4.

Tableau 5-4. Correspondance de la représentation XML aux propriétés du composant SOAP Operation
Propriété Valeur
{soap mep default} La valeur réelle de l'item d'information d'attribut wsoap:mepDefault, si présent.
{soap mep} La valeur réelle de l'item d'information d'attribut wsoap:mep, si présent.
{soap action} La valeur réelle de l'item d'information d'attribut wsoap:action, si présent.

5.8 Déclaration des modèles SOAP

5.8.1 Description

Le cadre de messagerie SOAP (SOAP messaging framework) permet à un service web d'engager une plusieurs caractéristiques (typiquement mises en œuvre en un ou plusieurs blocs d'en-tête SOAP), comme définis par des modules SOAP (cf. [SOAP 1.2 Part 1: Messaging Framework (Second Edition)]). Cette spécification d'extension de liaison permet une description des modules SOAP en vigueur à travers une liaison entière, pour chaque opération ou pour chaque message.

5.8.2 Relation avec le modèle de composants WSDL

Le composant SOAP Module ajoute la propriété suivante au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

Les modules SOAP applicables pour une opération particulière d'un service quelconque sont constitués de tous les modules définis dans les éléments input et output des composants Binding Message Reference, dans les éléments infault ou outfault des composants Binding Fault Reference, ceux définis au sein des composants Binding Fault, ceux définis au sein des composants Binding Operation et ceux définis au sein du composant Binding. Si un module est déclaré dans plusieurs composants, alors l'exigibilité (requiredness) de ce module est définie par la déclaration la plus proche, où la proximité est définie selon que l'exigibilité est décrite directement au niveau du composant Binding Message Reference ou du composant Binding Fault Reference, au niveau du composant Binding Fault ou du composant Binding Operation, ou au niveau du composant Binding, respectivement.

5.8.3 Composant SOAP Module

Le composant SOAP Module identifie un module SOAP en vigueur.

Les propriétés du composant SOAP Module sont les suivantes :

5.8.4 Représentation XML

<description>
  <binding >
    <wsoap:module ref="xs:anyURI"
                  required="xs:boolean"? >
      <documentation ... />*
    </wsoap:module>
    <fault>
      <wsoap:module ... />*
    </fault>
    <operation>
      <wsoap:module ... />*
      <input>
        <wsoap:module ... />*
      </input>
      <output>
        <wsoap:module ... />*
      </output>
      <infault>
        <wsoap:module ... />*
      </infault>
      <outfault>
        <wsoap:module ... />*
      </outfault>
    </operation>
  </binding>
</description>

La représentation XML d'un composant SOAP Module est un item d'information d'élément avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de module ;

  • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/soap" ;

  • un ou plusieurs items d'information d'attribut parmi ses attributs [attributes] comme suit :

    • un item d'information d'attribut ref OBLIGATOIRE avec les propriétés d'ensemble d'information suivantes :

      • un nom local [local name] de ref ;

      • un nom d'espace de noms [namespace name] sans valeur ;

      • un type de xs:anyURI.

    • un item d'information d'attribut required OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

      • un nom local [local name] de required ;

      • un nom d'espace de noms [namespace name] sans valeur ;

      • un type de xs:boolean.

    • zéro ou plus items d'information d'attribut, qualifiés d'un espace de noms. Le nom d'espace de noms [namespace name] de ces items d'information d'attribut NE DOIT PAS être "http://www.w3.org/ns/wsdl" NI "http://www.w3.org/ns/wsdl/soap".

  • zéro ou plus items d'information d'élément parmi ses sous-éléments [children], en ordre, comme suit :

    1. zéro ou plus items d'information d'élément documentation comme définis dans [WSDL 2.0 Core Language] ;

    2. zéro ou plus items d'information d'élément, qualifiés d'un espace de noms, parmi ses sous-éléments [children]. Le nom d'espace de noms [namespace name] de ces items d'information d'élément NE DOIT PAS être "http://www.w3.org/ns/wsdl" NI "http://www.w3.org/ns/wsdl/soap".

5.8.5 Correspondance de la représentation XML aux propriétés de composant

Cf. le tableau 5-5.

Tableau 5-5. Correspondance de la représentation XML aux propriétés liées au composant SOAP Module
Propriété Valeur
{soap modules} L'ensemble des composants SOAP Module correspondant à tous les items d'information d'élément module dans les sous-éléments [children] des items d'information d'élément binding, operation, fault, input, output, infault et outfault, le cas échéant.
{ref} La valeur réelle de l'item d'information d'attribut ref.
{required} La valeur réelle de l'item d'information d'attribut required, si présent ; sinon "false".
{parent} Le composant Binding, Binding Operation, Binding Message Reference, Binding Fault ou Binding Fault Reference correspondant à l'item d'information d'élément binding, operation, fault, input, output, infault ou outfault dans le parent [parent].

5.8.6 Identification IRI d'un composant SOAP Module

La spécification WSDL version 2.0 tome 1 — Cœur du langage [WSDL 2.0 Core Language] définit une syntaxe d'identificateur de fragment pour identifier les composants d'un document WSDL 2.0.

Un composant SOAP Module peut être identifié en utilisant le schéma wsdl.extension du cadre XPointer (XPointer Framework) :

wsdl.extension(http://www.w3.org/ns/wsdl/soap, wsoap.module(parent/ref))

  1. parent est la partie pointeur du composant {parent}, comme indiqué à l'annexe A.2 Identificateurs de fragments dans [WSDL 2.0 Core Language] ;

  2. ref est la valeur de la propriété {ref} du composant.

5.9 Déclaration des blocs d'entête SOAP

5.9.1 Description

SOAP permet d'utiliser des blocs d'en-tête (header blocks) dans la partie en-tête du message. Cette extension de liaison permet aux utilisateurs de déclarer les blocs d'en-tête SOAP en vigueur pour chaque message et pour chaque incident.

5.9.2 Relation avec le modèle de composants WSDL

La spécification d'extension de liaison de blocs d'en-tête SOAP ajoute la propriété suivante au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

5.9.3 Composant SOAP Header Block

Un composant SOAP Header Block décrit un morceau abstrait de données d'en-tête (bloc d'en-tête SOAP) qui est associé à l'échange de messages entre les parties communicantes. La présence d'un composant SOAP Header Block dans une description WSDL indique que le service gère les en-têtes et PEUT imposer à un client interagissant avec le service d'utiliser le bloc d'en-tête décrit. Zéro ou un bloc d'en-tête peut être utilisé.

Les propriétés du composant SOAP Header Block sont les suivantes :

  • {element declaration}, OBLIGATOIRE. Une déclaration d'élément XML dans la propriété {element declarations} du composant Description. Cette déclaration d'élément XML représente exclusivement un bloc d'en-tête SOAP spécifique ;

  • {mustUnderstand}, OBLIGATOIRE. Un type xs:boolean. Lorsque sa valeur est "true", le bloc d'en-tête SOAP DOIT être accompagné d'un item d'information d'attribut mustUnderstand SOAP avec une valeur de "true" ; dans ce cas, la déclaration d'élément XML référencée par la propriété {element declaration} DOIT admettre cet item d'information d'attribut mustUnderstand SOAP . Sinon, aucune autre contrainte n'est exercée quant à la présence et à la valeur d'un item d'information d'attribut mustUnderstand SOAP ;

  • {required}, OBLIGATOIRE. Un type xs:boolean indiquant si le bloc d'en-tête SOAP est nécessaire. Si la valeur est "true", alors le bloc d'en-tête SOAP DOIT être inclus dans le message . Si la valeur est "false", le bloc d'en-tête SOAP PEUT être inclus ;

  • {parent}, OBLIGATOIRE. Le composant Binding Fault ou Binding Message Reference qui contient ce composant dans sa propriété {soap headers}.

5.9.4 Représentation XML

<description>
  <binding name="xs:NCName" type="http://www.w3.org/ns/wsdl/soap" >
    <fault ref="xs:QName" >
      <wsoap:header element="xs:QName" mustUnderstand="xs:boolean"?
                 required="xs:boolean"? >
        <documentation />*
      </wsoap:header>*
      ...
    </fault>*
    <operation ref="xs:QName" >
      <input messageLabel="xs:NCName"?>
        <wsoap:header ... />*
        ...
      </input>*
      <output messageLabel="xs:NCName"?>
        <wsoap:header ... />*
        ...
      </output>*
    </operation>*
  </binding>
</description>

La représentation XML d'un composant SOAP Header Block est un item d'information d'élément avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de header ;

  • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/soap" ;

  • un ou plusieurs items d'information d'attribut parmi ses attributs [attributes] comme suit :

    • un item d'information d'attribut element OBLIGATOIRE avec les propriétés d'ensemble d'information suivantes :

      • un nom local [local name] de element ;

      • un nom d'espace de noms [namespace name] sans valeur ;

      • un type de xs:QName.

    • un item d'information d'attribut mustUnderstand OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

      • un nom local [local name] de mustUnderstand ;

      • un nom d'espace de noms [namespace name] sans valeur ;

      • un type de xs:boolean.

    • un item d'information d'attribut required OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

      • un nom local [local name] de required ;

      • un nom d'espace de noms [namespace name] sans valeur ;

      • un type de xs:boolean.

    • zéro ou plusieurs items d'information d'attribut qualifiés d'un espace de noms. Le nom d'espace de noms [namespace name] de ces items d'information d'attribut NE DOIT PAS être "http://www.w3.org/ns/wsdl" NI "http://www.w3.org/ns/wsdl/soap".

  • zéro ou plusieurs items d'information d'élément parmi ses sous-éléments [children], en ordre, comme suit :

    1. zéro ou plus items d'information d'élément documentation comme définis dans [WSDL 2.0 Core Language] ;

    2. zéro ou plus items d'information d'élément qualifiés d'un espace de noms parmi ses sous-éléments [children]. Le nom d'espace de noms [namespace name] de ces items d'information d'élément NE DOIT PAS être "http://www.w3.org/ns/wsdl" NI "http://www.w3.org/ns/wsdl/soap".

5.9.5 Correspondance de la représentation XML aux propriétés de composant

Cf. le tableau 5-6.

Tableau 5-6. Correspondance de la représentation XML aux propriétés liées au composant SOAP Header Block
Propriété Valeur
{soap headers} L'ensemble des composants SOAP Header Block correspondant à tous les items d'information d'élément header dans les sous-éléments [children] des items d'information d'élément fault, input ou output, le cas échéant.
{element declaration} La déclaration d'élément de la propriété {element declarations} résolue par la valeur de l'item d'information d'attribut element. La valeur de l'item d'information d'attribut element DOIT se résoudre en une déclaration d'élément globale de la propriété {element declarations} du composant Description .
{mustUnderstand} La valeur réelle de l'item d'information d'attribut mustUnderstand, si présent ; sinon "false".
{required} La valeur réelle de l'item d'information d'attribut required si présent ; sinon "false".
{parent} Le composant Binding Fault ou Binding Message Reference correspondant à l'item d'information d'élément fault, input ou output dans le parent [parent].

5.9.6 Identification IRI d'un composant SOAP Header Block

La spécification WSDL version 2.0 tome 1 — Cœur du langage [WSDL 2.0 Core Language] définit une syntaxe d'identificateur de fragment pour identifier les composants d'un document WSDL 2.0.

Un composant SOAP Header Block peut être identifié en utilisant le schéma wsdl.extension du cadre XPointer :

wsdl.extension(http://www.w3.org/ns/wsdl/soap, wsoap.header(parent/element declaration))

  1. parent est la partie pointeur "wsdl.*" du composant {parent}, comme défini à l'annexe A.2 Identificateurs de fragment dans [WSDL 2.0 Core Language], c'est-à-dire sans les parties pointeurs xmlns() ;

  2. element declaration est la valeur de la propriété {name} du composant Element Declaration désigné par la propriété {element declaration} du composant SOAP Header Block.

5.10 Liaison SOAP 1.2 WSDL

Cette section décrit la liaison SOAP 1.2 pour WSDL 2.0. Cette liaison ne prend pas en charge la totalité des capacités de SOAP 1.2. Certaines capacités peu utilisées ou vues comme étant problématiques en pratique ne sont pas disponibles, dans beaucoup de cas parce que leur prise en charge était considérée comme ajoutant une complexité considérable au langage. Voici quelques capacités non prises en charge :

  • les sous-éléments multiples du composant SOAP Body ;

  • les entrées SOAP Fault Detail multiples ;

  • les éléments non qualifiés comme sous-éléments d'un composant SOAP Fault Detail.

5.10.1 Identification d'une liaison SOAP 1.2 WSDL

Une liaison SOAP WSDL est identifiée comme une liaison SOAP 1.2 en affectant la valeur "1.2" à la propriété {soap version} du composant Binding.

5.10.2 Description

L'extension de liaison SOAP 1.2 WSDL définie dans cette section est une extension de la liaison SOAP définie à la section 5. Extension de liaison SOAP WSDL afin que les applications de services web puissent utiliser SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework (Second Edition)].

L'extension de liaison SOAP 1.2 WSDL gère la liaison HTTP SOAP 1.2 définie dans la spécification [SOAP 1.2 Part 2: Adjuncts (Second Edition)]. On l'indique en affectant l'adresse URI "http://www.w3.org/2003/05/soap/bindings/HTTP/" (comme défini par [SOAP 1.2 Part 2: Adjuncts (Second Edition)]) à la propriété {soap underlying protocol}. D'autres valeurs de protocole PEUVENT être utilisées pour cette propriété en conjonction avec l'extension de liaison SOAP 1.2 définie par cette spécification, à condition que la sémantique de ces protocoles soit cohérente avec cette extension de liaison.

Les règles par défaut de la section 5.10.3 Règles de liaison SOAP 1.2 définissent la relation entre les modèles d'échange de messages SOAP définis dans [SOAP 1.2 Part 2: Adjuncts (Second Edition)] et les modèles d'échange de messages WSDL définis à la section 2. Modèles d'échange de messages prédéfinis.

5.10.3 Règles de liaison SOAP 1.2

Ces règles de liaison sont applicables aux liaisons SOAP 1.2.

  • Caractéristique d'action SOAP. La valeur de la caractéristique d'action SOAP (SOAP Action Feature) du message initial du modèle d'échange de messages du composant Interface Operation lié est indiquée par la propriété {soap action} de ce composant Binding Operation. Si le composant Binding Operation n'a pas de propriété {soap action} définie, alors la caractéristique d'action SOAP (cf. [SOAP 1.2 Part 2: Adjuncts (Second Edition)]) n'a pas de valeur. Sinon, sa valeur est celle de la caractéristique d'action SOAP du message initial du modèle d'échange de messages. La propriété {soap action} n'a aucun effet sur une liaison au modèle d'échange de messages SOAP Response SOAP.

  • Sélection du modèle d'échange de messages SOAP. Pour un composant Interface Operation donné, s'il existe un composant Binding Operation dont la propriété {interface operation} correspond au composant en question et que sa propriété {soap mep} a une valeur, alors le modèle d'échange de messages SOAP est la valeur de la propriété {soap mep}. Sinon le modèle d'échange de messages SOAP est la valeur de la propriété {soap mep default} du composant Binding, le cas échéant. Sinon, la propriété {message exchange pattern} du composant Interface Operation DOIT avoir la valeur "http://www.w3.org/ns/wsdl/in-out", et le modèle d'échange de messages SOAP est l'adresse URI "http://www.w3.org/2003/05/soap/mep/request-response/" identifiant le modèle d'échange de messages Request-Response SOAP comme défini dans [SOAP 1.2 Part 2: Adjuncts (Second Edition).

  • Élément Detail SOAP. Le cas échéant, la valeur de l'élément Detail SOAP DOIT être l'item d'information d'élément identifié par la propriété {element declaration} du composant Interface Fault .

  • Sélection de méthode HTTP. Cette règle de liaison par défaut est applicable lorsque la valeur de la propriété {soap underlying protocol} du composant Binding est "http://www.w3.org/2003/05/soap/bindings/HTTP/". Si le modèle d'échange de messages SOAP sélectionné, comme indiqué ci-dessus, a la valeur "http://www.w3.org/2003/05/soap/mep/request-response/", alors la méthode HTTP utilisée est "POST". Si le modèle d'échange de messages SOAP sélectionné a la valeur "http://www.w3.org/2003/05/soap/mep/soap-response/", alors la méthode HTTP utilisée est "GET" .

5.10.4 Liaison des modèles d'échange de messages WSDL 2.0 aux modèles d'échange de messages SOAP 1.2

Cette section décrit la relation entre les composants WSDL et les propriétés de modèle d'échange de messages SOAP 1.2, décrites dans [SOAP 1.2 Part 2: Adjuncts (Second Edition)].

5.10.4.1 Liaison du modèle In-Out WSDL au modèle Request-Response SOAP

Cette section décrit la correspondance du modèle d'échange de message "http://www.w3.org/ns/wsdl/in-out" WSDL au modèle d'échange de messages "http://www.w3.org/2003/05/soap/mep/request-response/" SOAP (ce qui serait le cas habituel d'une opération d'entrée-sortie SOAP sur HTTP). Des extensions (telles que [WSA 1.0 Core]) PEUVENT altérer ces correspondances.

5.10.4.1.1 Le client

Comme client, la propriété "http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role" prend la valeur "RequestingSOAPNode".

La propriété "http://www.w3.org/2003/05/soap/mep/ImmediateDestination" SOAP prend la valeur de l'adresse IRI de requête HTTP, comme définie à la section 6.4.6 Adresse IRI de la requête HTTP et modifiée dans la section 6.8.1 Sérialisation des données d'instance dans les parties de l'adresse IRI de requête HTTP.

Le message "In" WSDL est associé à la propriété "http://www.w3.org/2003/05/soap/mep/OutboundMessage" SOAP.

Le message "Out" WSDL correspond à la propriété "http://www.w3.org/2003/05/soap/mep/InboundMessage" SOAP.

5.10.4.1.2 Le service

Comme service, la propriété "http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role" SOAP prend la valeur "RespondingSOAPNode".

Le message "In" WSDL est associé à la propriété "http://www.w3.org/2003/05/soap/mep/InboundMessage" SOAP.

Le message "Out" WSDL correspond à la propriété "http://www.w3.org/2003/05/soap/mep/OutboundMessage" SOAP.

5.10.4.2 Liaison du modèle In-Out WSDL au modèle SOAP Response SOAP

Cette section décrit la correspondance du modèle d'échange de messages "http://www.w3.org/ns/wsdl/in-out" WSDL au modèle d'échange de messages "http://www.w3.org/2003/05/soap/mep/soap-response/" SOAP. Des extensions (telles que [WSA 1.0 Core]) PEUVENT altérer ces correspondances.

5.10.4.2.1 Le client

Comme client, la propriété "http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role" prend la valeur "RequestingSOAPNode".

La propriété "http://www.w3.org/2003/05/soap/mep/ImmediateDestination" SOAP prend la valeur de l'adresse IRI de requête HTTP, comme définie à la section 6.4.6 Adresse IRI de la requête HTTP et modifiée à la section 6.8.1 Sérialisation des données d'instance dans les parties de l'adresse IRI de requête HTTP.

La valeur de la propriété {message content model} des composants Interface Message Reference de la propriété {interface message references} DOIT être soit "#element", soit "#none". Lorsque la valeur est :

La propriété "http://www.w3.org/2003/05/soap/mep/OutboundMessage" SOAP n'a pas de valeur.

Le message "Out" WSDL correspond à la propriété "http://www.w3.org/2003/05/soap/mep/InboundMessage" SOAP.

5.10.4.2.2 Le service

Comme service, la propriété "http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role" prend la valeur "RespondingSOAPNode".

Le message "In" WSDL est construit à partir de l'adresse URI de destination, selon les règles de la section 6.8.2 Sérialisation comme type "application/x-www-form-urlencoded", si la valeur de la propriété {message content model} des composants Interface Message Reference de la propriété {interface message references} est "#element".

Le message "Out" WSDL correspond à la propriété "http://www.w3.org/2003/05/soap/mep/OutboundMessage" SOAP.

5.10.4.3 Liaison du modèle In-Only au modèle Request-Response SOAP

Cette section décrit la correspondance du modèle d'échange de messages "http://www.w3.org/ns/wsdl/in-only" WSDL au modèle d'échange de messages "http://www.w3.org/2003/05/soap/mep/request-response/" SOAP. Des extensions (telles que [WSA 1.0 Core]) PEUVENT altérer ces correspondances.

5.10.4.3.1 Le client

Comme client, la propriété "http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role" prend la valeur "RequestingSOAPNode".

La propriété "http://www.w3.org/2003/05/soap/mep/ImmediateDestination" SOAP prend la valeur de l'adresse IRI de requête HTTP, comme définie à la section 6.4.6 Adresse IRI de la requête HTTP et modifiée à la section 6.8.1 Sérialisation des données d'instance dans les parties de l'adresse IRI de requête HTTP.

Le message "In" WSDL est associé à la propriété "http://www.w3.org/2003/05/soap/mep/OutboundMessage" SOAP.

La propriété "http://www.w3.org/2003/05/soap/mep/InboundMessage" SOAP n'a pas de valeur.

5.10.4.3.2 Le service

Comme service, la propriété "http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role" prend la valeur "RespondingSOAPNode".

Le message "In" WSDL est associé à la propriété "http://www.w3.org/2003/05/soap/mep/InboundMessage" SOAP.

La propriété "http://www.w3.org/2003/05/soap/mep/OutboundMessage" SOAP n'a pas de valeur.

5.10.4.4 Liaison du modèle Robust-In-Only WSDL au modèle Request-Response SOAP

Cette section décrit la correspondance du modèle d'échange de messages "http://www.w3.org/ns/wsdl/robust-in-only" WSDL au modèle d'échange de messages "http://www.w3.org/2003/05/soap/mep/request-response/" SOAP. Des extensions (telles que [WSA 1.0 Core]) PEUVENT altérer ces correspondances.

5.10.4.4.1 Le client

Comme client, la propriété "http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role" prend la valeur "RequestingSOAPNode".

La propriété "http://www.w3.org/2003/05/soap/mep/ImmediateDestination" SOAP prend la valeur de l'adresse IRI de requête HTTP, comme définie à la section 6.4.6 Adresse IRI de la requête HTTP et modifiée à la section 6.8.1 Sérialisation des données d'instance dans les parties de l'adresse IRI de requête HTTP.

Le message "In" WSDL est associé à la propriété "http://www.w3.org/2003/05/soap/mep/OutboundMessage" SOAP.

La propriété "http://www.w3.org/2003/05/soap/mep/InboundMessage" SOAP peut contenir un incident SOAP.

5.10.4.4.2 Le service

Comme service, la propriété "http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role" prend la valeur "RespondingSOAPNode".

Le message "In" WSDL est associé à la propriété "http://www.w3.org/2003/05/soap/mep/InboundMessage" SOAP.

La propriété "http://www.w3.org/2003/05/soap/mep/OutboundMessage" SOAP peut contenir un incident SOAP.

5.11 Conformité

Un item d'information d'élément dont le nom d'espace de noms est "http://www.w3.org/ns/wsdl" et dont la partie locale est description est conforme à cette spécification d'extension de liaison si les items d'information d'élément et items d'information d'attribut dont l'espace de noms est "http://www.w3.org/ns/wsdl/soap" sont conformes au schéma XML de ces éléments ou attributs, comme défini par cette spécification, et adhèrent en outre à toutes les contraintes contenues dans cette spécification.

6. Extension de liaison HTTP WSDL

L'extension de liaison HTTP décrite dans cette section est une extension de [WSDL 2.0 Core Language] qui permet aux applications de services web d'utiliser HTTP 1.1 [IETF RFC 2616] (et d'autres versions de HTTP) et HTTPS [IETF RFC 2818]. Cette extension de liaison étend WSDL 2.0 en ajoutant des propriétés au modèle de composants défini dans [WSDL 2.0 Core Language]. De plus, une représentation d'ensemble d'information XML de ces propriétés supplémentaires est fournie, en même temps qu'une correspondance de de cette représentation aux diverses propriétés de composant.

Comme permis dans [WSDL 2.0 Core Language], un composant Binding peut exister sans indiquer de composant Interface spécifique auquel il s'applique et, dans ce cas, aucun composant Binding Operation ou Binding Fault ne peut être présent dans le composant Binding.

L'extension de liaison HTTP est conçue dans le but de réduire ce qu'il faut déclarer explicitement dans les cas courants. Cela est obtenu en définissant un ensemble de règles par défaut qui affectent tous les composants Interface Operation d'un composant Interface auquel l'extension de liaison HTTP est appliquée, à moins d'être spécifiquement surclassée par un composant Binding Operation. Ainsi, si un composant Interface Operation donné n'est pas spécifiquement référencé par un composant Binding Operation, alors toutes les règles par défaut s'appliquent à ce composant Interface Operation. En conséquence, conformément aux exigences dans [WSDL 2.0 Core Language], toutes les opérations d'un composant Interface seront liées par cette extension de liaison.

Remarque : Comme ailleurs dans cette spécification, on aurait pu se passer de propriétés « par défaut » au niveau du modèle de composants et fixer la valeur des propriétés correspondantes non par défaut dans la section de la correspondance XML. Par contre, les propriétés par défaut sont nécessaires pour une liaison sans interface (interface-less binding). En effet, une liaison sans interface n'a aucun moyen d'établir la version non par défaut de la propriété au niveau de l'opération. La correspondance doit donc être réalisée ailleurs.

[Définition : La représentation de l'arbre interne d'un message d'entrée, de sortie ou d'incident est appelée données d'instance (instance data) et elle est contrainte par la définition de schéma associée au message ; c'est l'élément XML référencé dans la propriété {element declaration} du composant Interface Message Reference des message d'entrée et de sortie (sauf si la propriété {message content model} est "#any"), et dans la propriété {element declaration} d'un composant Interface Fault en ce qui concerne les incidents.]

6.1 Identification de l'utilisation de la liaison HTTP

Un composant Binding (défini dans [WSDL 2.0 Core Language]) est identifié comme étant une liaison HTTP en affectant la valeur "http://www.w3.org/ns/wsdl/http" à la propriété {type} du composant Binding.

6.2 Récapitulatif de la syntaxe HTTP (non normatif)

<description>
  <binding name="xs:NCName" interface="xs:QName"?
           type="http://www.w3.org/ns/wsdl/http"
           whttp:methodDefault="xs:string"?
           whttp:queryParameterSeparatorDefault="xs:string"?
           whttp:cookies="xs:boolean"?
           whttp:contentEncodingDefault="xs:string"? >
   <documentation />?

    <fault ref="xs:QName"
           whttp:code="union de xs:int, xs:token"?
           whttp:contentEncoding="xs:string"? >
      <documentation />*
      <whttp:header name="xs:string" type="xs:QName"
                    required="xs:boolean"? >
        <documentation />*
      </whttp:header>*
    </fault>*

    <operation ref="xs:QName" 
               whttp:location="xs:anyURI"?
               whttp:method="xs:string"? 
               whttp:inputSerialization="xs:string"? 
               whttp:outputSerialization="xs:string"? 
               whttp:faultSerialization="xs:string"? 
               whttp:queryParameterSeparator="xs:string"?
               whttp:contentEncodingDefault="xs:string"?
               whttp:ignoreUncited="xs:boolean"? >
          <documentation />*

      <input messageLabel="xs:NCName"? 
             whttp:contentEncoding="xs:string"? >
        <documentation />*
        <whttp:header ... />*
      </input>*

      <output messageLabel="xs:NCName"?
              whttp:contentEncoding="xs:string"? >
        <documentation />*
        <whttp:header ... />*
      </output>*

      <infault ref="xs:QName"
                  messageLabel="xs:NCName"? >
        <documentation />*
      </infault>*

      <outfault ref="xs:QName"
                 messageLabel="xs:NCName"? >
        <documentation />*
      </outfault>*

    </operation>*

  </binding>

  <service>
    <endpoint name="xs:NCName" binding="xs:QName" address="xs:anyURI"?
              whttp:authenticationScheme="xs:token"? 
              whttp:authenticationRealm="xs:string"? >
      <documentation />*
    </endpoint>
  </service>
</description>

6.3 Extensions gérées

Une mise en œuvre de l'extension de liaison HTTP DOIT prendre en charge l'extension suivante :

6.4 Règles de liaison HTTP

6.4.1 Sélection de la méthode HTTP

Lors de la formulation du message HTTP à transmettre, la méthode de la requête HTTP DOIT être sélectionnée d'après l'un des cas suivants  :

6.4.2 Sélection du codage de contenu HTTP

Lors de la formulation du message HTTP à transmettre, le codage de contenu (content encoding) d'un composant Binding Message Reference donné est déterminé comme suit  :

  • Si la propriété {http content encoding} a une valeur non vide, un champ d'en-tête Content-Encoding DOIT être inséré avec la valeur de cette propriété ;

  • Sinon, si la valeur de la propriété {http content encoding default} du composant Binding Operation parent a une valeur non vide, un champ d'en-tête Content-Encoding DOIT être inséré avec la valeur de cette propriété ;

  • Sinon, si la valeur de la propriété {http content encoding default} du composant Binding grand-parent a une valeur non vide, un champ d'en-tête Content-Encoding DOIt être inséré avec la valeur de cette propriété.

Lors de la formulation du message d'incident HTTP à transmettre, le codage de contenu d'un composant Binding Fault donné est déterminé comme suit  ;

  • Si la propriété {http content encoding} a une valeur non vide, alors un champ d'en-tête Content-Encoding DOIT être inséré avec la valeur de cette propriété ;

  • Si la propriété {http content encoding default} a une valeur non vide, alors un champ d'en-tête Content-Encoding DOIT être inséré avec la valeur de cette propriété.

Le corps du message de réponse est codé avec le codage de contenu indiqué.

6.4.3 Construction de la charge utile et format de sérialisation

Lors de la formulation du message HTTP à transmettre, le contenu de la charge utile (c'est-à-dire le contenu du corps de message HTTP) DOIT être celui qui est défini par les composants Interface Message Reference ou Interface Fault correspondants, sérialisé comme indiqué par le format de sérialisation utilisé .

[Définition : Le format de sérialisation (serialization format) est un atome de type de média (de la forme "type/sous-type"). Il identifie les règles pour sérialiser la charge utile dans un message HTTP. Sa valeur est définie par les règles suivantes. Le format de sérialisation de la requête HTTP DOIT être dans la gamme de type de média (media type range) indiquée par la propriété {http input serialization}. Le format de sérialisation de la réponse HTTP DOIT être dans la gamme de type de média indiquée par la propriété {http output serialization}. Le format de sérialisation HTTP d'un incident DOIT être dans la gamme de type de média indiquée par la propriété {http fault serialization}. Le concept de gamme de type de média est défini à la section 14.1 dans [IETF RFC 2616]. Le format de sérialisation PEUT avoir des paramètres de type de média associés (définis par la production parameter de media-range à la section 14.1 dans [IETF RFC 2616]).]

La section 6.8 Format de sérialisation des données d'instance définit les formats de sérialisation gérés par cette extension de liaison ainsi que leurs contraintes.

Si le composant Interface Message Reference, ou le composant Interface Fault, est déclaré en utilisant un système de typage non-XML (comme examiné à la section Types dans [WSDL 2.0 Core Language]), alors d'autres règles de liaison DOIVENT être définies dans une spécification d'extension pour indiquer comment associer (map) ces composants dans l'enveloppe HTTP .

6.4.3.1 Règles de sérialisation des messages XML

Les règles de sérialisation des messages dont la propriété {message content model} est soit "#element", soit "#any", et les règles de sérialisation des messages d'incident sont les suivantes  :

6.4.4 Format de sérialisation d'entrée et de sortie par défaut

La section tableau 6-1 définit les valeurs par défaut des valeurs GET, POST, PUT et DELETE de la méthode HTTP, sélectionnée selon la section 6.4.1 Sélection de la méthode HTTP.

Tableau 6-1. Valeurs par défaut pour GET, POST, PUT et DELETE
Méthode HTTP Sérialisation d'entrée par défaut Sérialisation de sortie par défaut
Sélectionnée selon la section 6.4.1 Sélection de la méthode HTTP {http input serialization} {http output serialization}
GET application/x-www-form-urlencoded application/xml
POST application/xml application/xml
PUT application/xml application/xml
DELETE application/x-www-form-urlencoded application/xml

Remarque :

Le format de sérialisation application/x-www-form-urlencoded exerce des contraintes sur la définition XML Schema de la propriété {element declaration} des composants Interface Message Reference du composant Interface Operation lié (cf. la section 6.8.2 Sérialisation comme type "application/x-www-form-urlencoded").

La valeur par défaut des propriétés {http input serialization} et {http output serialization} pour toute autre méthode HTTP sélectionnée est application/xml.

D'autres mécanismes que ceux de réglage des propriétés de sérialisation PEUVENT modifier le format de sérialisation des données d'instance correspondant au message. Un exemple d'une telle modification est celui des règles de sérialisation d'adresse IRI HTTP de la liaison SOAP WSDL définies à la section 5.3 Règles de liaison SOAP. Cette extension de liaison indique que le modèle d'échange de messages SOAP Response (section 6.3 dans [SOAP 1.2 Part 2: Adjuncts (Second Edition)]) ne gère une sérialisation de message d'entrée que comme application/x-www-form-urlencoded. Les autres modèles d'échange de messages ou extensions de liaison fournissent d'autres exemples.

6.4.5 Construction d'en-tête HTTP

Si la propriété {http headers} comme définie à la section 6.6 Déclaration des en-têtes HTTP existe et n'est pas vide dans un composant Binding Message Reference ou Binding Fault, les en-têtes HTTP conformes à chaque composant HTTP Header contenu dans cette propriété {http headers} PEUVENT être sérialisés comme suit  :

  • Le nom de champ d'en-tête HTTP utilisé dans la valeur de la propriété {name} du composant HTTP Header. La liaison HTTP NE DOIT PAS établir de champ d'en-tête HTTP correspondant à la valeur de la propriété {name} déjà fixée par un autre mécanisme, tel que la pile HTTP ou une autre caractéristique  ;

  • La valeur de champ d'en-tête HTTP, dont le type XML Schema est déclaré par la propriété {type definition} du composant HTTP Header, est sérialisée selon les règles de la production field-value à la section 4.2 de [IETF RFC 2616].

Si la valeur de la propriété {required} d'un composant HTTP Header est "true", l'inclusion de ce champ d'en-tête HTTP est OBLIGATOIRE , sinon elle est OPTIONNELLE.

6.4.6 Adresse IRI de requête HTTP

Lors de la formulation de la requête HTTP, l'adresse IRI de la requête HTTP est une référence IRI absolue et c'est la valeur de la propriété {http location} du composant Binding Operation, résolue en utilisant la valeur de la propriété {address} du composant Endpoint (cf. la section 5 de [IETF RFC 3986]) . Si la propriété {http location} n'est pas établie, l'adresse IRI de requête HTTP est la valeur de la propriété {address} du composant Endpoint. Les sérialisations d'entrée peuvent définir des règles de traitement supplémentaires, à appliquer à la valeur de {http location} avant de lancer le processus de résolution de référence, c'est-à-dire avant de la combiner avec la propriété {address} de l'élément endpoint pour former l'adresse IRI de requête HTTP. Ainsi, les trois formats de sérialisation décrits à la section 6.8 Format de sérialisation des données d'instance définissent une syntaxe pour utiliser la propriété {http location} comme gabarit avec les éléments des données d'instance.

Si l'adresse IRI résultante utilise le schéma https, alors on utilise HTTP sur le protocole TLS [IETF RFC 2818] pour envoyer la requête HTTP.

L'adresse IRI de requête HTTP qui identifie la ressource sur laquelle appliquer la demande est transmise en utilisant les champs d'en-tête Request-URI et, en option, Host, comme définis dans [IETF RFC 2616].

6.5 Opérations de liaison

6.5.1 Description

Cette spécification d'extension de liaison fournit à HTTP une liaison aux composants Interface Operation dont la propriété {message exchange pattern} a l'une des valeurs suivantes :

  • "http://www.w3.org/ns/wsdl/in-only"

  • "http://www.w3.org/ns/wsdl/robust-in-only"

  • "http://www.w3.org/ns/wsdl/in-out"

Cette extension de liaison HTTP PEUT être utilisée avec d'autres modèles d'échange de messages, tels que des modèles d'échange de messages hors-bande, à condition de définir des sémantiques supplémentaires, par exemple, au travers d'une extension.

Chaque modèle d'échange de messages parmi les trois cités implique l'échange d'un ou deux messages ou incidents. Le premier est transmis en utilisant une requête HTTP et le deuxième en utilisant la réponse HTTP correspondante . Au cas où un seul message est envoyé, le corps de message de la réponse HTTP DOIT être vide .

Pour les réponses réussies, le code de réponse HTTP DOIT être le suivant :

  • 202 lorsque le modèle d'échange de messages est "http://www.w3.org/ns/wsdl/in-only"  ;

  • 204 lorsque le modèle d'échange de messages est "http://www.w3.org/ns/wsdl/robust-in-only" .

Pour chaque composant Binding Operation correspondant à de tels composants Interface Operation, cette spécification d'extension de liaison permet à l'utilisateur d'indiquer la méthode HTTP à utiliser, la sérialisation d'entrée, de sortie et d'incident, et l'emplacement de l'opération liée.

6.5.2 Relation avec le modèle de composants WSDL

L'extension de liaison HTTP ajoute les propriétés suivantes au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

6.5.3 Spécification des règles de sérialisation permises

La valeur des propriétés {http input serialization}, {http output serialization} et {http fault serialization} est similaire à la valeur permise pour l'en-tête HTTP Accept, définie par la spécification HTTP 1.1 (cf. la section 14.1 dans [IETF RFC 2616]), et elle DOIT suivre les règles de production définies dans cette section sauf pour ce qui suit  :

  1. Le préfixe "Accept:" NE DOIT PAS être utilisé ;

  2. La règle qdtext change de :

    qdtext = <tout TEXT sauf<">>

    Pour :

    qdtext = <tout CHAR sauf<">>

    Cette modification est apportée pour interdire les « OCTET » non-US-ASCII.

Ces propriétés indiquent la gamme des types de média et des paramètres associés avec lesquels une instance PEUT être sérialisée. La valeur du format de sérialisation utilisé pour un message est un type de média qui DOIT être couvert par cette gamme . On NE DEVRAIT PAS utiliser de caractères génériques (wildcards), par exemple, "application/*", dans cet item d'information d'attribut car ils peuvent entraîner des problèmes d'interopérabilité .

L'utilisation des propriétés {http input serialization}, {http output serialization} et {http fault serialization} est spécifiée à la section 6.4.3 Construction de la charge utile et format de sérialisation.

6.5.4 Représentation XML

<description>
 <binding whttp:methodDefault="xs:string"?
          whttp:queryParameterSeparatorDefault="xs:string"? >
   <operation ref="xs:QName" 
              whttp:location="xs:anyURI"?
              whttp:method="xs:string"? 
              whttp:inputSerialization="xs:string"? 
              whttp:outputSerialization="xs:string"? 
              whttp:faultSerialization="xs:string"?
              whttp:queryParameterSeparator="xs:string"? >
  </operation>
 </binding>
</description>

La représentation XML de liaison d'une opération consiste en six items d'information d'attribut avec les propriétés d'ensemble d'information suivantes :

  • un item d'information d'attribut location OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de location ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:anyURI.

  • un item d'information d'attribut method OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de method ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:string.

  • un item d'information d'attribut inputSerialization OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de inputSerialization ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:string.

  • un item d'information d'attribut outputSerialization OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de outputSerialization ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:string.

  • un item d'information d'attribut faultSerialization OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de faultSerialization ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:string.

  • un item d'information d'attribut queryParameterSeparator OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de queryParameterSeparator ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:string, dont la facette pattern est "[&;a-zA-Z0-9\-\._~!$'\(\):@/\?\*\+,]{1,1}" ; les caractères « & » et « ; » sont les plus souvent employés dans la pratique.

Les items d'information d'attribut suivants de l'item d'information d'élément binding sont définis :

  • un item d'information d'attribut methodDefault OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de methodDefault ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:string.

  • un item d'information d'attribut queryParameterSeparatorDefault OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de queryParameterSeparatorDefault.

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:string dont la facette length est "1". Les caractères admis sont les mêmes que pour la propriété {http query parameter separator} ci-dessus.

6.5.5 Correspondance de la représentation XML aux propriétés de composant

See tableau 6-2.

Tableau 6-2. Correspondance de la représentation XML aux propriétés d'extension du composant Binding Operation
Propriété Valeur
{http location} La valeur réelle de l'item d'information d'attribut whttp:location, si présent.
{http method default} La valeur réelle de l'item d'information d'attribut whttp:methodDefault, si présent.
{http method} La valeur réelle de l'item d'information d'attribut whttp:method, si présent.
{http input serialization} La valeur réelle de l'item d'information d'attribut whttp:inputSerialization, si présent ; sinon la valeur par défaut telle que définie à la section 6.4 Règles de liaison HTTP.
{http output serialization} La valeur réelle de l'item d'information d'attribut whttp:outputSerialization, si présent ; sinon la valeur par défaut telle que définie à la section 6.4 Règles de liaison HTTP.
{http fault serialization} La valeur réelle de l'item d'information d'attribut whttp:faultSerialization, si présent ; sinon "application/xml".
{http query parameter separator default} La valeur réelle de l'item d'information d'attribut whttp:queryParameterSeparatorDefault, si présent ; sinon "&".
{http query parameter separator} La valeur réelle de l'item d'information d'attribut whttp:queryParameterSeparator, si présent.

6.6 Déclaration des en-têtes HTTP

6.6.1 Description

HTTP permet l'utilisation d'en-têtes dans les messages. Cette extension de liaison permet aux utilisateurs de déclarer les en-têtes HTTP en vigueur pour chaque message et pour chaque incident.

6.6.2 Relation avec le modèle de composants WSDL

La spécification d'extension de liaison du composant HTTP Header ajoute les propriétés suivantes au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

La propriété {http headers} d'un composant Binding Message Reference ou Binding Fault NE DOIT PAS contenir plusieurs composants HTTP Header avec la même propriété {name

6.6.3 Composant HTTP Header

Un composant HTTP Header décrit un morceau abstrait de données d'en-tête (champ d'en-tête HTTP) associé à l'échange de messages entre les parties communicantes. La présence d'un composant HTTP Header dans une description WSDL indique que le service gère les en-têtes et PEUT imposer au client interagissant avec lui d'utiliser le champ d'en-tête décrit. Zéro ou un seul tel champ d'en-tête peut être utilisé.

Les propriétés du composant HTTP Header sont les suivantes :

  • {name}, OBLIGATOIRE. Un type xs:string dont la facette pattern est "[!#-'*+\-.0-9A-Z^-z|~]+" ; c'est le nom du champ d'en-tête HTTP. La valeur de cette propriété suit les règles de la production field-name, comme définie à la section 4.2 de [IETF RFC 2616] ;

  • {type definition}, OBLIGATOIRE. Un composant Type Definition, dans la propriété {type definitions} du composant Description, contraignant la valeur du champ d'en-tête HTTP. Ce type DOIT être un type simple  ;

  • {required}, OBLIGATOIRE. Un type xs:boolean indiquant si le champ d'en-tête HTTP est nécessaire. Si la valeur est "true", alors le champ d'en-tête HTTP DOIT être inclus dans le message . Si la valeur est "false", le champ d'en-tête HTTP PEUT être inclus ;

  • {parent}, OBLIGATOIRE. Le composant Binding Fault ou Binding Message Reference qui contient ce composant dans sa propriété {http headers}.

6.6.4 Représentation XML

<description>
  <binding name="xs:NCName" type="http://www.w3.org/ns/wsdl/http" >
    <fault ref="xs:QName">
      <whttp:header name="xs:string" type="xs:QName"
                    required="xs:boolean"? >
        <documentation />*
      </whttp:header>*
      ...
    </fault>*
    <operation ref="xs:QName" >
      <input messageLabel="xs:NCName"?>
        <whttp:header ... />*
        ...
      </input>*
      <output messageLabel="xs:NCName"?>
        <whttp:header ... />*
        ...
      </output>*
    </operation>*
  </binding>
</description>

La représentation XML d'un composant HTTP Header est un item d'information d'élément avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de header ;

  • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

  • un ou plusieurs items d'information d'attribut parmi ses attributs [attributes] comme suit :

    • un item d'information d'attribut name OBLIGATOIRE avec les propriétés d'ensemble d'information suivantes :

      • un nom local [local name] de name ;

      • un nom d'espace de noms [namespace name] sans valeur ;

      • un type de xs:string dont la facette pattern est "[!#-'*+\-.0-9A-Z^-z|~]+".

    • un item d'information d'attribut type OBLIGATOIRE avec les propriétés d'ensemble d'information suivantes :

      • un nom local [local name] de type ;

      • un nom d'espace de noms [namespace name] sans valeur ;

      • un type de xs:QName.

    • un item d'information d'attribut required OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

      • un nom local [local name] de required ;

      • un nom d'espace de noms [namespace name] sans valeur ;

      • un type de xs:boolean.

    • zéro ou plus items d'information d'attribut qualifiés d'un espace de noms. Le nom d'espace de noms [namespace name] de ces items d'information d'attribut NE DOIT PAS être "http://www.w3.org/ns/wsdl" NI "http://www.w3.org/ns/wsdl/http".

  • zéro ou plus items d'information d'élément parmi ses sous-éléments [children], en ordre, comme suit :

    1. zéro ou plus items d'information d'élément documentation comme défini dans [WSDL 2.0 Core Language] ;

    2. zéro ou plus items d'information d'élément, qualifiés d'un espace de noms, parmi ses sous-éléments [children]. Le nom d'espace de noms [namespace name] de ces items d'information d'élément NE DOIT PAS être "http://www.w3.org/ns/wsdl" NI "http://www.w3.org/ns/wsdl/http".

6.6.5 Correspondance de la représentation XML aux propriétés de composant

Cf.  le tableau 6-3.

Tableau 6-3. Correspondance de la représentation XML aux propriétés liées au composant HTTP Header
Propriété Valeur
{http headers} L'ensemble des composants HTTP Header correspondant à tous les items d'information d'élément header dans les sous-éléments [children] des items d'information d'élément fault, input ou output, le cas échéant.
{name} La valeur de l'item d'information d'attribut name.
{type definition} Le composant Type Definition de la propriété {type definitions} du composant Description résolue par la valeur de l'item d'information d'attribut type.
{required} La valeur réelle de l'item d'information d'attribut required, si présent ; sinon "false".
{parent} Le composant Binding Fault ou Binding Message Reference correspondant à l'item d'information d'élément fault, input ou output dans le parent [parent].

6.6.6 Identification IRI d'un composant HTTP Header

WSDL version 2.0 tome 1 [WSDL 2.0 Core Language] définit une syntaxe d'identificateur de fragment pour identifier les composants d'un document WSDL 2.0.

Un composant HTTP Header peut être identifié en utilisant le schéma wsdl.extension du cadre XPointer :

wsdl.extension(http://www.w3.org/ns/wsdl/http, whttp.header(parent/name))

  1. parent est la partie pointeur du composant {parent}, comme défini dans la spécification WSDL version 2.0 tome 1 — Cœur du langage ;

  2. name est la valeur de la propriété {name}.

6.7 Indication du code d'erreur HTTP pour les incidents

6.7.1 Description

Pour chaque composant Interface Fault contenu dans un composant Interface, un code d'erreur HTTP PEUT être défini. Il représente le code d'erreur qui sera utilisé par le service au cas où l'incident doit être retourné.

La définition d'incident DEVRAIT correspondre à celle des codes d'erreur HTTP, comme définis à la section 8 de [IETF RFC 3205.

6.7.2 Relation avec le modèle de composants WSDL

L'extension de liaison d'incident HTTP ajoute la propriété suivante au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

  • {http error status code}, OBLIGATOIRE. L'union d'un type xs:int et d'un type xs:token, où la valeur d'atome permise est "#any" ; propriété ajoutée au composant Binding Fault. Une valeur entière de cette propriété identifie l'erreur Status-Code, comme définie par [IETF RFC 2616], que le service utilisera au cas où l'incident est retourné . Si la valeur de cette propriété est "#any", le service ne fait aucune réclamation.

6.7.3 Représentation XML

<description>
  <binding >
    <fault ref="xs:QName"
           whttp:code="union de xs:int, xs:token"? >
    </fault>*
  </binding>
</description>

La représentation XML pour lier un incident HTTP est un item d'information d'attribut avec les propriétés d'ensemble d'information suivantes :

  • un item d'information d'attribut code OPTIONNEL ;

    • un nom local [local name] de code ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type composé de l'union d'un type xs:int et d'un type xs:token, où la valeur d'atome permise est "#any".

6.7.4 Correspondance de la représentation XML aux propriétés de composant

Cf. le tableau 6-4.

Tableau 6-4. Correspondance de la représentation XML aux propriétés d'extension du composant Binding Fault
Propriété Valeur
{http error status code} La valeur réelle de l'item d'information d'attribut whttp:code, si présent ; sinon "#any".

6.8 Format de sérialisation des données d'instance

Cette section spécifie trois formats de sérialisation définissant les règles pour coder les données d'instance d'un message d'entrée ou de sortie comme un message HTTP. Le tableau 6-5 et le tableau 6-6 donne une vue d'ensemble de ces formats de sérialisation et leurs contraintes. Tous ceux-ci permettent la sérialisation de parties des données d'instance dans l'adresse IRI de requête HTTP, comme définie à la section 6.8.1 Sérialisation des données d'instance dans les parties de l'adresse IRI de requête HTTP.

D'autres formats de sérialisation peuvent être définis. Ceux-ci DEVRAIENT placer les restrictions sur le style du composant Interface Operation lié.

Tableau 6-5. Applicabilité des formats de sérialisation définis dans cette section pour cette liaison HTTP
- Sérialisation des données d'instance dans les parties d'un message HTTP
Dans l'adresse URI de requête Dans le corps du message
application/x-www-form-urlencoded multipart/form-data application/xml
Requête HTTP (message d'entrée) Sans corps de message : GET, DELETE, … Tous, certains ou aucun - - -
Avec corps de message : POST, PUT, … Tous, certains ou aucun Reste Tous Tous
Réponse HTTP (message de sortie) - - - Tous
Tableau 6-6. Styles d'opération nécessaires pour utiliser les formats de sérialisation définis ci-dessous comme sérialisation d'entrée
Méthode HTTP Requête
Adresse URI de requête : paramètres de requête ou composants de chemin Sérialisation d'entrée
application/x-www-form-urlencoded multipart/form-data application/xml
Sans corps de message : GET, DELETE, … Style IRI Style IRI - -
Avec corps de message : POST, PUT, … Style IRI, si des données sont sérialisées comme composants de chemin ou paramètres de requête. Style IRI Style multipart Aucun exigé

6.8.1 Sérialisation des données d'instance dans les parties de l'adresse IRI de requête HTTP

Cette section définit les règles de modélisation (templating rules) de la propriété {http location} du composant Binding Operation. Une modélisation est utilisée par les formats de sérialisation, définis à la section 6.8 Format de sérialisation des données d'instance, et elle PEUT être réutilisée par d'autres formats de sérialisation.

Avec cette liaison HTTP, une partie des données d'instance des requêtes HTTP PEUT être sérialisée dans la requête HTTP et une autre partie PEUT l'être dans le corps du message HTTP.

Si la propriété {style} du composant Interface Operation lié a une valeur de "http://www.w3.org/ns/wsdl/style/iri", comme définie à la section 4.2 Style IRI, et si la propriété {http location} du composant Binding Operation est présente, la valeur de la propriété {http location} du composant est utilisée comme gabarit (template) , lequel est combiné avec la propriété {address} de l'élément endpoint pour former l'adresse IRI complète à utiliser dans une requête HTTP, comme défini à la section 6.5.2 Relation avec le modèle de composants WSDL.

L'adresse IRI obtenue DOIT être associée à une adresse URI à utiliser dans la requête HTTP, selon la section 3.1 Correspondance des adresse IRI aux adresses URI de la spécification IRI [IETF RFC 3987. Un format de sérialisation PEUT définir des règles supplémentaires pour la sérialisation de l'adresse IRI de requête HTTP.

6.8.1.1 Construction de l'adresse IRI de requête en utilisant la propriété {http location}

La propriété {http location} PEUT citer les noms locaux des éléments à partir des données d'instance du message à sérialiser dans l'adresse IRI de requête. La citation s'effectue :

  • soit en plaçant le nom de l'élément entre des accolades. Ainsi, "temperature/{town}". Cf. l'exemple 6-1 pour des précisions ;

  • soit en plaçant le nom de l'élément à l'intérieur d'accolades avec un point d'exclamation pour inclure l'élément sans codage avec pourcentage (percent-encoding). Ainsi, "temperature/{!town}". Les règles détaillées suivent.

La propriété {http location} DOIT se conformer à la grammaire EBNF [ISO/IEC 14977:1996] suivante, qui représente les modèles pour construire l'adresse IRI de requête  :

httpLocation ::= charData? (( openBrace | closeBrace | template ) charData?)*
charData ::= [^{}]*
openBrace ::= '{{'
closeBrace ::= '}}'
template ::= rawTemplate | encodedTemplate
rawTemplate ::= '{!' NCName '}'
encodedTemplate ::= '{' NCName '}'

L'adresse IRI de requête est construite comme suit (les productions ALPHA et DIGIT ci-dessous sont définies dans [IETF RFC 4234]) :

  • Le nom local dans un modèle (template) DEVRAIT correspondre à au moins un élément des données d'instance du message d'entrée . Lorsqu'il n'y a pas de correspondance, le modèle est remplacé par une chaîne vide. Sinon, le modèle consomme le premier élément correspondant non consommé dans les données d'instance. L'apparition suivante du modèle consomme l'élément correspondant non consommé suivant, et ainsi de suite jusqu'à ce que tous les modèles soient traités. Les éléments correspondants sont consommés dans l'ordre où ils apparaissent dans les données d'instance. Les éléments cités (c'est-à-dire les éléments référencés dans les modèles) NE DOIVENT PAS porter d'attribut xs:nil dont la valeur est "true"  ;

  • Chaque modèle brut (la production rawTemplate dans la grammaire précédente) est remplacé par la seule valeur, éventuellement vide, de l'élément correspondant des données d'instance. Aucun codage avec pourcentage n'est effectué ;

  • Chaque modèle codé (la production encodedTemplate dans la grammaire précédente), dans la propriété {http location}, non précédé d'un caractère « ? » est remplacé par la seule valeur, éventuellement vide, de l'élément correspondant des données d'instance. Le codage est le suivant :

    • Les caractères dans la gamme "&" | ";" | "!" | "$" | "'" | "(" | ")" | "*" | "+" | "," | "=" | ":" | "@" DEVRAIENT être codés avec des pourcentages ;

    • Les autres caractères, sauf ceux dans la gamme ALPHA | DIGIT | "-" | "." | "_" | "~", DOIVENT être codés avec des pourcentages.

  • Chaque modèle codé (la production encodedTemplate dans la grammaire précédente), dans la propriété {http location}, précédé d'un caractère « ? » est remplacé par la seule valeur, éventuellement vide, de l'élément correspondant des données d'instance. Le codage est le suivant :

    • La valeur de la propriété {http query parameter separator}, si présente, sinon la valeur de la propriété {http query parameter separator default}, DOIT être codée avec des pourcentages ;

    • Les caractères dans la gamme "&" | ";" | "!" | "$" | "'" | "(" | ")" | "*" | "+" | "," | "=" | ":" | "@" | "?" | "/" DEVRAIENT être codés avec des pourcentages ;

    • Les autres caractères, sauf ceux dans la gamme ALPHA | DIGIT | "-" | "." | "_" | "~", DOIVENT être codés avec des pourcentages.

  • Chaque élément non cité (c'est-à-dire ceux non référencés dans un modèle) à sérialiser, le cas échéant, est codé comme pour un modèle codé ;

  • Le codage avec des pourcentages DOIT être réalisé en utilisant la représentation UTF-8 du caractère, comme prescrit à la section 6.4 de [IETF RFC 3987] ;

  • Chaque accolade double (les productions openBrace ou closeBrace dans la grammaire précédente) est remplacée par une seule accolade littérale (respectivement, "{" ou "}"). Cela fournit un mécanisme d'échappement simple (escaping mechanism).

Notez que le mécanisme décrit dans cette section pourrait être utilisé pour indiquer l'adresse IRI absolue entière, incluant le schéma, l'hôte ou le port, ainsi :

{scheme}://{host}:{port}/temperature/{town}
Ou même :
{!myIRI}

6.8.2 Sérialisation comme type "application/x-www-form-urlencoded"

Ce format de sérialisation est conçu pour permettre à un client ou un service web de produire une adresse IRI fondée sur les données d'instance d'un message et de sérialiser une chaîne d'interrogation (query string) dans le corps de message HTTP comme type application/x-www-form-urlencoded.

Si ce format est utilisé, alors la propriété {style} du composant Interface Operation lié DOIT contenir une valeur de "http://www.w3.org/ns/wsdl/style/iri", comme définie à la section 4.2 Style IRI, c'est-à-dire que ce format de sérialisation peut seulement être utilisé pour sérialiser la requête HTTP correspondant au message initial d'une opération d'interface .

Pour la liaison HTTP définie dans cette section (6. Extension de liaison HTTP WSDL), on PEUT utiliser "application/x-www-form-urlencoded" comme format de sérialisation pour un message d'entrée (requête HTTP) ; mais on NE DOIT PAS l'utiliser comme format de sérialisation pour un message de sortie ou d'incident (réponse HTTP.

6.8.2.1 Cas des éléments cités dans la propriété {http location}

Dans cette sérialisation, les règles pour construire l'adresse IRI de requête HTTP en utilisant les éléments cités dans la propriété {http location}, définies à la section 6.8.1 Sérialisation des données d'instance dans les parties de l'adresse IRI de requête HTTP, s'appliquent. Voici des règles supplémentaires pour construire l'adresse IRI de requête HTTP.

6.8.2.2 Sérialisation du contenu des données d'instance non citées dans la propriété {http location}

Si les éléments des données d'instance ne sont pas tous cités dans la propriété {http location}, ou si la propriété n'est pas présente sur le composant Binding Operation, alors des règles de sérialisation supplémentaires s'appliquent .

Le reste des données d'instance est formaté comme une chaîne d'interrogation telle que définie à la section 6.8.2.2.1 Construction de la chaîne d'interrogation.

Si la méthode HTTP utilisée pour la requête n'admet pas de corps de message, alors cette chaîne d'interrogation est sérialisée comme des paramètres dans l'adresse IRI de requête (cf. la section 6.8.2.2.3 Sérialisation dans l'adresse IRI de requête), sinon elle est sérialisée dans le corps de message (cf. la section 6.8.2.2.4 Sérialisation dans le corps de message).

6.8.2.2.1 Construction de la chaîne d'interrogation

Pour les éléments des données d'instance non cités dans la propriété {http location}, une chaîne d'interrogation se construit comme suit .

Les éléments non nuls (non-nil elements) avec une seule valeur éventuellement vide des données d'instance, non cités, sont sérialisés comme des paramètres d'interrogation dans l'ordre où ils apparaissent dans les données d'instance.

Les données d'instance NE DOIVENT PAS contenir d'éléments avec un attribut xs:nil dont la valeur est "true" .

Chaque couple de paramètre est séparé du suivant par la valeur de la propriété {http query parameter separator}, si présente, ou la valeur de la propriété {http query parameter separator default}.

  • Les éléments non cités avec des valeurs simples (non des listes) sont sérialisés en un seul couple de paramètre nom-valeur. Le nom du paramètre est le nom local de l'élément non cité, et la valeur du paramètre est celle de l'élément non cité ;

  • Les éléments non cités avec des valeurs de liste sont sérialisés en un couple de paramètre nom-valeur par valeur de liste. Le nom de chaque paramètre est le nom local de l'élément non cité, et la valeur de chaque paramètre est la valeur correspondante dans la liste. L'ordre des valeurs de liste est conservé ;

  • Les valeurs de remplacement tombant hors de la gamme ALPHA | DIGIT | "-" | "." | "_" | "~" | "!" | "$" | "&" | "'" | "(" | ")" | "*" | "+" | "," | ";" | "=" | ":" | "@" (ALPHA et DIGIT sont définis selon le RFC [IETF RFC 4234]) DOIVENT être codés avec des pourcentages. Le codage avec des pourcentages DOIT être effectué en utilisant la représentation UTF-8 du caractère, comme prescrit à la section 6.4 de [IETF RFC 3987].

Exemple 6-1. Génération d'une chaîne d'interrogation

Les données d'instance suivantes d'un message d'entrée :

<data>
  <town>Fréjus</town>
  <date>2007-06-26</date>
  <unit>C</unit>
</data>

dont la valeur de la propriété {http location} est :

'temperature/{town}'

et dont la valeur de la propriété {http query parameter separator default} est :

'&'

produira la chaîne d'interrogation suivante :

date=2007-06-26&unit=C
6.8.2.2.2 Contrôle de la sérialisation de la chaîne d'interrogation dans l'adresse IRI de requête

Ce format de sérialisation ajoute la propriété suivante au composant Binding Operation :

  • {http location ignore uncited}, OBLIGATOIRE. Un type xs:boolean. Ce booléen indique si les éléments non cités dans la propriété {http location} DOIVENT être ajoutés à la fin de l'adresse IRI de requête ou ignorés. Si la valeur de cette propriété est "false", les règles définies à la section 6.8.2.2.3 Sérialisation dans l'adresse IRI de requête dictent comment sérialiser les éléments non cités dans {http location} dans l'adresse IRI de requête. Sinon ces éléments ne sont pas sérialisés dans l'adresse IRI de requête.

Lorsqu'on sérialise une requête HTTP qui n'admet pas de corps de message HTTP et que la propriété {http location ignore uncited} est "true", tout élément non cité dans la propriété {http location} DOIT être défini dans le schéma comme nillable, ou avoir une valeur default, ou ne pas apparaître moins de fois qu'indiqué par la valeur de minOccurs. La déclaration d'élément NE DEVRAIT PAS combiner une valeur par défaut avec nillable .

La représentation XML de cette propriété est un item d'information d'attribut avec les propriétés d'ensemble d'information suivantes :

  • un item d'information d'attribut ignoreUncited OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de ignoreUncited ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:boolean.

La correspondance de la représentation XML aux propriétés de composant est comme suit :

Tableau 6-7. Correspondance de la représentation XML aux propriétés d'extension du composant Binding Operation
Propriété Valeur
{http location ignore uncited} La valeur réelle de l'item d'information d'attribut whttp:ignoreUncited, si présent ; sinon "false".
6.8.2.2.3 Sérialisation dans l'adresse IRI de requête

Si la méthode de requête HTTP utilisée n'admet pas de corps de message HTTP (par exemple, les méthodes "GET" et "DELETE"), et si la valeur de la propriété {http location ignore uncited} est "false", alors les règles suivantes s'appliquent .

Si la propriété {http location} n'est pas présente, ou qu'elle est présente mais que sa valeur ne contient pas un caractère point d'interrogation « ? », il en est ajouté un à la fin de l'adresse IRI de requête. Si elle contient déjà un point d'interrogation, alors la valeur de la propriété {http query parameter separator}, si présente, ou de la propriété {http query parameter separator default} sinon, est ajoutée à la fin.

Enfin, la chaîne d'interrogation calculée d'après la section 6.8.2.2.1 Construction de la chaîne d'interrogation est ajoutée à la fin.

Exemple 6-2. Données d'instance data sérialisées dans une adresse IRI

Les données d'instance définies dans l'exemple 6-1 avec la déclaration d'élément operation suivante :

<operation ref='t:data'
    whttp:location='temperature/{town}'
    whttp:method='GET' />

et la déclaration d'élément endpoint suivante :

<endpoint name='e' binding='t:b'
    address='http://ws.example.com/service1/' />

produiront une sérialisation du message dans la requête HTTP comme suit :

GET http://ws.example.com/service1/temperature/Fr%C3%A9jus?date=2007-06-26&unit=C HTTP/1.1
Host: ws.example.com
6.8.2.2.4 Sérialisation dans le corps de message

Si la méthode de requête HTTP admet un corps de message HTTP (par exemple, les méthodes "POST" et "PUT"), alors les règles suivantes s'appliquent .

Finalement, la chaîne d'interrogation calculée d'après la section 6.8.2.2.1 Construction de la chaîne d'interrogation est utilisée comme valeur du corps de message HTTP.

Le champ d'en-tête HTTP Content-Type doit avoir la valeur application/x-www-form-urlencoded .

Exemple 6-3. Données d'instance sérialisées dans l'adresse IRI de requête et dans le corps de message

Les données d'instance définies dans l'exemple 6-1 avec la déclaration d'élément operation suivante :

<operation ref='t:data'
    whttp:inputSerialization='application/x-www-form-urlencoded'
    whttp:location='temperature/{town}'
    whttp:method='POST' />

et la déclaration d'élément endpoint suivante :

<endpoint name='e' binding='t:b'
    address='http://ws.example.com/service1/' />

produiront une sérialisation du message dans la requête HTTP comme suit :

POST http://ws.example.com/service1/temperature/Fr%C3%A9jus HTTP/1.1
Host: ws.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: …

date=2007-06-26&unit=C

6.8.3 Sérialisation comme type "application/xml"

Dans cette sérialisation, pour les requêtes HTTP, les règles définies à la section 6.8.1 Sérialisation des données d'instance dans les parties de l'adresse IRI de requête HTTP pour construire l'adresse IRI de requête HTTP s'appliquent, si la propriété {style} du composant Interface Operation lié a une valeur de "http://www.w3.org/ns/wsdl/style/iri", comme définie à la section 4.2 Style IRI.

Les données d'instance du message d'entrée, de sortie ou d'incident sont sérialisées en un document XML dans le corps de message du message HTTP, en suivant la sérialisation définie dans [Canonical XML]. De ce fait, elle convient seulement pour les requêtes HTTP utilisant des méthodes admettant un corps de message (c'est-à-dire, pour les messages d'entrée de la liaison HTTP définie dans cette spécification où la méthode HTTP sélectionnée a un corps), et pour les réponses HTTP (c'est-à-dire, pour les messages de sortie et d'incident de la liaison HTTP définie dans cette spécification).

L'en-tête HTTP Content-Type DOIT avoir la valeur application/xml [IETF RFC 3023], ou un type de média compatible avec application/xml, comme défini à la section 6.4.3.1 Règles de sérialisation des messages XML . D'autres en-têtes HTTP PEUVENT être utilisés.

6.8.4 Sérialisation comme type "multipart/form-data"

Dans cette sérialisation, pour les requêtes HTTP, les règles définies à la section 6.8.1 Sérialisation des données d'instance dans les parties de l'adresse IRI de requête HTTP pour construire l'adresse IRI de requête HTTP s'appliquent, si la propriété {style} du composant Interface Operation lié a une valeur de "http://www.w3.org/ns/wsdl/style/iri", comme définie à la section 4.2 Style IRI.

Ce format, pour la compatibilité à l'existant, permet d'utiliser des clients XForms avec des serveurs [IETF RFC 2388]. Ce format de sérialisation ne peut être utilisé que pour lier des composants Interface Operation dont la propriété {style} a une valeur de "http://www.w3.org/ns/wsdl/style/multipart", comme définie à la section 4.3 Style multipart, c'est-à-dire qu'on ne peut utiliser ce format de sérialisation que pour sérialiser la requête HTTP correspondant au message initial d'une opération d'interface .

Spécifiquement, pour la liaison HTTP définie dans cette section (6. Extension de liaison HTTP WSDL), on PEUT utiliser "multipart/form-data" comme format de sérialisation pour un message d'entrée (requête HTTP) ; mais on NE DOIT PAS l'utiliser comme format de sérialisation pour un message de sortie ou d'incident (réponse HTTP. Ce format sérialise les données d'instance dans le corps de message HTTP et convient seulement pour les requêtes HTTP utilisant des méthodes admettant un corps de message.

Chaque élément dans la séquence est sérialisé en une partie comme suit :

  1. L'en-tête Content-Disposition DOIT avoir la valeur form-data, et son paramètre name être le nom local de l'élément  ;

  2. L'en-tête Content-Type DOIT avoir pour valeur  :

    • application/xml (ou un type de média compatible avec application/xml) si l'élément a un type complexe ;

    • application/octet-stream si l'élément est de type xs:base64Binary, xs:hexBinary, ou d'un type dérivé ;

    • text/plain si l'élément a un type simple ; le paramètre charset DOIT être réglé de façon appropriée. Les codages UTF-8 ou UTF-16 DOIVENT être gérés au minimum.

  3. Si le type est xs:base64Binary, xs:hexBinary, xs:anySimpleType, ou un type dérivé, le contenu de la partie est le contenu de l'élément. Si c'est un type complexe, l'élément est sérialisé suivant les règles définies à la section 6.8.3 Sérialisation comme type "application/xml".

Les données d'instance NE DOIVENT PAS contenir d'éléments avec un attribut xs:nil dont la valeur est "true" .

Exemple 6-4. Exemple de sérialisation "multipart/form-data"

Les données d'instance suivantes d'un message d'entrée :

<data>
  <town>
    <name>Fréjus</name>
    <country>France</country>
  </town>
  <date>2007-06-26</date>
</data>

avec l'élément operation suivant :

<operation ref='t:data'
    whttp:location='temperature'
    whttp:method='POST'
    whttp:inputSerialization='multipart/form-data'/>

produiront une sérialisation du message comme suit :

Content-Type: multipart/form-data; boundary=AaB03x
Content-Length: xxx
        
--AaB03x
Content-Disposition: form-data; name="town"
Content-Type: application/xml

<town>
  <name>Fréjus</name>
  <country>France</country>
</town>
--AaB03x
Content-Disposition: form-data; name="date"
Content-Type: text/plain; charset=utf-8

2007-06-26
--AaB03x--

6.9 Indication du codage de contenu

6.9.1 Description

Chaque composant Binding Message Reference et Binding Fault PEUT indiquer quels codages de contenu, comme définis à la section 3.5 de [IETF RFC 2616], sont disponibles pour ce message particulier.

L'extension de liaison HTTP fournit un mécanisme pour indiquer une valeur par défaut au niveau des composants Binding et Binding Operation.

Si aucune valeur n'est définie, aucune revendication n'est faite.

6.9.2 Relation avec le modèle de composants WSDL

La spécification d'extension de liaison HTTP ajoute les propriétés suivantes au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

Ces propriétés ne sont pas pertinentes lorsque HTTP 1.0 est utilisé.

6.9.3 Représentation XML

<description>
  <binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
           whttp:contentEncodingDefault="xs:string"? >

    <fault ref="xs:QName"
           whttp:contentEncoding="xs:string"? >
    </fault>*

    <operation location="xs:anyURI"?
               whttp:contentEncodingDefault="xs:string"? >
      <input messageLabel="xs:NCName"? 
             whttp:contentEncoding="xs:string"? />

      <output messageLabel="xs:NCName"?
              whttp:contentEncoding="xs:string"? />

    </operation>
  </binding>
</description>

La représentation XML pour indiquer le codage de contenu est un item d'information d'attribut OPTIONNEL pour les items d'information d'élément input, output et fault avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de contentEncoding ;

  • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

  • un type de xs:string.

La représentation XML pour indiquer le codage de contenu par défaut est un item d'information d'attribut OPTIONNEL pour l'item d'information d'élément binding ou pour les items d'information d'élément operation sous-éléments de l'élément binding, avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de contentEncodingDefault ;

  • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

  • un type de xs:string.

6.9.4 Correspondance de la représentation XML aux propriétés de composant

Cf. le tableau 6-8.

Tableau 6-8. Correspondance de la représentation XML aux propriétés d'extension du composant Interface Message Reference
Propriété Valeur
{http content encoding default} du composant Binding La valeur réelle de l'item d'information d'attribut whttp:contentEncodingDefault de l'item d'information d'élément binding, si présent.
{http content encoding default} du composant Binding Operation La valeur réelle de l'item d'information d'attribut whttp:contentEncodingDefault de l'item d'information d'élément operation, si présent.
{http content encoding} du composant Binding Message Reference La valeur réelle de l'item d'information d'attribut whttp:contentEncoding de l'item d'information d'élément input ou output, si présent.
{http content encoding} du composant Binding Fault La valeur réelle de l'item d'information d'attribut whttp:contentEncoding de l'item d'information d'élément fault, si présent.

6.10 Indication de l'utilisation de cookies HTTP

6.10.1 Description

La propriété {http cookies} permet aux composants Binding d'indiquer que des cookies HTTP (définis dans [IETF RFC 2965]) sont utilisés par des opérations spécifiques de l'interface à laquelle s'applique cette liaison.

6.10.2 Relation avec le modèle de composants WSDL

La spécification d'extension de liaison HTTP ajoute la propriété suivante au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

  • {http cookies}, OBLIGATOIRE. Un type xs:boolean ; propriété ajoutée au composant Binding.

6.10.3 Représentation XML

<description>
  <binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
           whttp:cookies="xs:boolean"? >
  </binding>
</description>

La représentation XML pour indiquer l'utilisation de cookies HTTP est un item d'information d'attribut OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de cookies ;

  • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

  • un type de xs:boolean.

6.10.4 Correspondance de la représentation XML aux propriétés de composant

Cf. le tableau 6-9.

Tableau 6-9. Correspondance de la représentation XML aux propriétés d'extension du composant Binding
Propriété Valeur
{http cookies} La valeur réelle de l'item d'information d'attribut whttp:cookies ; sinon "false". Une valeur de "true" signifie que le service utilise des cookies et que le client DOIT les comprendre .

6.11 Indication d'authentification d'accès HTTP

6.11.1 Description

Chaque composant Endpoint PEUT indiquer l'utilisation d'un mécanisme d'authentification d'accès HTTP (défini dans [IETF RFC 2616]) pour l'extrémité décrite.

Cette spécification d'extension de liaison permet d'indiquer les schéma et domaine (realm) d'authentification.

6.11.2 Relation avec le modèle de composants WSDL

La spécification d'extension de liaison HTTP ajoute les propriétés suivantes au modèle de composants WSDL (défini dans [WSDL 2.0 Core Language]) :

  • {http authentication scheme}, OPTIONNELLE. Un type xs:token avec la valeur "basic" ou "digest" ; propriété ajoutée au composant Endpoint, correspondant au schéma d'authentification utilisé. Si présente, cette propriété indique le schéma d'authentification en vigueur : "basic" indique le schéma d'authentification d'accès Basic et "digest" le schéma d'authentification d'accès Digest, comme définis dans [IETF RFC 2617] ;

  • {http authentication realm}, OPTIONNELLE. Un type xs:string ; propriété ajoutée au composant Endpoint. Elle correspond au paramètre d'authentification de domaine défini dans [IETF RFC 2617]. Si la propriété {http authentication scheme} est présente, alors cette propriété DOIT l'être .

6.11.3 Représentation XML

<description>
  <service>
    <endpoint name="xs:NCName" binding="xs:QName" address="xs:anyURI"? >
              whttp:authenticationScheme="xs:token"? 
              whttp:authenticationRealm="xs:string"? />
    </endpoint>
  </service>
</description>

La représentation XML pour indiquer l'utilisation d'une authentification d'accès HTTP consiste en deux items d'information d'attribut OPTIONNELS avec les propriétés d'ensemble d'information suivantes :

  • un item d'information d'attribut authenticationScheme OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de authenticationScheme ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:token, où les valeurs d'atome permises sont "basic" et "digest".

  • un item d'information d'attribut authenticationRealm OPTIONNEL avec les propriétés d'ensemble d'information suivantes :

    • un nom local [local name] de authenticationRealm ;

    • un nom d'espace de noms [namespace name] de "http://www.w3.org/ns/wsdl/http" ;

    • un type de xs:string.

6.11.4 Correspondance de la représentation XML aux propriétés de composant

Cf. le tableau 6-10.

Tableau 6-10. Correspondance de la représentation XML aux propriétés d'extension du composant Endpoint
Propriété Valeur
{http authentication scheme} La valeur réelle de l'item d'information d'attribut whttp:authenticationScheme, si présent.
{http authentication realm} La valeur réelle de l'item d'information d'attribut whttp:authenticationRealm, si présent ; sinon, si l'item d'information d'attribut whttp:authenticationScheme est présent, c'est "" (la valeur vide).

6.12 Conformité

Un item d'information d'élément, dont le nom d'espace de noms est "http://www.w3.org/ns/wsdl" et dont la partie locale est description, est conforme à cette spécification d'extension de liaison si les items d'information d'élément et items d'information d'attribut, dont l'espace de noms est http://www.w3.org/ns/wsdl/http, sont conformes au schéma XML de ces éléments ou attributs, comme défini par cette spécification, et adhèrent en outre à toutes les contraintes contenues dans cette spécification.

7. Références

7.1 Références normatives

[ISO/IEC 14977:1996]
Extended BNF, IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical Commission), décembre 1996. Disponible à http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm.
[IETF RFC 2119]
Mots-clés à utiliser dans les RFC pour indiquer les degrés d'exigence, S. Bradner, auteur. Internet Engineering Task Force, mars 1997. Disponible à http://www.ietf.org/rfc/rfc2119.txt.
[IETF RFC 2388]
Valeurs de retour des formulaires : multipart/form-data, L. Masinter, auteur. Internet Engineering Task Force, août1998. Disponible à http://www.ietf.org/rfc/rfc2388.txt.
[IETF RFC 2616]
Protocole de transfert hypertexte HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, auteurs. Internet Engineering Task Force, juin 1999. Disponible à http://www.ietf.org/rfc/rfc2616.txt.
[IETF RFC 2617]
Authentification HTTP : authentification d'accès Basic et Digest, J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart, juin 1999. Disponible à http://www.ietf.org/rfc/rfc2616.txt.
[IETF RFC 2818]
HTTP sur TLS, E. Rescorla, auteur. Internet Engineering Task Force, mai 2000. Disponible à http://www.ietf.org/rfc/rfc2818.txt.
[IETF RFC 2965]
Mécanisme de gestion d'état HTTP, D. Kristol, L. Montulli, auteurs.Internet Engineering Task Force, octobre 2000. Disponible à http://www.ietf.org/rfc/rfc2965.txt.
[IETF RFC 3023]
Types de média XML, M. Murata, S. St. Laurent, D. Kohn, auteurs. Internet Engineering Task Force, janvier 2001. Disponible à http://www.ietf.org/rfc/rfc3023.txt.
[IETF RFC 3205]
Utiliser HTTP comme substrat, K. Moore, auteur. Internet Engineering Task Force, février 2002. Disponible à http://www.ietf.org/rfc/rfc3205.txt.
[IETF RFC 3986]
Identificateurs de ressource uniformes (URI) : syntaxe générique, T. Berners-Lee, R. Fielding, L. Masinter, auteurs. Internet Engineering Task Force, janvier 2005. Disponible à http://www.ietf.org/rfc/rfc3986.txt.
[IETF RFC 3987]
Identificateurs de ressource internationalisés (IRI), M. Duerst, M. Suignard, auteurs. Internet Engineering Task Force, janvier 2005. Disponible à http://www.ietf.org/rfc/rfc3987.txt.
[IETF RFC 4234]
BNF augmenté pour les spécifications de syntaxe : ABNF, D. Crocker, P. Overell, auteurs. Internet Engineering Task Force, octobre 2005. Disponible à http://www.ietf.org/rfc/rfc4234.txt.
[Web Architecture]
Architecture du Web, tome 1, I. Jacobs et N. Walsh, rédacteurs. World Wide Web Consortium, 15 décembre 2004. Cette version de la recommandation « Architecture du Web, tome 1 » est celle à http://www.w3.org/TR/2004/REC-webarch-20041215/. La dernière version de l'« Architecture du Web, tome 1 » est disponible à http://www.w3.org/TR/webarch/.
[Web Services Architecture]
Architecture des services web, David Booth, Hugo Haas, Francis McCabe, Eric Newcomer, Michael Champion, Chris Ferris, David Orchard, rédacteurs. World Wide Web Consortium, 11 février 2004. Cette version de la note de groupe « Architecture des services web » est celle à http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. La dernière version d'« Architecture des services web » est disponible à http://www.w3.org/TR/ws-arch/.
[WSDL 2.0 Core Language]
Langage de description de services web (WSDL) version 2.0 tome 1 — Cœur du langage, R. Chinnici, J-J. Moreau, A. Ryman, S. Weerawarana, rédacteurs. World Wide Web Consortium, 26 juin 2007. Cette version de la recommandation « WSDL version 2.0 tome 1 » est disponible à http://www.w3.org/TR/2007/REC-wsdl20-20070626. La dernière version de « WSDL version 2.0 tome 1 » est disponible à http://www.w3.org/TR/wsdl20.
[SOAP 1.2 Part 1: Messaging Framework (Second Edition)]
SOAP version 1.2 tome 1 : structure d'échange de messages (deuxième édition), M. Gudgin, et al., rédacteurs. World Wide Web Consortium, 24 juin 2003, révisé le 27 avril 2007. Cette version de la recommadation « SOAP version 1.2 tome 1 : structure d'échange de messages (deuxième édition) est disponible à http://www.w3.org/TR/2007/REC-soap12-part1-20070427/. La dernière version de « SOAP version 1.2 tome 1 » est disponible à http://www.w3.org/TR/soap12-part1/.
[SOAP 1.2 Part 2: Adjuncts (Second Edition)]
SOAP version 1.2 tome 2 : ajouts (deuxième édition), M. Gudgin, et al., rédacteurs. World Wide Web Consortium, 24 juin 2006, révisé le 27 avril 2007. Cette version de la recommandation « SOAP version 1.2 tome 2 : ajouts (deuxième édition) » est celle à http://www.w3.org/TR/2007/REC-soap12-part2-20070427/. La dernière version de « SOAP version 1.2 tome 2 » est disponible à http://www.w3.org/TR/soap12-part2/.
[XML 1.0]
Langage de balisage extensible (XML) 1.0 (quatrième édition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler et F. Yergeau, rédacteurs. World Wide Web Consortium, 10 février 1998, révisé le 16 août 2006. Cette version de la recommandation XML 1.0 est celle à http://www.w3.org/TR/2006/REC-xml-20060816/. La dernière version du « Langage de balisage extensible (XML) 1.0 est disponible à http://www.w3.org/TR/REC-xml.
[Canonical XML]
XML canonique, J. Boyer, auteur. World Wide Web Consortium, 15 mars 2001. Cette version de la recommandation « XML canonique » est celle à http://www.w3.org/TR/2001/REC-xml-c14n-20010315. La dernière version de « XML canonique » est disponible à http://www.w3.org/TR/xml-c14n.
[XML Information Set]
Ensemble d'information XML (deuxième édition), J. Cowan et R. Tobin, rédacteurs. World Wide Web Consortium, 24 octobre 2001, révisé le 4 février 2004. Cette version de la recommandation « Ensemble d'information XML » est celle à http://www.w3.org/TR/2004/REC-xml-infoset-20040204. La dernière version d'« Ensemble d'information XML est disponible à http://www.w3.org/TR/xml-infoset.
[XML Namespaces]
Espaces de noms dans XML (deuxième édition), T. Bray, D. Hollander, A. Layman et R. Tobin, rédacteurs. World Wide Web Consortium, 16 août 2006. Cette version de la recommandation des espaces de noms XML est celle à http://www.w3.org/TR/2006/REC-xml-names-20060816. La dernière version des espaces de noms en XML est disponible à http://www.w3.org/TR/REC-xml-names.
[XML Schema Structures]
XML Schema tome 1 : structures (deuxième édition), H. Thompson, D. Beech, M. Maloney et N. Mendelsohn, rédacteurs. World Wide Web Consortium, 2 mai 2001, révisé le 28 octobre 2004. Cette version de la recomandation « XML Schema tome 1 » est celle à http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. La dernière version de « XML Schema tome 1 » est disponible à http://www.w3.org/TR/xmlschema-1.
[XML Schema Datatypes]
XML Schema tome 2 : types de données (deuxième édition), P. Byron et A. Malhotra, rédacteurs. World Wide Web Consortium, 2 mai 2001, révisé le 28 octobre 2004. Cette version de la recommandation « XML Schema tome 2 » est celle à http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. La dernière version de « XML Schema tome 2 » est disponible à http://www.w3.org/TR/xmlschema-2.
[XForms 1.0]
XForms 1.0 (deuxième édition), J. Boyer, et al., rédacteurs. World Wide Web Consortium, 14 octobre 2003, révisé le 14 mars 2006. Cette version de la recommandation « XForms 1.0 » est celle à http://www.w3.org/TR/2006/REC-xforms-20060314/. La dernière version de XForms 1.0 est disponible à http://www.w3.org/TR/xforms/.

7.2 Références informatives

[WSA 1.0 Core]
Adressage des services web 1.0 — Cœur, M. Gudgin, M. Hadley, T. Rogers, rédacteurs. World Wide Web Consortium, 9 mai 2006. Cette version de la recommandation « Adressage des services web 1.0 — Cœur » est celle à http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. La dernière version de l'« Adressage des services web 1.0 — Cœur » est disponible à http://www.w3.org/TR/ws-addr-core.
[WSDL 2.0 Primer]
Langage de description de services web (WSDL) version 2.0 tome 0 — Introduction, D.Booth, C.K. Liu, rédacteurs. World Wide Web Consortium, 26 juin 2007. Cette version de la recommandation « WSDL version 2.0 tome 0 » est disponible à http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626. La dernière version de « WSDL version 2.0 tome 0 » est disponible à http://www.w3.org/TR/wsdl20-primer.
[WSDL 2.0 Additional MEPs]
Langage de description de services web (WSDL) version 2.0 — Autres modèles d'échange de messages, A. Lewis, Editors. World Wide Web Consortium, 26 juin 2007. Cette version de la note de groupe de travail « WSDL version 2.0 — Autres modèles d'échange de messages » est celle à http://www.w3.org/TR/2007/NOTE-wsdl20-additional-meps-20070626. La dernière version de « WSDL version 2.0 — Autres modèles d'échange de messages » est disponible à http://www.w3.org/TR/wsdl20-additional-meps.
[SOAP Message Transmission Optimization Mechanism]
Mécanisme d'optimisation de la transmission de message SOAP, N. Mendelsohn, M. Nottingham et H. Ruellan, rédacteurs. World Wide Web Consortium, recommandation du W3C, 25 janvier 2005. Cette version du « Mécanisme d'optimisation de la transmission de message SOAP » est celle à http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/. La dernière version du « Mécanisme d'optimisation de la transmission de message SOAP est disponible à http://www.w3.org/TR/soap12-mtom/.
[XPointer]
Cadre XPointer, Paul Grosso, Eve Maler, Jonathan Marsh, Norman Walsh, rédacteurs. World Wide Web Consortium, 25 mars 2003. Cette version de la recommandation proposée du « Cadre XPointer » est celle à http://www.w3.org/TR/2003/REC-xptr-framework-20030325/. La dernière version du « Cadre XPointer est disponible à http://www.w3.org/TR/xptr-framework/.

A. Remerciements (non normatif)

Ce document est le travail du groupe de travail Web Service Description du W3C.

Les membres du groupe de travail sont les suivants (au moment de la rédaction, et dans l'ordre alphabétique) : Charlton Barreto (Adobe Systems, Inc), Allen Brookes (Rogue Wave Softwave), Dave Chappell (Sonic Software), Helen Chen (Agfa-Gevaert N. V.), Roberto Chinnici (Sun Microsystems), Kendall Clark (University of Maryland), Glen Daniels (Sonic Software), Paul Downey (British Telecommunications), Youenn Fablet (Canon), Ram Jeyaraman (Microsoft), Tom Jordahl (Adobe Systems), Anish Karmarkar (Oracle Corporation), Jacek Kopecky (DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria), Amelia Lewis (TIBCO Software, Inc.), Philippe Le Hegaret (W3C), Michael Liddy (Education.au Ltd.), Kevin Canyang Liu (SAP AG), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems), Josephine Micallef (SAIC - Telcordia Technologies), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce), Jean-Jacques Moreau (Canon), David Orchard (BEA Systems, Inc.), Gilbert Pilz (BEA Systems, Inc.), Tony Rogers (Computer Associates), Arthur Ryman (IBM), Adi Sakala (IONA Technologies), Michael Shepherd (Xerox), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçınalp (SAP AG), Peter Zehler (Xerox).

Les membres précédents du groupe de travail étaient : Eran Chinthaka (WSO2), Mark Nottingham (BEA Systems, Inc.), Hugo Haas (W3C), Vivek Pandey (Sun Microsystems), Bijan Parsia (University of Maryland), Lily Liu (webMethods, Inc.), Don Wright (Lexmark), Joyce Yang (Oracle Corporation), Daniel Schutzer (Citigroup), Dave Solo (Citigroup), Stefano Pogliani (Sun Microsystems), William Stumbo (Xerox), Stephen White (SeeBeyond), Barbara Zengler (DaimlerChrysler Research and Technology), Tim Finin (University of Maryland), Laurent De Teneuille (L'Echangeur), Johan Pauhlsson (L'Echangeur), Mark Jones (AT&T), Steve Lind (AT&T), Sandra Swearingen (U.S. Department of Defense, U.S. Air Force), Philippe Le Hégaret (W3C), Jim Hendler (University of Maryland), Dietmar Gaertner (Software AG), Michael Champion (Software AG), Don Mullen (TIBCO Software, Inc.), Steve Graham (Global Grid Forum), Steve Tuecke (Global Grid Forum), Michael Mahan (Nokia), Bryan Thompson (Hicks & Associates), Ingo Melzer (DaimlerChrysler Research and Technology), Sandeep Kumar (Cisco Systems), Alan Davies (SeeBeyond), Jacek Kopecky (Systinet), Mike Ballantyne (Electronic Data Systems), Mike Davoren (W. W. Grainger), Dan Kulp (IONA Technologies), Mike McHugh (W. W. Grainger), Michael Mealling (Verisign), Waqar Sadiq (Electronic Data Systems), Yaron Goland (BEA Systems, Inc.), Ümit Yalçınalp (Oracle Corporation), Peter Madziak (Agfa-Gevaert N. V.), Jeffrey Schlimmer (Microsoft Corporation), Hao He (The Thomson Corporation), Erik Ackerman (Lexmark), Jerry Thrasher (Lexmark), Prasad Yendluri (webMethods, Inc.), William Vambenepe (Hewlett-Packard Company), David Booth (W3C), Sanjiva Weerawarana (IBM), Asir Vedamuthu (webMethods, Inc.), Igor Sedukhin (Computer Associates), Martin Gudgin (Microsoft Corporation), Rebecca Bergersen (IONA Technologies), Ugo Corda (SeeBeyond).

Nous remercions également les personnes qui ont contribué aux discussions sur www-ws-desc@w3.org.

B. Récapitulatif des composants (non normatif)

Le tableau B-1 liste tous les composants dans le modèle de composants abstrait des compléments WSDL 2.0, et toutes leurs propriétés.

Tableau B-1. Récapitulatif des composants et leurs propriétés des compléments WSDL 2.0
Composant Propriétés définies
Binding {http content encoding default}, {http cookies}, {http method default}, {http query parameter separator default}, {soap mep default}, {soap modules}, {soap underlying protocol}, {soap version}
Binding Fault {http content encoding}, {http error status code}, {http headers}, {soap fault code}, {soap fault subcodes}, {soap headers}, {soap modules}
Binding Fault Reference {soap modules}
Binding Message Reference {http content encoding}, {http headers}, {soap headers}, {soap modules}
Binding Operation {http content encoding default}, {http fault serialization}, {http input serialization}, {http location}, {http location ignore uncited}, {http method}, {http output serialization}, {http query parameter separator}, {soap action}, {soap mep}, {soap modules}
Endpoint {http authentication realm}, {http authentication scheme}
HTTP Header {name}, {parent}, {required}, {type definition}
Interface Operation {rpc signature}, {safe}
SOAP Header Block {element declaration}, {mustUnderstand}, {parent}, {required}
SOAP Module {parent}, {ref}, {required}
Propriété Là où définie
element declaration SOAP Header Block.{element declaration}
http authentication realm Endpoint.{http authentication realm}
http authentication scheme Endpoint.{http authentication scheme}
http content encoding Binding Fault.{http content encoding}, Binding Message Reference.{http content encoding}
http content encoding default Binding.{http content encoding default}, Binding Operation.{http content encoding default}
http cookies Binding.{http cookies}
http error status code Binding Fault.{http error status code}
http fault serialization Binding Operation.{http fault serialization}
http headers Binding Fault.{http headers}, Binding Message Reference.{http headers}
http input serialization Binding Operation.{http input serialization}
http location Binding Operation.{http location}
http location ignore uncited Binding Operation.{http location ignore uncited}
http method Binding Operation.{http method}
http method default Binding.{http method default}
http output serialization Binding Operation.{http output serialization}
http query parameter separator Binding Operation.{http query parameter separator}
http query parameter separator default Binding.{http query parameter separator default}
mustUnderstand SOAP Header Block.{mustUnderstand}
name HTTP Header.{name}
parent HTTP Header.{parent}, SOAP Header Block.{parent}, SOAP Module.{parent}
ref SOAP Module.{ref}
required HTTP Header.{required}, SOAP Header Block.{required}, SOAP Module.{required}
rpc signature Interface Operation.{rpc signature}
safe Interface Operation.{safe}
soap action Binding Operation.{soap action}
soap fault code Binding Fault.{soap fault code}
soap fault subcodes Binding Fault.{soap fault subcodes}
soap headers Binding Fault.{soap headers}, Binding Message Reference.{soap headers}
soap mep Binding Operation.{soap mep}
soap mep default Binding.{soap mep default}
soap modules Binding.{soap modules}, Binding Fault.{soap modules}, Binding Fault Reference.{soap modules}, Binding Message Reference.{soap modules}, Binding Operation.{soap modules}
soap underlying protocol Binding.{soap underlying protocol}
soap version Binding.{soap version}
type definition HTTP Header.{type definition}

C. Récapitulatif des assertions (non normatif)

Cette annexe reprend les assertions à propos des documents et composants WSDL 2.0 que le schéma de WSDL 2.0 ne fait pas valoir. À chaque assertion est affecté un identificateur que les processeurs WSDL 2.0 peuvent utiliser pour signaler des erreurs.

Tableau C-1. Récapitulatif des assertions à propos des documents WSDL 2.0
Identificateur Assertion
OperationSafety-2028 Un item d'information d'attribut safe OPTIONNEL avec les propriétés d'ensemble d'information suivantes :
WRPC-2050 En plus, chaque élément de numéro pair (0, 2, 4, ...) dans la liste DOIT être de type xs:QName et chaque élément de numéro impair (1, 3, 5, ...) dans la liste DOIT être du sous-type de xs:token décrit au paragraphe précédent.
Tableau C-2. Récapitulatif des assertions à propos des composants WSDL 2.0
Identificateur Assertion
FaultPropagationModification-2005 Par contre, les extensions et les extensions de liaison PEUVENT modifier ces règlements.
HTTPAccessAuthentication-2127 Si la propriété {http authentication scheme} est présente, alors cette propriété DOIT l'être.
HTTPBinding-2083 Lors de la formulation du message HTTP à transmettre, la méthode de la requête HTTP DOIT être sélectionnée d'après l'un des cas suivants…
HTTPBinding-2084 Lors de la formulation du message HTTP à transmettre, le codage de contenu d'un composant Binding Message Reference donné est déterminé comme suit…
HTTPBinding-2085 Lors de la formulation du message d'incident HTTP à transmettre, le codage de contenu d'un composant Binding Fault donné est déterminé comme suit…
HTTPBinding-2086 Lors de la formulation du message HTTP à transmettre, le contenu de la charge utile (c'est-à-dire le contenu du corps de message HTTP) DOIT être celui qui est défini par les composants Interface Message Reference ou Interface Fault correspondants, sérialisé comme indiqué par le format de sérialisation utilisé.
HTTPBinding-2087 Si la valeur est "#none", alors la charge utile DOIT être vide et la valeur de la propriété de sérialisation correspondante ({http input serialization} ou {http output serialization}) est ignorée.
HTTPBinding-2088 Si le composant Interface Message Reference ou le composant Interface Fault est déclaré en utilisant un système de typage non-XML (comme examiné dans [WSDL 2.0 Core Language], section Types), alors d'autres règles de liaison DOIVENT être définies dans une spécification d'extension pour indiquer comment associer ces composants dans l'enveloppe HTTP.
HTTPBinding-2089 Les règles de sérialisation des messages dont la propriété {message content model} est soit "#element" soit "#any", et les règles de sérialisation des messages d'incident sont les suivantes…
HTTPBindingFault-2105 La définition d'incident DEVRAIT correspondre à celle des codes d'erreur HTTP, comme définis à la section 8 de [IETF RFC 3205].
HTTPBindingFault-2106 Une valeur entière de cette propriété identifie l'erreur Status-Code, comme définie par [IETF RFC 2616], que le service utilisera au cas où l'incident est retourné.
HTTPBindingOperation-2093 Lors de la formulation de la requête HTTP, l'adresse IRI de la requête HTTP est une référence IRI absolue et c'est la valeur de la propriété {http location} du composant Binding Operation, résolue en utilisant la valeur de la propriété {address} du composant Endpoint (cf. la section 5 de [IETF RFC 3986]).
HTTPBindingOperation-2094 Le premier est transmis en utilisant une requête HTTP et le deuxième en utilisant la réponse HTTP correspondante.
HTTPBindingOperation-2095 Au cas où un seul message est envoyé, le corps de message de la réponse HTTP DOIT être vide.
HTTPBindingOperation-2098 Elle DOIT contenir une référence IRI et NE DOIT PAS inclure de composant identificateur de fragment.
HTTPBindingOperation-2100 La valeur du format de sérialisation utilisé pour un message est un type de média qui DOIT être couvert par cette gamme.
HTTPBindingOperation-2101 On NE DEVRAIT PAS utiliser de caractères génériques (wildcards) (par exemple, "application/*") dans cet item d'information d'attribut car ils peuvent entraîner des problèmes d'interopérabilité.
HTTPCookies-2126 Une valeur de "true" signifie que le service s'appuie sur des cookies et que le client DOIT les comprendre.
HTTPHeader-2090 Si la propriété {http headers} comme définie à la section 6.6 Déclaration des en-têtes HTTP existe et n'est pas vide dans un composant Binding Message Reference ou Binding Fault, les en-têtes HTTP conformes à chaque composant HTTP Header contenu dans cette propriété {http headers} PEUVENT être sérialisées comme suit…
HTTPHeader-2091 La liaison HTTP NE DOIT PAS établir de champ d'en-tête HTTP correspondant à la valeur de la propriété {name} déjà fixée par un autre mécanisme, tel que la pile HTTP ou une autre caractéristique.
HTTPHeader-2092 Si la valeur de la propriété {required} d'un composant HTTP Header est "true", l'inclusion de ce champ d'en-tête HTTP est OBLIGATOIRE.
HTTPHeader-2102 La propriété {http headers} d'un composant Binding Message Reference ou Binding Fault NE DOIT PAS contenir plusieurs composants HTTP Header avec la même propriété {name}.
HTTPHeader-2103 Ce type DOIT être un type simple.
HTTPHeader-2104 Si la valeur est "true", alors le champ d'en-tête HTTP DOIT être inclus dans le message.
HTTPQueryString-2115 Les données d'instance NE DOIVENT PAS contenir d'éléments avec un attribut xs:nil dont la valeur est "true".
HTTPQueryString-2116 Lorsqu'on sérialise une requête HTTP qui n'admet pas de corps de message HTTP et que la propriété {http location ignore uncited} est "true", tout élément non cité dans la propriété {http location} DOIT être défini dans le schéma comme nillable, ou avoir une valeur default, ou apparaître pas moins qu'indiqué par la valeur de minOccurs. La déclaration d'élément NE DEVRAIT PAS combiner une valeur par défaut avec nillable.
HTTPSerialization-2099 La valeur des propriétés {http input serialization}, {http output serialization} et {http fault serialization} est similaire à la valeur permise pour l'en-tête HTTP Accept, définie par la spécification HTTP 1.1 (cf. la section 14.1 dans [IETF RFC 2616]), et elle DOIT suivre les règles de production définies dans cette section sauf pour ce qui suit…
HTTPSerialization-2106 La propriété {http location} DOIT se conformer à la grammaire EBNF [ISO/IEC 14977:1996] suivante, qui représente les modèles pour construire l'adresse IRI de requête…
HTTPSerialization-2107 Si la propriété {style} du composant Interface Operation lié a une valeur de "http://www.w3.org/ns/wsdl/style/iri", comme défini à la section 4.2 Style IRI, et si la propriété {http location} du composant Binding Operation est présente, la valeur de la propriété {http location} du composant est utilisée comme gabarit (template).
HTTPSerialization-2108 L'adresse IRI obtenue DOIT être associée à une adresse URI à utiliser dans la requête HTTP, selon la section 3.1 Correspondance des adresse IRI aux adresses URI de la spécification IRI [IETF RFC 3987].
HTTPSerialization-2109 Le nom local dans un modèle (template) DEVRAIT correspondre à au moins un élément des données d'instance du message d'entrée.
HTTPSerialization-2111 Si ce format est utilisé, alors la propriété {style} du composant Interface Operation lié DOIT contenir une valeur de "http://www.w3.org/ns/wsdl/style/iri", comme définie à la section 4.2 Style IRI, c'est-à-dire que ce format de sérialisation peut seulement être utilisé pour sérialiser la requête HTTP correspondant au message initial d'une opération d'interface.
HTTPSerialization-2112 Pour la liaison HTTP définie dans cette section (6. Extension de liaison HTTP WSDL), on PEUT utiliser "application/x-www-form-urlencoded" comme format de sérialisation pour un message d'entrée (requête HTTP) ; mais on NE DOIT PAS l'utiliser comme format de sérialisation pour un message de sortie ou d'incident (réponse HTTP).
HTTPSerialization-2113 >Si les éléments des données d'instance ne sont pas tous cités dans la propriété {http location}, ou si la propriété n'est pas présente sur le composant Binding Operation, alors des règles de sérialisation supplémentaires s'appliquent.
HTTPSerialization-2114 Pour les éléments des données d'instance non cités dans la propriété {http location}, une chaîne d'interrogation se construit comme suit…
HTTPSerialization-2117 Si la méthode de requête HTTP utilisée n'admet pas de corps de message HTTP (par exemple, les méthodes "GET" et "DELETE"), et si la valeur de la propriété {http location ignore uncited} est "false", alors les règles suivantes s'appliquent…
HTTPSerialization-2118 Si la méthode de requête HTTP admet un corps de message HTTP (par exemple, les méthodes "POST" et "PUT"), alors les règles suivantes s'appliquent…
HTTPSerialization-2119 Le champ d'en-tête HTTP Content-Type doit avoir la valeur application/x-www-form-urlencoded.
HTTPSerialization-2120 L'en-tête HTTP Content-Type DOIT avoir la valeur application/xml [IETF RFC 3023], ou un type de média compatible avec application/xml, comme défini à la section 6.4.3.1 Règles de sérialisation des messages XML.
HTTPSerialization-2121 on ne peut utiliser ce format de sérialisation que pour sérialiser la requête HTTP correspondant au message initial d'une opération d'interface.
HTTPSerialization-2122 Spécifiquement, pour la liaison HTTP définie dans cette section (6. Extension de liaison HTTP WSDL), on PEUT utiliser "multipart/form-data" comme format de sérialisation pour un message d'entrée (requête HTTP) ; mais on NE DOIT PAS l'utiliser comme format de sérialisation pour un message de sortie ou d'incident (réponse HTTP).
HTTPSerialization-2123 L'en-tête Content-Disposition DOIT avoir la valeur form-data, et son paramètre name être le nom local de l'élément.
HTTPSerialization-2124 L'en-tête Content-Type DOIT avoir pour valeur…
HTTPSerialization-2125 Les données d'instance NE DOIVENT PAS contenir d'éléments avec un attribut xs:nil dont la valeur est "true".
IRIStyle-2051 Lorsqu'on utilise ce style, la valeur de la propriété {message content model} du composant Interface Message Reference correspondant au message initial du modèle d'échange de messages DOIT être "#element".
IRIStyle-2052 La séquence ne DOIT contenir que des éléments.
IRIStyle-2053 La séquence ne DOIT contenir que des sous-éléments d'élément local.
IRIStyle-2054 La partie locale (localPart) du nom qualifié QName de l'élément DOIT être la même que celle de la propriété {name} du composant Interface Operation.
IRIStyle-2055 Le type complexe qui définit le corps de l'élément ou ses sous-éléments NE DOIT PAS contenir d'attributs.
IRIStyle-2056 Les sous-éléments de la séquence DOIVENT dériver du type xs:simpleType, et NE DOIVENT PAS être ou dériver d'un type xs:QName, xs:NOTATION, xs:hexBinary ou xs:base64Binary.
InOnlyComposition-2012 Le modèle d'échange de message in-only comprend un seul message exactement, comme suit…
InOutComposition-2015 Le modèle d'échange de messages in-out comprend deux messages exactement, en ordre, comme suit…
InterfaceOperation-2096 202 lorsque le modèle d'échange de messages est "http://www.w3.org/ns/wsdl/in-only"
InterfaceOperation-2097 204 lorsque le modèle d'échange de messages est "http://www.w3.org/ns/wsdl/robust-in-only"
MultipartStyle-2057 Lorsqu'on utilise ce style, la valeur de la propriété {message content model} du composant Interface Message Reference correspondant au message initial du modèle d'échange de messages DOIT être "#element".
MultipartStyle-2058 La séquence ne DOIT contenir que des éléments.
MultipartStyle-2059 La séquence ne DOIT contenir que des sous-éléments d'élément local.
MultipartStyle-2060 Les attributs minOccurs et maxOccurs de ces sous-éléments DOIVENT avoir une valeur de "1".
MultipartStyle-2061 La partie locale (localPart) du nom qualifié QName de l'élément DOIT être la même que la propriété {name} du composant Interface Operation.
MultipartStyle-2062 Le type complexe qui définit le corps de l'élément ou ses sous-éléments NE DOIT PAS contenir d'attributs.
MultipartStyle-2063 La séquence NE DOIT PAS contenir plusieurs sous-éléments déclarés avec le même nom local.
OperationSafety-2027 Toutefois, une opération DEVRAIT être marquée comme sûre si elle satisfait aux critères d'interaction sûre définis à la section 3.4 dans [Web Architecture].
RPCStyle-2029 Si un composant Interface Operation utilise le style RPC, alors sa propriété {message exchange pattern} DOIT avoir pour valeur soit "http://www.w3.org/ns/wsdl/in-only", soit "http://www.w3.org/ns/wsdl/in-out".
RPCStyle-2030 La valeur de la propriété {message content model} des composants Interface Message Reference de la propriété {interface message references} DOIT être "#element".
RPCStyle-2031 Le modèle de contenu des déclarations d'élément {element declaration} des élément d'entrée et de sortie DOIT être défini en utilisant un type complexe qui contient une séquence du schéma XML.
RPCStyle-2032 La séquence d'entrée ne DOIT contenir que des éléments et des éléments génériques.
RPCStyle-2033 La séquence d'entrée NE DOIT PAS contenir plus d'un seul élément générique.
RPCStyle-2034 L'élément générique, si présent, DOIT apparaître après tous les éléments.
RPCStyle-2035 La séquence de sortie ne DOIT contenir que des éléments.
RPCStyle-2036 Les séquences d'entrée et de sortie ne DOIVENT contenir que des sous-éléments d'élément local.
RPCStyle-2037 Le nom local du nom qualifié QName de l'élément input DOIT être le même que celui du composant Interface Operation.
RPCStyle-2038 Les éléments input et output DOIVENT se trouver dans le même espace de noms.
RPCStyle-2039 Le type complexe qui définit le corps d'un élément input ou output NE DOIT PAS contenir d'attributs locaux.
RPCStyle-2040 Si des éléments avec le même nom qualifié apparaissent comme sous-éléments à la fois des éléments input et output, alors ils DOIVENT tous être déclarés en utilisant le même type de nom.
RPCStyle-2041 La séquence input ou output NE DOIT PAS contenir plusieurs sous-éléments déclarés avec le même nom.
RobustInOnlyComposition-2013 Le modèle d'échange de message robust-in-only comprend un seul message exactement, comme suit…
SOAPAction-2075 Un type xs:anyURI, qui est une adresse IRI absolue comme définie par [IETF RFC 3987] ; propriété ajoutée au composant Binding Operation.
SOAPBinding-2065 Lors de la formulation de l'enveloppe SOAP à transmettre, le contenu de la charge utile (c'est-à-dire le contenu de l'item d'information d'élément SOAP Body de l'enveloppe SOAP) DOIT être ce qui est défini par le composant Interface Message Reference correspondant.
SOAPBinding-2068 Si le composant Interface Message Reference est déclaré avec un système de typage non-XML (comme examiné à la section Types dans WSDL 2.0 Core Language]), alors des règles de liaison supplémentaires DOIVENT être définies afin d'indiquer comment associer ces composants dans l'enveloppe SOAP.
SOAPBinding-2069 Chaque liaison SOAP DOIT indiquer quelle version de SOAP est utilisée pour les opérations de l'interface à laquelle cette liaison s'applique.
SOAPBinding-2070 Chaque liaison SOAP DOIT indiquer quel protocole sous-jacent est utilisé.
SOAPBindingFault-2071 Pour chaque composant Interface Fault contenu dans un composant Interface, une correspondance à un composant SOAP Fault DOIT être décrite.
SOAPBindingFault-2072 lorsque la valeur de la propriété {soap version} est "1.2", les noms qualifiés QName permis DOIVENT être ceux définis à la section 5.4.6 dans [SOAP 1.2 Part 1: Messaging Framework (Second Edition)],
SOAPHTTPProperties-2064 Ces propriétés NE DOIVENT PAS être utilisées sauf si le protocole sous-jacent est HTTP.
SOAPHTTPSelection-2082 Cette règle de liaison par défaut est applicable lorsque la valeur de la propriété {soap underlying protocol} du composant Binding est "http://www.w3.org/2003/05/soap/bindings/HTTP/". Si le modèle d'échange de messages SOAP sélectionné, comme indiqué ci-dessus, a la valeur "http://www.w3.org/2003/05/soap/mep/request-response/", alors la méthode HTTP utilisée est "POST". Si le modèle d'échange de messages SOAP sélectionné a la valeur "http://www.w3.org/2003/05/soap/mep/soap-response/", alors la méthode HTTP utilisée est "GET".
SOAPHeaderBlock-2077 Lorsque sa valeur est "true", le bloc d'en-tête SOAP DOIT être accompagné d'un item d'information d'attribut mustUnderstand SOAP avec une valeur de "true" ; dans ce cas, la déclaration d'élément XML référencée par la propriété {element declaration} DOIT admettre cet item d'information d'attribut mustUnderstand SOAP.
SOAPHeaderBlock-2078 Si la valeur est "true", le bloc d'en-tête SOAP DOIT être inclus dans le message.
SOAPHeaderBlock-2079 La valeur de l'item d'information d'attribut element DOIT se résoudre en une déclaration d'élément globale de la propriété {element declarations} du composant Description.
SOAPMEP-2074 Un type xs:anyURI, qui est une adresse IRI absolue comme définie par [IETF RFC 3987] ; propriété ajoutée au composant Binding Operation.
SOAPMEPDefault-2073 Un type xs:anyURI, qui est une adresse IRI absolue comme définie par [IETF RFC 3987] ; propriété ajoutée au composant Binding.
SOAPMEPSelection-2080 Pour un composant Interface Operation donné, s'il existe un composant Binding Operation dont la propriété {interface operation} correspond au correspond au composant en question et que sa propriété {soap mep} a une valeur, alors le modèle d'échange de messages SOAP est la valeur de la propriété {soap mep}.Sinon le modèle d'échange de messages SOAP est la valeur de la propriété {soap mep default} du composant Binding, le cas échéant. Sinon, la propriété {message exchange pattern} du composant Interface Operation DOIT avoir la valeur "http://www.w3.org/ns/wsdl/in-out", et le modèle d'échange de messages SOAP est l'adresse URI "http://www.w3.org/2003/05/soap/mep/request-response/" identifiant le modèle d'échange de messages Request-Response SOAP comme défini dans [SOAP 1.2 Part 2: Adjuncts (Second Edition)].
SOAPModule-2076 Un type xs:anyURI, qui est une adresse IRI absolue comme définie par [IETF RFC 3987].
WRPC-2042 OPTIONNELLE, mais DOIT être présente lorsque c'est le style RPC.
WRPC-2043 Les valeurs du deuxième composant DOIVENT être choisies parmi les quatre suivantes : "#in", "#out", "#inout" et "#return".
WRPC-2044 La valeur du premier composant de chaque couple (qt) DOIT être unique dans la liste.
WRPC-2045 Pour chaque sous-élément des messages d'entrée et de sortie de l'opération, un couple (qt), dont le premier composant q est égal au nom qualifié de cet élément, DOIT être présent dans la liste, à la restriction que les éléments apparaissant avec une cardinalité supérieure à un DOIVENT être traités comme un seul élément.
WRPC-2046 Pour chaque couple (q, #in), il DOIT y avoir un sous-élément de l'élément input avec le nom q. Il NE DOIT PAS y avoir de sous-élément de l'élément output avec le nom q.
WRPC-2047 Pour chaque couple (q, #out), il DOIT y avoir un sous-élément de l'élément output avec le nom q. Il NE DOIT PAS y avoir de sous-élément de l'élément input avec le nom q.
WRPC-2048 Pour chaque couple (q, #inout), il DOIT y avoir un sous-élément de l'élément input avec le nom q. Il NE DOIT PAS y avoir de sous-élément de l'élément output avec le nom q.
WRPC-2049 Pour chaque couple (q, #return), il DOIT y avoir un sous-élément de l'élément output avec le nom q. Il NE DOIT PAS y avoir de sous-élément de l'élément input avec le nom q.
Tableau C-3. Récapitulatif des assertions à propos des messages
Identificateur Assertion
HTTPSerialization-2110 Les éléments cités (c'est-à-dire les éléments référencés dans les modèles) NE DOIVENT PAS porter d'attribut xs:nil dont la valeur est "true" ;
SOAP12Binding-SOAPDetail-2081 Le cas échéant, la valeur de l'élément Detail SOAP DOIT être l'item d'information d'élément identifié par la propriété {element declaration} du composant Interface Fault.
SOAPBinding-2066 Si la valeur est "#none", alors la charge utile DOIT être vide.
SOAPBinding-2067 Si la valeur est "#element", alors la charge utile DOIT être l'item d'information d'élément identifié par la propriété {element declaration} du composant Interface Message Reference.
Tableau C-4. Récapitulatif des assertions à propos des échanges de messages
Identificateur Assertion
FaultDelivery-2008 Le message d'incident DOIT être livré au même nœud cible que le message qu'il remplace, sauf indication contraire par une extension ou une extension de liaison. S'il n'y a pas de chemin vers ce nœud, l'incident DOIT être jeté.
FaultDelivery-2010 Le message d'incident DOIT être livré à l'émetteur du message de déclenchement, sauf indication contraire par une extension ou une extension de liaison. Tout nœud PEUT propager un message d'incident, et il NE DOIT PAS le faire plus d'une fois pour chaque message de déclenchement. S'il n'y a pas de chemin vers l'émetteur, l'incident DOIT être jeté.
FaultPropagation-2003 Les nœuds qui génèrent les incidents DOIVENT essayer de propager les incidents conformément au règlement en vigueur, mais il est entendu que la livraison d'un message de réseau est au mieux, elle n'est pas garantie.
FaultPropagation-2004 Lorsqu'un incident est généré, le nœud générateur DOIT essayer de propager l'incident, et il DOIT le faire dans la direction et au destinataire indiqués par le règlement.
FaultReplacesMessage-2007 Lorsque la règle de propagation Fault Replaces Message est en vigueur, tout message après le premier dans le modèle PEUT être remplacé par un message d'incident, lequel DOIT avoir une direction identique.
InOnlyFaults-2013 Le modèle d'échange de messages in-only utilise la règle 2.2.3 Règle de propagation No Faults.
InOutFaults-2016 Le modèle d'échange de messages in-out utilise la règle 2.2.1 Règle de propagation Fault Replaces Message.
MEPDescriptiveness-2002 par un accord préalable, un autre nœud ou le service PEUVENT envoyer des messages (l'un à l'autre ou à d'autres nœuds) qui ne sont pas décrits par le modèle.
MEPTermination-2006 La génération d'un incident, indépendamment du règlement, termine l'échange.
MessageTriggersFault-2009 Lorsque la règle de propagation Message Triggers Fault est en vigueur, tout message y compris le premier dans le modèle PEUT déclencher un message d'incident, lequel DOIT avoir une direction opposée.
NoFaults-2011 Lorsque la règle de propagation No Faults est en vigueur, les incidents NE DOIVENT PAS être propagés.
NodeIdentity-2001 Un nœud PEUT être accessible au travers de plus d'une adresse physique ou d'un transport.
RobustInOnlyFaults-2014 Le modèle d'échange de messages robust-in-only utilise la règle 2.2.2 Règle de propagation Message Triggers Fault.