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 no