Lisez-moi S.V.P. 

W3C

Langage de description de services web (WSDL) version 2.0 tome 1 — Cœur du langage

Recommandation du W3C du 26 juin 2007

Cette version :
http://www.w3.org/TR/2007/REC-wsdl20-20070626
Dernière version :
http://www.w3.org/TR/wsdl20
Version précédente :
http://www.w3.org/TR/2007/PR-wsdl20-20070523
Rédacteurs :
Roberto Chinnici, Sun Microsystems
Jean-Jacques Moreau, Canon
Arthur Ryman, IBM
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 : XHTML avec notation Z, PDF, PostScript, XML et texte ordinaire.

Cf. également d'éventuelles traductions.


Résumé

Ce document décrit le langage de description de services web version 2.0 (WSDL 2.0), un langage XML pour décrire des services web. Cette spécification définit le noyau du langage que l'on peut utiliser pour décrire des services web selon un modèle abstrait de ce qu'offre le service. Elle définit également les critères de conformité des documents dans ce langage.

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 1 — Cœur du langage 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) 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 du service tels que « comment » et « où » cette fonctionnalité est offerte.

Cette spécification définit un langage pour décrire la fonctionnalité abstraite d'un service ainsi qu'un cadre d'applications (framework) pour décrire les détails concrets d'une description de service. Elle définit également les critères de conformité des documents dans ce langage.

La spécification complémentaire Langage de description de services web (WSDL) version 2.0 tome 2 — Compléments [WSDL 2.0 Adjuncts] décrit des extensions pour les modèles d'échanges de messages, la sécurité des opérations, les styles d'opérations et des extensions de liaisons (pour les protocoles SOAP [SOAP 1.2 Part 1: Messaging Framework (Second Edition)] et HTTP [IETF RFC 2616]).

1.1 Description de service

WSDL 2.0 décrit un service web en deux étapes fondamentales : l'une abstraite et l'autre concrète. Lors de chaque étape, la description utilise plusieurs concepts (constructs) afin de promouvoir la réutilisabilité de la description et de séparer des préoccupations de conception indépendantes.

Au niveau abstrait, WSDL 2.0 décrit un service web en fonction des messages que celui-ci envoie et reçoit ; les messages sont décrits indépendamment d'un format de transmission (wire format) particulier en utilisant un système de typage (type system), typiquement XML Schema.

Une opération (operation) associe un modèle d'échange de messages à un ou plusieurs messages. Un modèle d'échange de messages (message exchange pattern) identifie la séquence et la cardinalité des messages envoyés ou reçus ainsi que leurs destinataires ou leurs émetteurs logiques. Une interface (interface) regroupe les opérations sans engagement vis-à-vis d'un format de transport ou de transmission.

Au niveau concret, une liaison (binding) définit les détails des formats de transport et de transmission d'une ou plusieurs interfaces. Une extrémité (endpoint) associe une adresse de réseau à une liaison. Enfin, un service (service) regroupe les extrémités qui mettent en œuvre une interface commune.

1.2 Signification d'une description de service

Une description de service WSDL 2.0 indique comment des clients potentiels sont censés interagir avec le service décrit. Elle représente l'assertion selon laquelle le service décrit met en œuvre et se conforme entièrement à ce que le document WSDL 2.0 décrit. Par exemple, ainsi que cela est approfondi dans la section 6.1.1 Extensions obligatoires, si le document WSDL 2.0 indique une extension optionnelle particulière, la fonctionnalité impliquée par cette extension n'est optionnelle que pour le client. Elle doit être gérée par le service web.

Une interface WSDL 2.0 décrit des interactions potentielles avec un service web, non des interactions nécessaires. La déclaration d'une opération dans une interface WSDL 2.0 n'est pas une assertion selon laquelle l'interaction décrite par l'opération doit se produire. C'est plutôt : si une telle interaction est amorcée (d'une certaine manière), alors l'opération déclarée décrit la façon dont cette interaction est censée avoir lieu.

1.3 Conformité des documents

Un item d'information d'élément (element information item), comme défini dans l'ensemble d'information XML [XML Information Set]), dont le nom d'espace de noms est "http://www.w3.org/ns/wsdl" et la partie locale (local part) est description, est conforme à cette spécification s'il est valide selon le schéma XML de cet élément tel que défini par cette spécification (c'est-à-dire http://www.w3.org/2007/06/wsdl/wsdl20.xsd) et, en outre, adhère à toutes les contraintes décrites dans cette spécification et se conforme aux définitions des extensions qui y sont contenues. Un tel item d'information d'élément constitue un document WSDL 2.0 (WSDL 2.0 document).

La définition du langage WSDL 2.0 s'appuie sur l'ensemble d'information XML [XML Information Set], mais elle impose aussi beaucoup de contraintes sémantiques pour la conformité de la structure, sur et au-dessus d'elle, à cet ensemble d'information XML. Pour décrire précisément ces contraintes, et afin d'aider à définir exactement la signification de chaque document WSDL 2.0, la spécification WSDL 2.0 définit un modèle de composants (Component Model), cf. la section 2. Modèle de composants, en couche supplémentaire d'abstraction au-dessus de l'ensemble d'information XML. Les contraintes et la signification sont définies en fonction de ce modèle de composants, et la définition de chaque composant inclut une correspondance (mapping) indiquant comment les valeurs du modèle de composants sont dérivées des éléments (items) correspondants de l'ensemble d'information XML.

Un document XML 1.0, qui est valide par rapport au schéma XML de WSDL 2.0 et correspond à un modèle de composant WSDL 2.0 valide, est conforme à la spécification WSDL 2.0.

1.4 Conventions d'écriture

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.

1.4.1 Mots-clés du RFC 2119

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 s'interpréter selon le RFC 2119 [IETF RFC 2119].

1.4.2 Espaces de noms du RFC 3986

Les noms d'espaces 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].

1.4.3 Type anyURI de XML Schema

Cette spécification utilise le type xs:anyURI de XML Schema, cf. [XML Schema: Datatypes]. Il est défini de façon à ce que les valeurs xs:anyURI soient essentiellement des adresses IRI, cf. [IETF RFC 3987]. La conversion des valeurs xs:anyURI en adresses URI réelles intervient au travers d'une procédure d'échappement (escaping procedure) définie dans [XLink 1.0], laquelle est essentiellement identique à celle décrite dans la section 3.1 de [IETF RFC 3987]).

Pour l'interopérabilité, les créateurs (authors) WSDL sont conviés à ne pas utiliser les caractères US-ASCII suivants : « < », « > », « " », espace, « { », « } », « | », « \ », « ^ » et « ` », admis dans les valeurs de type xs:anyURI mais pas dans les adresses IRI.

1.4.4 Préfixes et espaces de noms utilisés dans cette spécification

Cette spécification utilise tout du long des préfixes d'espaces de noms prédéfinis ; les voici dans la liste suivante. 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" Défini par cette spécification.
wsdli "http://www.w3.org/ns/wsdl-instance" Défini par cette spécification, 7.1 Item d'information d'attribut wsdli:wsdlLocation.
wsdlx "http://www.w3.org/ns/wsdl-extensions" Défini par cette spécification, 3.3 Description des messages en rapport avec des services et des extrémités.
wrpc "http://www.w3.org/ns/wsdl/rpc" Défini par WSDL 2.0 : compléments, [WSDL 2.0 Adjuncts].
wsoap "http://www.w3.org/ns/wsdl/soap" Défini par WSDL 2.0 : compléments, [WSDL 2.0 Adjuncts].
whttp "http://www.w3.org/ns/wsdl/http" Défini par WSDL 2.0 : compléments, [WSDL 2.0 Adjuncts].
xs "http://www.w3.org/2001/XMLSchema" Défini dans la spécification XML Schema du W3C, [XML Schema : Structures], [XML Schema : Datatypes].
xsi "http://www.w3.org/2001/XMLSchema-instance" Défini dans la spécification XML Schema du W3C, [XML Schema : Structures], [XML Schema : Datatypes].

1.4.5 Termes utilisés dans cette spécification

Cette section décrit les termes et concepts introduits dans le tome 1 de la spécification WSDL version 2.0 (ce document).

Valeur réelle

Comme dans la spécification [XML Schema : Structures], l'expression « valeur réelle » (actual value) se rapporte au membre de l'espace de valeurs de la définition de type simple associée à un item d'information d'attribut qui correspond à sa valeur normalisée. Ce sera souvent une chaîne mais ça peut être un entier, un booléen, une adresse IRI, etc.

Schéma incorporé

Un schéma XML défini dans l'item d'information d'élément wsdl:types d'une description WSDL 2.0. Par exemple, un schéma XML défini dans l'item d'information d'élément xs:schema, cf. la section 3.1.2 Incorporation d'un schéma XML.

1.4.6 Propriétés de l'ensemble d'information XML

Cette spécification se réfère à des propriétés dans l'ensemble d'information XML [XML Information Set]. Ces propriétés sont signalées par des crochets, ainsi [children] et [attributes].

1.4.7 Propriétés du modèle de composants WSDL 2.0

Cette spécification définit et se réfère à des propriétés du modèle de composants WSDL 2.0, cf. la section 2. Modèle de composants. Ces propriétés sont signalées par des accolades, ainsi {name}, {interfaces}.

Cette spécification obéit à une convention d'écriture cohérente pour les propriétés du modèle de composants qui se rapportent aux composants. Si une propriété se rapporte à un composant obligatoire ou optionnel, le nom de propriété est le même que celui du composant. Si une propriété se rapporte à un ensemble de composants, le nom de propriété prend alors la forme du pluriel du nom de composant.

1.4.8 Notation Z

La notation Z [Z notation Reference Manual] a été utilisée pour le développement de cette spécification. La notation Z est un langage de définition formel fondé sur une notation mathématique standard. La notation Z de cette spécification a été contrôlée à l'aide du vérificateur de saisie (type-checker) Fuzz 2000 [Fuzz 2000].

La notation Z n'étant pas très connue, elle n'est pas incluse dans la version normative de cette spécification. Par contre, la notation Z est incluse dans une version non normative, où on peut la cacher ou la faire apparaître dynamiquement. Les navigateurs affichent correctement les caractères Unicode mathématiques, à condition que les fontes (fonts) nécessaires soient installées. Les fontes mathématiques pour Mozilla Firefox sont téléchargeables sur le site web de Mozilla.

La notation Z a été utilisée pour améliorer la qualité du texte normatif définissant le modèle de composants et pour s'assurer que la suite de tests couvrait toutes les règles importantes impliquées par le modèle de composants. Par contre, la notation Z n'étant pas normative, tout conflit intervenant entre elle et le texte normatif sera considéré comme une erreur de la notation Z. Les lecteurs et les développeurs (implementers) peuvent néanmoins trouver la notation Z utile lorsque le texte normatif n'est pas clair.

La syntaxe de la notation Z présente deux aspects contredisant les conventions d'écriture décrites dans les sections précédentes. Dans la notation Z, les crochets servent à introduire des ensembles de base, par exemple [ID], en contradiction de leur utilisation pour signaler les propriétés de l'ensemble d'information XML, cf. la section 1.4.6 Propriétés de l'ensemble d'information XML. Dans la notation Z encore, les accolades servent à indiquer un ensemble et son contenu, par exemple {1, 2, 3}, en contradiction de leur utilisation pour signaler les propriétés du modèle de composants de WSDL 2.0, cf. la section 1.4.7 Propriétés du modèle de composants WSDL 2.0. Quoi qu'il en soit, la signification attendue des crochets et des accolades devrait être claire dans le contexte, et ces conflits d'écriture ne devraient pas entraîner de confusion.

1.4.9 Pseudo-schémas BNF

Des pseudo-schémas sont fournis pour chaque composant en préalable de leur description. Ils utilisent des conventions de type BNF pour les attributs et les éléments : un caractère « ? » indique une nature optionnelle (c'est-à-dire zéro ou une apparition), un caractère « * » indique zéro ou plus apparitions, le caractère « + » indique une ou plusieurs apparitions, les caractères « [ » et « ] » servent à former des groupes, et le caractère « | » représente un choix. Les attributs reçoivent conventionnellement une valeur qui correspond à leur type, tel que défini dans le schéma normatif. Les éléments à contenu simple reçoivent conventionnellement une valeur qui correspond au type de leur contenu, tel que défini dans le schéma normatif. Les pseudo-schémas ne contiennent pas de points d'extension pour la concision.

<!-- exemple de pseudo-schéma -->
<élément_défini
      attribut_obligatoire_de_type_string="xs:string"
      attribut_optionnel_de_type_int="xs:int"? >
  <élément_obligatoire />
  <élément_optionnel />?
  <un_ou_plusieurs_de_ces_éléments />+
  [ <choix_1 /> | <choix_2 /> ]*
</élément_défini>

1.4.10 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 E. Récapitulatif des assertions.

2. Modèle de composants

Cette section décrit le modèle conceptuel de WSDL 2.0 comme un ensemble de composants avec des propriétés, qui décrit collectivement un service web. Ce modèle est appelé le modèle de composants (component model) de WSDL 2.0. Un modèle de composants WSDL 2.0 valide est un ensemble de composants et propriétés WSDL 2.0 qui satisfait à toutes les exigences données dans cette spécification en fonction des indications des mots-clés à interpréter selon le RFC 2119 [IETF RFC 2119].

Les composants sont des collections typées de propriétés qui correspondent à des aspects différents des services web. Chaque sous-section à suivre décrit un type de composant différent, ses propriétés définies et sa représentation comme ensemble d'information XML [XML Information Set].

Les propriétés, non ordonnées, sont uniques par rapport au composant auquel elles sont associées. Les définitions des propriétés individuelles peuvent contraindre leur contenu (par exemple, à une valeur typée, un autre composant, ou un ensemble de valeurs typées ou de composants), et les composants peuvent imposer la présence d'une propriété pour prétendre à la conformité. Ces propriétés sont marquées comme étant OBLIGATOIRES, et celles dont la présence n'est pas nécessaire comme étant OPTIONNELLES. Par convention, pour la définition des règles de correspondance entre la représentation de l'ensemble d'information XML d'un composant et le composant même, une propriété optionnelle qui est absente du composant en question est décrite comme étant « vide ». Sauf indication contraire, lorsqu'une propriété est identifiée comme étant une collection (un ensemble ou une liste), sa valeur peut être une collection de zéro élément (vide). Pour simplifier la présentation des règles concernant des ensembles de composants, pour toutes les propriétés OPTIONNELLES dont le type est un ensemble, on DOIT interpréter l'absence d'une telle propriété dans un composant comme sémantiquement équivalente à la présence d'une propriété de même nom dont la valeur est l'ensemble vide. En d'autres termes, on DOIT partir du principe que toutes les propriétés à valeur d'ensemble (set-valued property) ont l'ensemble vide comme valeur par défaut, à utiliser en absence de la propriété.

Les définitions de composants sont sérialisables en format XML 1.0 mais elles sont indépendantes de toute sérialisation particulière du modèle de composants. Les définitions de composants utilisent un sous-ensemble (cf. la section 2.14 Types simples XML Schema 1.0 utilisés dans le modèle de composants) des types simples définis par la spécification XML Schema 1.0 [XML Schema: Datatypes].

Outre la représentation directe dans l'ensemble d'information XML décrite ici, le modèle de composants admet des composants extérieurs à l'ensemble d'information au travers des mécanismes décrits dans la section 4. Modularisation des descriptions WSDL 2.0.

On peut extraire un modèle de composants d'un ensemble d'information XML donné conforme au schéma XML de WSDL 2.0 en associant récursivement les items d'information à leurs composants identifiés, en commençant par l'item d'information d'élément wsdl:description. Cela comprend l'application des mécanismes décrits dans la section 4. Modularisation des descriptions WSDL 2.0.

Ce document ne définit pas de méthode pour produire une représentation dans l'ensemble d'information XML depuis une instance du modèle de composants. Notamment, parce qu'il y a en général plusieurs méthodes valides de modularisation d'une instance donnée du modèle de composants en un ou plusieurs ensembles d'information XML.

2.1 Description

2.1.1 Le composant Description

Au niveau supérieur, le composant Description est juste un conteneur pour deux catégories de composants : les composants WSDL 2.0 (WSDL 2.0 components) et les composants de système de typage (type system components).

Les composants WSDL 2.0 sont des interfaces, des liaisons et des services. Les composants de système de typage sont des déclarations d'éléments et des définitions de types.

Les composants de système de typage décrivent les contraintes exercées sur le contenu d'un message. Par défaut, ces contraintes sont exprimées en fonction de l'ensemble d'information XML [XML Information Set], c'est-à-dire qu'elles définissent les propriétés de nom local [local name], de nom d'espace de noms [namespace name], de sous-éléments [children] et d'attributs [attributes] d'un item d'information d'élément. Les systèmes de typage fondés sur d'autres modèles de données sont généralement pris en charge par des extensions de WSDL 2.0 ; cf. la section 6. Extensibilité du langage. Au cas où une extension définit des informations équivalentes à celles d'une déclaration d'élément global XML Schema, on peut la traiter comme si elle était une telle déclaration.

Cette spécification ne définit pas quel serait le comportement d'un document WSDL 2.0 utilisant simultanément plusieurs langages de schéma pour décrire des composants de système de typage.

Un composant Element Declaration définit le nom et le modèle de contenu d'un item d'information d'élément tels ceux définis par une déclaration d'élément globale XML Schema. Le composant a une propriété {name} qui est le nom qualifié QName de l'item d'information d'élément et une propriété {system} qui est l'adresse IRI de l'espace de noms des items d'information d'élément d'extension du système de typage, par exemple l'espace de noms de XML Schema.

Un composant Type Definition définit le modèle de contenu d'un item d'information d'élément tel que celui défini par une définition de type globale XML Schema. Le composant a une propriété {name} qui est le nom qualifié QName du type et une propriété {system} qui est l'adresse IRI de l'espace de noms des items d'information d'élément du système de typage, par exemple l'espace de noms de XML Schema.

Les composants Interface, Binding, Service, Element Declaration et Type Definition sont directement contenus dans le composant Description ; on les appelle des composants de niveau supérieur (top-level components). Les composants WSDL 2.0 de niveau supérieur contiennent d'autres composants, par exemple les composants Interface Operation et Endpoint, que l'on appelle des composants nichés (nested components). Les composants nichés peuvent contenir d'autres composants nichés. Le composant contenant un composant niché est appelé le parent (parent) du composant niché. Les composants nichés ont une propriété {parent} qui est une référence à leur composant parent.

Les propriétés du composant Description sont les suivantes :

L'ensemble des composants de niveau supérieur contenus dans le composant Description associé au document WSDL 2.0 initial se compose des composants définis dans le document initial, plus les composants associés aux documents WSDL 2.0 inclus par le document initial, plus les composants définis par les autres documents WSDL 2.0 dans les espaces de noms importés par le document initial. Le modèle de composants ne fait aucune distinction entre les composants définis dans le document initial et ceux définis dans les documents inclus ou les espaces de noms importés. Par contre, tout document WSDL 2.0 contenant des définitions de composants qui se réfèrent par un nom qualifié QName à des composants WSDL 2.0 appartenant à un espace de noms différent DOIT contenir un item d'information d'élément wsdl:import pour cet espace de noms (cf. la section 4.2 Importation des descriptions). En outre, toutes les références QName (QName references), qu'elles soient au même espace de noms ou à des espaces de noms différents, doivent se résoudre en composants (cf. la section 2.17 Résolution des noms qualifiés QName).

Lorsqu'on utilise le langage XML Schema pour décrire des composants de système de typage, l'inclusion des composants Element Declaration et Type Definition dans un composant Description obéit aux règles édictées dans la section 3.1 Utilisation du langage de définition XML Schema du W3C.

Outre des composants WSDL 2.0 et des composants de système de typage, on PEUT ajouter des composants d'extension supplémentaires, cf. la section 6. Extensibilité du langage. On PEUT aussi ajouter par extension des propriétés supplémentaires aux composants WSDL 2.0 et aux composants de système de typage.

2.1.2 Représentation XML du composant Description

<description
      targetNamespace="xs:anyURI" >
  <documentation />*
  [ <import /> | <include /> ]*
  <types />?
  [ <interface /> | <binding /> | <service /> ]*
</description>

Les descriptions WSDL 2.0 sont représentées en XML par un ou plusieurs ensembles d'information WSDL 2.0, c'est-à-dire un ou plusieurs items d'information d'élément description. Un ensemble d'information WSDL 2.0 contient les représentations d'une collection de composants WSDL 2.0 partageant un espace de noms cible commun et zéro ou plus items d'information d'élément wsdl:import, cf. la section 4.2 Importation des descriptions, correspondant à une collection avec des composants de plusieurs espaces de noms cibles.

Les composants définis ou inclus directement dans un composant Description sont dits appartenir au même espace de noms cible (target namespace). Ainsi, l'espace de noms cible regroupe un ensemble de définitions de composants liés et représente un nom univoque pour la sémantique attendue de la collection de composants. La valeur de l'item d'information d'attribut targetNamespace DEVRAIT être résolvable . Elle DEVRAIT se résoudre en un document exploitable par un humain ou une machine définissant directement ou indirectement la sémantique attendue de ces composants . Elle PEUT se résoudre en un document WSDL 2.0 fournissant une information de description de service pour cet espace de noms .

Si un document WSDL 2.0 est scindé en plusieurs documents WSDL 2.0 (lesquels peuvent être combinés au besoin selon les indications de la section 4.1 Inclusion des descriptions), alors l'item d'information d'élément targetNamespace DEVRAIT se résoudre en un document WSDL 2.0 maître comprenant tous les documents WSDL 2.0 nécessaires pour cette description de service . Cette approche permet la bonne résolution des identificateurs de fragment d'indicateur de composant WSDL 2.0.

Les composants appartenant à des espaces de noms importés ont des valeurs d'espace de noms cible différentes de celle du document WSDL 2.0 importeur. L'importation est donc le mécanisme pour utiliser des composants d'un espace de noms dans la définition de composants d'un autre espace de noms.

Notez que chaque document WSDL 2.0 ou composant de système de typage de même nature doit être identifié de façon unique par son nom qualifié. C'est-à-dire que, si deux composants distincts de même nature (Interface, Binding, etc.) sont dans le même espace de noms cible, alors leurs noms qualifiés DOIVENT être uniques. En revanche, des composants de types différents (par exemple, un composant Interface et un composant Binding) PEUVENT avoir le même nom qualifié QName. Les noms qualifiés des composants doivent donc être uniques dans l'espace de ces composants au sein d'un espace de noms cible donné.

L'item d'information d'élément description a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de description ;

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

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

    • un item d'information d'attribut targetNamespace OBLIGATOIRE comme décrit à la section 2.1.2.1 Item d'information d'attribut targetNamespace ;

    • zéro ou plus items d'information d'attribut, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".

  • 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 (cf. la section 5. Documentation) ;

    2. zéro ou plus items d'information d'élément parmi les suivants, dans un ordre quelconque :

      • zéro ou plus items d'information d'élément include (cf. la section 4.1 Inclusion des descriptions) ;

      • zéro ou plus items d'information d'élément import (cf. la section 4.2 Importation des descriptions) ;

      • zéro ou plus items d'information d'éléments, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".

    3. un item d'information d'élément types OPTIONNEL (cf. la section 3. Types) ;

    4. zéro ou plus items d'information d'élément parmi les suivants, dans un ordre quelconque :

2.1.2.1 Item d'information d'attribut targetNamespace

L'item d'information d'attribut targetNamespace définit l'affiliation à un espace de noms des composants de niveau supérieur définis dans cet item d'information d'élément description. Les composants Interface, Binding et Service sont des composants de niveau supérieur.

L'item d'information d'attribut targetNamespace a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de targetNamespace ;

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

Le type de l'item d'information d'attribut targetNamespace est xs:anyURI. Sa valeur DOIT être une adresse IRI absolue (cf. [IETF RFC 3987]) et devrait être résolvable .

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

La correspondance de la représentation XML de l'item d'information d'élément description (cf. la section 2.1.2 Représentation XML du composant Description) aux propriétés du composant Description est décrite dans le tableau 2-1.

Tableau 2-1. Correspondance de la représentation XML aux propriétés du composant Description
Propriété Valeur
{interfaces} L'ensemble des composants Interface correspondant à tous les items d'information d'élément interface dans les sous-éléments [children] de l'item d'information d'élément description, le cas échéant, plus tous les composants Interface inclus (via wsdl:include) ou importés (via wsdl:import), cf. la section 4. Modularisation des descriptions WSDL 2.0.
{bindings} L'ensemble des composants Binding correspondant à tous les items d'information d'élément binding dans les sous-éléments [children] de l'item d'information d'élément description, le cas échéant, plus tous les composants Binding inclus (via wsdl:include) ou importés (via wsdl:import), cf. la section 4. Modularisation des descriptions WSDL 2.0.
{services} L'ensemble des composants Service correspondant à tous les items d'information d'élément service dans les sous-éléments [children] de l'item d'information d'élément description, le cas échéant, plus tous les composants Service inclus (via wsdl:include) ou importés (via wsdl:import), cf. la section 4. Modularisation des descriptions WSDL 2.0.
{element declarations} L'ensemble des composants Element Declaration correspondant à toutes les déclarations d'élément définies comme descendants de l'item d'information d'élément types, le cas échéant, plus tous les composants Element Declaration inclus (via xs:include) ou importés (via xs:import). L'ensemble incluera au minimum toutes les déclarations d'élément globales définies par les items d'information d'élément element de XML Schema. Il PEUT également inclure les déclarations d'autres systèmes de typage décrivant les propriétés de nom local [local name], de nom d'espace de noms [namespace name], d'attributs [attributes] et de sous-éléments [children] d'un item d'information d'élément. Chaque déclaration d'élément XML Schema DOIT avoir un nom qualifié QName unique .
{type definitions} L'ensemble des composants Type Definition correspondant à toutes les définitions de type définies comme descendants des items d'information d'élément types, le cas échéant, plus tous les composants Type Definition inclus (via xs:include) ou importés (via xs:import) ; plus les types de données intégrés définis par la spécification XML Schema [XML Schema: Datatypes], à savoir les 19 types de données primitifs suivants, xs:string, xs:boolean, xs:decimal, xs:float, xs:double, xs:duration, xs:dateTime, xs:time, xs:date, xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay, xs:gMonth, xs:hexBinary, xs:base64Binary, xs:anyURI, xs:QName, xs:NOTATION, et les 25 types de données dérivés, xs:normalizedString, xs:token, xs:language, xs:NMTOKEN, xs:NMTOKENS, xs:Name, xs:NCName, xs:ID, xs:IDREF, xs:IDREFS, xs:ENTITY, xs:ENTITIES, xs:integer, xs:nonPositiveInteger, xs:negativeInteger, xs:long, xs:int, xs:short, xs:byte, xs:nonNegativeInteger, xs:unsignedLong, xs:unsignedInt, xs:unsignedShort, xs:unsignedByte, xs:positiveInteger. L'ensemble PEUT également inclure les définitions d'autres systèmes de typage décrivant les propriétés d'attributs [attributes] et de sous-éléments [children] d'un item d'information d'élément. Chaque définition de type XML Schema DOIT avoir un nom qualifié QName unique 

2.2 Interface

2.2.1 Le composant Interface

Un composant Interface décrit les séquences de messages qu'un service envoie ou reçoit. Il regroupe les messages liés en opérations. Une opération est une séquence de messages entrants et sortants, et une interface est un ensemble d'opérations.

Une interface peut en option étendre une ou plusieurs interfaces. Afin d'éviter les définitions circulaires, une interface NE DOIT PAS apparaître dans l'ensemble d'interfaces qu'elle étend, que ce soit directement ou indirectement . L'ensemble des opérations disponibles dans une interface comprend toutes les opérations définies par les interfaces que cette interface étend directement ou indirectement, ainsi que toutes les opérations qu'elle définit directement. Les opérations définies directement dans une interface sont appelées les opérations déclarées (declared operations) de l'interface. Au cours du processus, les composants d'opération équivalents, selon la section 2.15 Équivalence des composants, sont traités comme un seul composant. Le mécanisme d'extension d'interface agit de façon similaire pour tous les autres composants susceptibles d'être définis dans une interface, à savoir les composants Interface Fault.

Les interfaces sont des structures nommées qui peuvent être appelées par un nom qualifié QName (cf. la section 2.17 Résolution des noms qualifiés QName). Les composants Binding, par exemple, se réfèrent aux interfaces de cette façon.

Les propriétés du composant Interface sont les suivantes :

Pour chaque composant Interface dans la propriété {interfaces} d'un composant Description, la propriété {name} DOIT être unique .

2.2.2 Représentation XML du composant Interface

<description>
  <interface
        name="xs:NCName" 
        extends="liste de xs:QName"?
        styleDefault="liste de xs:anyURI"? >
    <documentation />*
    [ <fault /> | <operation /> ]*
  </interface>
</description>

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

2.2.2.1 Item d'information d'attribut name avec élément possesseur [owner element] interface

L'item d'information d'attribut name avec l'item d'information d'attribut targetNamespace de l'item d'information d'élément description parent [parent] forment le nom qualifié QName de l'interface.

L'item d'information d'attribut name a 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.

Le type de l'item d'information d'attribut name est xs:NCName.

2.2.2.2 Item d'information d'attribut extends

L'item d'information d'attribut extends liste les interfaces dont cette interface dérive.

L'item d'information d'attribut extends a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de extends ;

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

Le type de l'item d'information d'attribut extends est une liste de noms qualifiés xs:QName séparés par des caractères blancs.

La liste des noms qualifiés xs:QName dans un item d'information d'attribut extends NE DOIT PAS contenir de doubles .

2.2.2.3 Item d'information d'attribut styleDefault

L'item d'information d'attribut styleDefault indique le style par défaut (cf. la section 2.4.1.2 Style d'opération) utilisé pour construire les propriétés {element declaration} des propriétés {interface message references} de toutes les opérations contenues dans l'élément possesseur [owner element] interface.

L'item d'information d'attribut styleDefault a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de styleDefault ;

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

Le type de l'item d'information d'attribut styleDefault est une liste de xs:anyURI. Si présent, sa valeur DOIT contenir des adresses IRI absolues (cf. [IETF RFC 3987]) .

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

La correspondance de la représentation XML de l'item d'information d'élément interface (cf. la section 2.2.2 Représentation XML du composant Interface) aux propriétés du composant Interface est décrite dans le tableau 2-2.

Tableau 2-2. Correspondance de la représentation XML aux propriétés du composant Interface
Propriété Valeur
{name} Le nom qualifié QName dont le nom local est la valeur réelle (actual value) de l'item d'information d'attribut name et le nom d'espace de noms est la valeur réelle de l'item d'information d'attribut targetNamespace de l'item d'information d'élément description parent [parent].
{extended interfaces} L'ensemble des composants Interface en lesquels se résolvent les valeurs dans l'item d'information d'attribut extends, le cas échéant (cf. la section 2.17 Résolution des noms qualifiés QName).
{interface faults} L'ensemble des composants Interface Fault correspondant aux items d'information d'élément fault dans les sous-éléments [children], le cas échéant.
{interface operations} L'ensemble des composants Interface Operation correspondant aux items d'information d'élément operation dans les sous-éléments [children], le cas échéant.

Rappellez-vous, cf. la section 2.2.1 Le composant Interface, que les composants Interface dans la propriété {extended interfaces} d'un composant Interface donné NE DOIVENT PAS contenir de composant Interface dans l'une de leurs propriétés {extended interfaces}, pour dire que les interfaces d'extension récursives sont prohibées.

2.3 Incident d'interface

2.3.1 Le composant Interface Fault

Un incident (fault) est un événement survenant pendant l'exécution d'un échange de messages, qui bouleverse le flux normal des messages.

Un incident survient typiquement lorsqu'une partie est dans l'impossibilité de communiquer une condition d'erreur dans le flux de messages normal ou souhaite terminer un échange de messages. Un message d'incident peut être utilisé pour communiquer une information hors bande telle que la raison de l'erreur, l'origine de la panne, ainsi que d'autres diagnostics informels tel qu'une trace de pile de programme (program stack trace).

Un composant Interface Fault décrit un incident qui PEUT se produire au cours de l'invocation d'une opération de l'interface. Le composant Interface Fault déclare un incident abstrait en le nommant et en indiquant le contenu du message d'incident. Le composant Interface Operation indique quand et comment le message d'incident circule.

Le composant Interface Fault fournit un mécanisme clair pour nommer et décrire l'ensemble des incidents qu'une interface peut générer. Cela permet aux opérations d'identifier aisément par leur nom les incidents individuels que les interfaces peuvent générer. Ce mécanisme permet d'identifier immédiatement le même incident survenant à travers plusieurs opérations et référencé dans plusieurs liaisons, et de réduire la multiplication des descriptions d'un incident individuel.

D'autres incidents que ceux décrits dans le composant Interface peuvent également être générés à l'exécution (at run-time), c'est-à-dire que les incidents forment un ensemble ouvert. Le composant Interface décrit les incidents ayant une sémantique au niveau de l'application, c'est-à-dire que le client ou le services sont censés les prendre en charge et potentiellement récupérer d'eux, dans le cadre de la logique de traitement de l'application. Par exemple, un composant Interface qui accepte un numéro de carte de crédit peut décrire les incidents indiquant que le numéro de la carte est invalide, qu'elle a été signalée volée ou qu'elle est périmée. Le composant Interface ne décrit pas les incidents de systèmes généraux tels que les pannes de réseau, les conditions de dépassement de mémoire, les conditions de pénurie d'espace disque, les formats de message invalides, etc., même si ces incidents peuvent survenir dans le cadre de l'échange de messages. De tels incidents de systèmes généraux peuvent survenir au cours de n'importe quel échange de messages et les décrire explicitement dans un composant Interface n'est donc pas informatif.

Les propriétés du composant Interface Fault sont les suivantes :

  • {name}, OBLIGATOIRE. Un nom qualifié xs:QName ;

  • {message content model}, OBLIGATOIRE. Un type xs:token ayant l'une des valeurs suivantes : #any, #none, #other ou #element . Une valeur de #any indique que le contenu des incidents est n'importe quel élément seul ; une valeur de #none indique qu'il n'y aucun contenu d'incident ; une valeur de #other indique que le contenu d'incident est décrit par une autre propriété d'extension référençant une déclaration dans un système de typage d'extension non-XML ; une valeur de #element indique que l'incident se compose d'un seul élément décrit par la déclaration d'élément globale référencée par la propriété {element declaration}. Cette propriété n'est utilisée que si l'incident est décrit en utilisant un modèle de données fondé sur XML ;

  • {element declaration}, OPTIONNELLE. Une référence à un composant Element Declaration dans la propriété {element declarations} du composant Description. Cet élément représente le contenu, ou « charge utile » (payload), de l'incident. Lorsque la propriété {message content model} a la valeur #any ou #none, la propriété {element declaration} DOIT être vide  ;

  • {parent}, OBLIGATOIRE. Le composant Interface qui contient ce composant dans sa propriété {interface faults}.

Pour chaque composant Interface Fault dans la propriété {interface faults} d'un composant Interface, la propriété {name} doit être unique. Notez que le schéma XML normatif de WSDL 2.0 fait valoir cette contrainte.

Les composants Interface Fault sont identifiés de manière unique par le nom qualifié QName du composant Interface englobant et le nom qualifié du composant Interface Fault même.

Remarque :

Bien qu'ils aient une propriété {name}, les composants Interface Fault ne peuvent pas être identifiés exclusivement par leur nom qualifié QName. En effet, deux composants Interface, dont la valeur de la propriété {name} a le même nom d'espace de noms mais des noms locaux différents, peuvent contenir des composants Interface Fault ayant la même valeur de propriété {name}. La propriété {name} des composants Interface Fault est donc insuffisante pour former l'identité unique d'un composant Interface Fault. Une méthode pour identifier les composants de manière unique est définie dans la section A.2 Identificateurs de fragment. Cf. la section A.2.5 Le composant Interface Fault pour la définition de l'identificateur de fragment du composant Interface Fault.

Au cas où deux (ou plus) composants Interface Fault ont des propriétés {name} de même valeur, en raison d'une interface qui étend une ou plusieurs autres interfaces, alors les modèles de composant de ces composants Interface Fault DOIVENT être équivalents (cf. la section 2.15 Équivalence des composants. Si les composants Interface Fault sont équivalents, alors ils sont censés fusionner en un seul composant. Au sein du même composant Interface, si deux composants Interface Fault ne sont pas équivalents, alors leurs propriétés {name} NE DOIVENT PAS être égales.

À cause des règles précédentes, notez que si deux interfaces ont la même valeur de nom d'espace de noms pour leurs propriétés {name} et ont aussi un ou plusieurs incidents avec la même valeur pour leurs propriétés {name}, alors ces interfaces ne peuvent pas les deux former une partie de la chaîne de dérivation d'une interface dérivée, à moins que ces incidents n'en soient qu'un.

Pour la raison précédente, une bonne pratique DEVRAIT être de s'assurer, le cas échéant, que le nom local de la propriété {name} des composants Interface Fault au sein d'un espace de noms soit unique, rendant ainsi possible une telle dérivation sans erreur accidentelle .

Si un sytème de typage non fondé sur l'ensemble d'information XML [XML Information Set] est en vigueur (comme examiné dans la section 3.2 Utitilisation d'autres langages de schéma), alors il faudrait ajouter d'autres propriétés au composant Interface Fault (en même temps que des attributs d'extension à sa représentation XML) afin de pouvoir associer ces types de message au message de référence.

2.3.2 Représentation XML du composant Interface Fault

<description>
  <interface>
    <fault
          name="xs:NCName" 
          element="union de xs:QName, xs:token"? >
      <documentation />*
    </fault>
  </interface>
</description>

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

  • un nom local [local name] de fault ;

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

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

  • 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 (cf. la section 5. Documentation) ;

    2. zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".

2.3.2.1 Item d'information d'attribut name avec élément possesseur [owner element] fault

L'item d'information d'attribut name identifie un item d'information d'élément fault donné à l'intérieur d'un item d'information d'élément interface.

L'item d'information d'attribut name a 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.

Le type de l'item d'information d'attribut name est xs:NCName.

2.3.2.2 Item d'information d'attribut element avec élément possesseur [owner element] fault

L'item d'information d'attribut element se rapporte, par un nom qualifié QName, à un composant Element Declaration.

L'item d'information d'attribut element a 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.

Le type de l'item d'information d'attribut element est l'union d'un type xs:QName et d'un type xs:token, où les valeurs d'atome (token) permises sont #any, #none ou #other.

2.3.3 Correspondance de la représentation XML de Interface Fault aux propriétés de composant

La correspondance de la représentation XML de l'item d'information d'élément fault (cf. la section 2.3.2 Représentation XML du composant Interface Fault) aux propriétés du composant Interface Fault est décrite dans le tableau 2-3.

Tableau 2-3. Correspondance de la représentation XML aux propriétés du composant Interface Fault
Propriété Valeur
{name} Le nom qualifié QName dont le nom local est la valeur réelle de l'item d'information d'attribut name et dont le nom d'espace de noms est la valeur réelle de l'item d'information d'attribut targetNamespace de l'item d'information d'élément description parent [parent] de l'item d'information d'élément interface parent [parent].
{message content model} Si l'item d'information d'attribut element est présent et que sa valeur est un nom qualifié QName, alors c'est #element ; sinon la valeur réelle de l'item d'information d'attribut element, le cas échéant ; sinon #other.
{element declaration} Si l'item d'information d'attribut element est présent et que sa valeur est un nom qualifié QName, alors c'est le composant Element Declaration de la propriété {element declarations} du composant Description en lequel est résolue la valeur de l'item d'information d'attribut element (cf. la section 2.17 Résolution des noms qualifiés QName) ; sinon vide. Si l'item d'information d'attribut element a une valeur, alors elle DOIT se résoudre dans le composant Element Declaration de la propriété {element declarations} du composant Description .
{parent} Le composant Interface correspondant à l'item d'information d'élément interface dans le parent [parent].

2.4 Opération d'interface

2.4.1 Le composant Interface Operation

Un composant Interface Operation décrit une opération prise en charge par une interface donnée. Une opération est une interaction avec le service consistant en un ensemble de messages échangés (ordinaires et d'incident) entre le service et les autres parties prenantes de l'interaction. Le séquencement (sequencing) et la cardinalité des messages impliqués dans une interaction particulière sont régis par le modèle d'échange de messages (message exchange pattern) utilisé par l'opération (cf. la propriété {message exchange pattern}).

Un modèle d'échange de messages définit les paramètres fictifs (placeholders) des messages, les participants du modèle (c'est-à-dire les émetteurs et les récepteurs des messages), et la cardinalité et le séquencement des messages échangés par les participants. Les paramètres fictifs de message sont associés à des types de message spécifiques par l'opération utilisant le modèle au moyen de références de message et d'incident (cf les propriétés {interface message references} et {interface fault references}). Le service dont l'opération utilise le modèle devient un participant du modèle. Cette spécification ne définit pas de langage interprétable par une machine pour décrire des modèles d'échange de messages ni ne définit de modèles spécifiques. La spécification complémentaire [WSDL 2.0 Adjuncts] définit un ensemble de tels modèles et définit des adresses IRI d'identification, dont chacune PEUT être utilisée comme valeur de la propriété {message exchange pattern}.

Les propriétés du composant Interface Operation sont les suivantes :

Pour chaque composant Interface Operation dans la propriété {interface operations} d'un composant Interface, la propriété {name} DOIT être unique. Notez que le schéma XML normatif de WSDL 2.0 fait valoir cette contrainte.

Les composants Interface Operation sont identifiés de manière unique par le nom qualifié QName du composant Interface englobant et le nom qualifié QName du composant Interface Operation même.

Remarque :

Bien qu'ils aient une propriété {name}, les composants Interface Operation ne peuvent pas être identifiés exclusivement par leur nom qualifié QName. En effet, deux composants Interface, dont la valeur de la propriété {name} a le même nom d'espace de noms mais des noms locaux différents, peuvent contenir des composants Interface Operation ayant la même valeur de propriété {name}. La propriété {name} des composants Interface Operation est donc insuffisante pour former l'identité unique d'un composant Interface Operation. Une méthode pour identifier les composants de manière unique est définie dans la section A.2 Identificateurs de fragment. Cf. la section A.2.6 Le composant Interface Operation pour la définition de l'identificateur de fragment du composant Interface Operation.

Au cas où deux (ou plus) composants Interface Operation ont des propriétés {name} de même valeur, en raison d'une interface qui étend une ou plusieurs interfaces, alors les modèles de composant de ces composants Interface Operation DOIVENT être équivalents (cf. la section 2.15 Équivalence des composants. Si les composants Interface Operation sont équivalents, alors ils sont censés fusionner en un seul composant. Au sein du même document Interface, si deux composants Interface Operation ne sont pas équivalents, alors leurs propriétés {name} NE DOIVENT PAS être égales.

À cause des règles précédentes, notez que si deux interfaces ont la même valeur de nom d'espace de noms pour leurs propriétés {name} et ont aussi une ou plusieurs opérations avec la même valeur pour leurs propriétés {name}, alors ces interfaces ne peuvent pas les deux former une partie de la chaîne de dérivation d'une interface dérivée, à moins que ces opérations n'en soient qu'une.

Pour la raison précédente, une bonne pratique DEVRAIT être de s'assurer, le cas échéant, que le nom local de la propriété {name} des composants Interface Operation au sein d'un espace de noms soit unique, rendant ainsi possible une telle dérivation sans erreur accidentelle 

Plusieurs composants Interface Fault Reference dans la propriété {interface fault references} d'un composant Interface Operation peuvent se rapporter au même libellé de message (message label). Auquel cas, les types d'incident listés définissent les autres messages d'incident. Cela permet d'indiquer qu'il y a plus d'un type d'incident lié à ce message.

2.4.1.1 Modèle d'échange de messages

Cette section précise quelques aspects des modèles d'échange de messages. Consultez la spécification Langage de description de services web (WSDL) version 2.0 tome 2 — Compléments [WSDL 2.0 Adjuncts] pour une explication complète de la sémantique des modèles d'échange de messages en général, ainsi que les définitions des modèles d'échange de messages prédéfinis de WSDL 2.0.

Un message fictif (placeholder message) est un gabarit pour un message réel tel que décrit par un composant Interface Message Reference. Bien qu'un message fictif ne soit pas en lui-même un composant, il y a lieu de le considérer utilement comme ayant les deux propriétés {message label} et {direction} définissant les valeurs du composant Interface Message Reference réel qui lui correspond. Un message fictif est également associé à un nœud qui échange le message avec le service. En outre, un message fictif peut être désigné comme optionnel dans l'échange.

Un règlement de propagation d'incident (fault propagation ruleset) définit la relation entre les composants Interface Fault Reference et Interface Message Reference d'un composant Interface Operation. La spécification Langage de description de services web (WSDL) version 2.0 tom 2 : compléments [WSDL 2.0 Adjuncts] définit trois règlements de propagation d'incident, que nous désignerons par fault-replaces-message, message-triggers-fault et no-faults. Ces trois règlements de propagation d'incident sont utilisés par les modèles d'échange de messages prédéfinis dans [WSDL 2.0: Adjuncts]. D'autres modèles d'échange de messages peuvent définir des règlements de propagation d'incident supplémentaires.

Un modèle d'échange de messages est un gabarit (template) pour l'échange d'un ou plusieurs messages, et incidents associés, entre le service et un ou plusieurs nœuds comme décrit par un composant Interface Operation. Le service et les autres nœuds sont appelés les participants (participants) de l'échange. Plus spécifiquement, un modèle d'échange de messages consiste en une séquence d'un ou plusieurs messages fictifs. Chaque message fictif dans cette séquence est identifié de manière unique par sa propriété {message label}. Un modèle d'échange de message est lui-même identifié par une adresse IRI absolue, qui est utilisée comme valeur de la propriété {message exchange pattern} du composant Interface Operation et qui définit le règlement de propagation d'incident auquel ses incidents obéissent .

2.4.1.2 Style d'opération

Un style d'opération définit des informations supplémentaires à propos d'une opération. Ainsi, un style d'opération peut définir des contraintes structurelles sur les déclarations d'éléments des composants de référence de message d'interface ou d'incident d'interface utilisés par l'opération. Ces informations supplémentaires n'affectent en aucune façon les messages et incidents échangés avec le service, et on peut donc les ignorer dans ce contexte en toute sécurité. En revanche, ces informations peuvent servir dans d'autres buts, par exemple, une génération de code améliorée. La propriété {style} du composant Interface Operation contient un ensemble de zéro ou plus adresses IRI identifiant des styles d'opération. Un composant Interface Operation DOIT satisfaire aux indications fournies par chaque style d'opération identifié par sa propriété {style. Si aucun composant Interface Operation ne peut satisfaire simultanément à tous les styles, le document est invalide.

Si la propriété {style} d'un composant Interface Operation a une valeur, alors celle-ci (un ensemble d'adresses IRI) indique les règles qui ont servi à définir les déclarations d'éléments (ou les autres propriétés définissant des contenus de messages et d'incidents ; cf. les sections 3.2 Utilisation d'autres langages de schéma) des composants Interface Message Reference ou Interface Fault utilisés par l'opération. Bien qu'un style d'opération donné puisse contraindre tous les messages et incidents d'entrée et de sortie d'une opération, il PEUT choisir d'en contraindre une combinaison, par exemple, seulement les messages, ou seulement les entrées.

Veuillez consulter la spécification Langage de description de services web (WSDL) version 2.0 tome 2 : compléments [WSDL 2.0 Adjuncts] pour les définitions de style d'opérations particulières.

2.4.2 Représentation XML du composant Interface Operation

<description>
  <interface>
    <operation
          name="xs:NCName" 
          pattern="xs:anyURI"?
          style="liste de xs:anyURI"? >
      <documentation />*
      [ <input /> | <output /> | <infault /> | <outfault /> ]*
    </operation>
  </interface>
</description>

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

2.4.2.1 Item d'information d'attribut name avec élément possesseur [owner element] operation

L'item d'information d'attribut name identifie un item d'information d'élément operation donné dans un item d'information d'élément interface donné.

L'item d'information d'attribut name a 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.

Le type de l'item d'information d'attribut name est xs:NCName.

2.4.2.2 Item d'information d'attribut pattern avec élément possesseur [owner element] operation

L'item d'information d'attribut pattern identifie le modèle d'échange de messages qu'utilise une opération donnée.

L'item d'information d'attribut pattern a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de pattern ;

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

Le type de l'item d'information d'attribut pattern est xs:anyURI. Notez que sa valeur doit être une adresse IRI absolue (cf. [IETF RFC 3987]).

2.4.2.3 Item d'information d'attribut style avec élément possesseur [owner element] operation

L'item d'information d'attribut style indique les règles utilisées pour construire les propriétés {element declaration} des composants Interface Message Reference membres de la propriété {interface message references} de l'élément possesseur [owner element] operation.

L'item d'information d'attribut style a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de style ;

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

Le type de l'item d'information d'attribut style est une liste de xs:anyURI. Notez que sa valeur doit être une liste d'adresses IRI absolues (cf. [IETF RFC 3987]).

2.4.3 Correspondance de la représentation XML de Interface Operation aux propriétés de composant

La correspondance de la représentation XML de l'item d'information d'élément operation (cf. la section 2.4.2 Représentation XML du composant Interface Operation) aux propriétés du composant Interface Operation (cf. la section 2.4.1 Le composant Interface Operation) est décrite dans le tableau 2-4.

Tableau 2-4. Correspondance de la représentation XML aux propriétés du composant Interface Operation
Propriété Valeur
{name} Le nom qualifié QName dont le nom local est la valeur réelle de l'item d'information d'attribut name et le nom d'espace de noms est la valeur réelle de l'item d'information d'attribut targetNamespace de l'item d'information d'élément description parent [parent] de l'item d'information d'élément interface parent [parent].
{message exchange pattern} La valeur réelle de l'item d'information d'attribut pattern ; sinon "http://www.w3.org/ns/wsdl/in-out".
{interface message references} L'ensemble des références de messages correspondant aux items d'information d'élément input et output dans les sous-éléments [children], le cas échéant.
{interface fault references} L'ensemble des références d'incidents d'interface correspondant aux items d'information d'élément infault et outfault dans les sous-éléments [children], le cas échéant.
{style} L'ensemble contenant les adresses IRI dans la valeur réelle de l'item d'information d'attribut style, si présent ; sinon l'ensemble contenant les adresses IRI dans la valeur réelle de l'item d'information d'attribut styleDefault de l'item d'information d'élément interface parent [parent], si présent ; sinon vide.
{parent} Le composant Interface correspondant à l'item d'information d'élément interface dans le parent [parent].

2.5 Référence de message d'interface

2.5.1 Le composant Interface Message Reference

Un composant Interface Message Reference définit le contenu, ou charge utile, d'un message échangé dans une opération. Par défaut, le contenu du message est défini par un système de typage fondé sur XML tel que XML Schema. D'autres systèmes de typage peuvent être utilisés via le mécanisme d'extension de système de typage de WSDL 2.0.

Un modèle d'échange de messages définit un ensemble de messages fictifs, qui interviennent dans le modèle, et leur affecte des libellés de message (message labels) uniques (par exemple, 'In', 'Out'). Le but d'un composant Interface Message Reference est d'associer un élément de message réel (une déclaration de message XML ou un autre déclaration ; cf. la section 3.2 Utilisation d'autres langages de schéma) à un message dans le modèle, identifié par un libellé de message. Plus tard, à l'instanciation du modèle d'échange de messages, les messages correspondant à ce libellé particulier suivront les affectations d'éléments faites par le composant Interface Message Reference.

Les propriétés du composant Interface Message Reference sont les suivantes :

  • {message label}, OBLIGATOIRE. Un nom sans deux-points xs:NCName (Non-Colon Name). Cette propriété identifie le rôle joué par le message dans la propriété {message exchange pattern} du composant Interface Operation contenant le message. La valeur de cette propriété DOIT correspondre au nom d'un message fictif défini par le modèle d'échange de messages  ;

  • {direction}, OBLIGATOIRE. Un type xs:token ayant la valeur in ou out, indiquant respectivement si le message arrive au service ou en vient . La direction DOIT être la même que celle du message identifié par la propriété {message label} dans la propriété {message exchange pattern} du composant Interface Operation contenant le message  ;

  • {message content model}, OBLIGATOIRE. Un type xs:token avec l'une des valeurs suivantes : #any, #none, #other ou #element . Une valeur de #any indique que le contenu du message est un élément seul ; une valeur de #none indique que le message n'a pas de contenu ; une valeur de #other indique que le contenu du message est décrit par une autre propriété d'extension référençant une déclaration dans un système de typage d'extension non-XML ; une valeur de #element indique que le message se compose d'un seul élément décrit par la déclaration d'élément globale référencée par la propriété {element declaration}. Cette propriété n'est utilisée que si le message est décrit en utilisant un modèle de données fondé sur XML ;

  • {element declaration}, OPTIONNELLE. Une référence à un composant Element Declaration dans la propriété {element declarations} du composant Description. Cette élément représente le contenu ou « charge utile » du message. Lorsque la propriété {message content model} a la valeur #any ou #none, la propriété {element declaration} DOIT être vide  ;

  • {parent}, OBLIGATOIRE. Le composant Interface Operation qui contient ce composant dans sa propriété {interface message references}.

Pour chaque composant Interface Message Reference dans la propriété {interface message references} d'un composant Interface Operation, sa propriété {message label} DOIT être unique .

Si un système de typage non fondé sur l'ensemble d'information XML est en vigueur (comme étudié dans la section 3.2 Utilisation d'autres langages de schéma), alors il faudrait ajouter les propriétés supplémentaires au composant Interface Message Reference (en même temps que les attributs d'extension à sa représentation XML) afin de pouvoir associer ces types de message à la référence de message.

2.5.2 Représentation XML du composant Interface Message Reference

<description>
  <interface>
    <operation>
      <input
            messageLabel="xs:NCName"?
            element="union de xs:QName, xs:token"? >
        <documentation />*
      </input>
      <output
            messageLabel="xs:NCName"?
            element="union de xs:QName, xs:token"? >
        <documentation />*
      </output>
    </operation>
  </interface>
</description>

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

  • un nom local [local name] de input ou output ;

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

  • zéro ou plus items d'information d'attribut parmi ses attributs [attributes] comme suit :

  • 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 (cf. la section 5. Documentation) ;

    2. zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".

2.5.2.1 Item d'information d'attribut messageLabel avec élément possesseur [owner element] input ou output

L'item d'information d'attribut messageLabel identifie le rôle de ce message dans le modèle d'échange de messages de l'item d'information d'élément operation donné.

L'item d'information d'attribut messageLabel a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de messageLabel ;

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

Le type de l'item d'information d'attribut messageLabel est xs:NCName.

2.5.2.2 Item d'information d'attribut element avec élément possesseur [owner element] input ou output

L'item d'information d'attribut element a 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.

Le type de l'item d'information d'attribut element est l'union d'un nom qualifié de type xs:QName et d'un type xs:token, où les valeurs permises sont #any, #none ou #other.

2.5.3 Correspondance de la représentation XML de Interface Message Reference aux propriétés de composant

La correspondance de la représentation XML de l'item d'information d'élément de la référence de message d'interface (cf. la section 2.5.2 Représentation XML du composant Interface Message Reference) aux propriétés du composant Interface Message Reference (cf. la section 2.5.1 Le composant Interface Message Reference) est décrite dans le tableau 2-5 et utilise les définitions suivantes.

Définir le modèle d'échange de messages de l'item d'information d'élément comme étant la propriété {message exchange pattern} du composant Interface Operation parent.

Définir la direction de message de l'item d'information d'élément comme valant in si le nom local de celui-ci est input, et out si le nom local est output.

Notez que l'item d'information d'attribut messageLabel d'un item d'information d'élément de la référence de message d'interface doit être présent si le modèle d'échange de messages a plus d'un message fictif dont la propriété {direction} est égale à la direction du message.

Si l'item d'information d'attribut messageLabel d'un item d'information d'élément d'une référence de message d'interface est présent, alors sa valeur réelle DOIT correspondre à la propriété {message label} d'un message fictif dont la propriété {direction} est égale à la direction du message .

Si l'item d'information d'attribut messageLabel d'un item d'information d'élément d'une référence de message d'interface est absent, alors il DOIT y avoir un message fictif unique dont la propriété {direction} est égale à la direction du message .

Définir le libellé de message effectif (effective message label) d'un item d'information d'élément d'une référence de message d'interface comme étant soit la valeur réelle de l'item d'information d'attribut messageLabel si présent, soit la propriété {message label} du message fictif unique dont la propriété {direction} est égale à la direction du message si l'item d'information d'attribut est absent.

Si le nom local est input, alors le modèle d'échange de messages DOIT avoir au moins un message fictif avec une direction de "In" .

Si le nom local est output, alors le modèle d'échange de messages DOIT avoir au moins un message fictif avec une direction de "Out" .

Si le nom local est infault, alors le modèle d'échange de messages DOIT comporter au moins un incident dans la direction "In" .

Si le nom local est outfault, alors le modèle d'échange de messages DOIT comporter au moins un incident dans la direction "Out" .

Tableau 2-5. Correspondance de la représentation XML aux propriétés du composant Interface Message Reference
Propriété Valeur
{message label} Le libellé de message effectif.
{direction} La direction du message.
{message content model} Si l'item d'information d'attribut element est présent et que sa valeur est un nom qualifié QName, alors #element ; sinon la valeur réelle de l'item d'information d'attribut element, le cas échéant ; sinon #other.
{element declaration} Si l'item d'information d'attribut element est présent et que sa valeur est un nom qualifié QName, alors le composant Element Declaration de la propriété {element declarations} du composant Description en lequel est résolue la valeur de l'item d'information d'attribut element (cf. la section 2.17 Résolution des noms qualifiés QName) ; sinon vide. Si l'item d'information d'attribut element a une valeur, alors elle DOIT se résoudre en un composant Element Declaration de la propriété {element declarations} du composant Description .
{parent} Le composant Interface Operation correspondant à l'item d'information d'élément interface dans le parent [parent].

2.6 Référence d'incident d'interface

2.6.1 Le composant Interface Fault Reference

Un composant Interface Fault Reference associe un type défini, indiqué par un composant Interface Fault, à un message d'incident échangé dans une opération.

Un modèle d'échange de messages définit un ensemble de messages fictifs, qui interviennent dans le modèle, et leur affecte des libellés de message uniques au sein du modèle (par exemple, "In", "Out"). Le but d'un composant Interface Fault Reference est d'associer un type de message réel (une déclaration d'élément XML ou une autre déclaration, cf. la section 3.2 Utilisation d'autres langages de schéma en contenu du message, défini par un composant Interface Fault) à un message d'incident survenant dans le modèle. Pour identifier le message d'incident qu'il décrit, le composant Interface Fault Reference utilise le libellé du message auquel il se rapporte comme clé.

Comme indiqué précédemment, la spécification complémentaire [WSDL 2.0 Adjuncts] définit plusieurs règlements de propagation d'incident utilisables par un modèle d'échange de messages donné. Pour le règlement fault-replaces-message, le message auquel se rapporte l'incident identifie le message à la place duquel le message d'incident déclaré apparaîtra. Ainsi, le message d'incident voyagera dans la même direction que celle du message qu'il remplace dans le modèle. Pour le règlement message-triggers-fault, le message auquel l'incident se rapporte identifie le message à la suite duquel l'incident indiqué peut apparaître, en direction opposée du message en question. C'est-à-dire que le message d'incident voyagera dans la direction opposée du message qu'il suit dans le modèle d'échange de messages.

Les propriétés du composant Interface Fault Reference sont les suivantes :

  • {interface fault}, OBLIGATOIRE. Un composant Interface Fault dans la propriété {interface faults} du composant Interface parent [parent] (ou dans un composant Interface qui étend celui-ci directement ou indirectement) du composant Interface Operation parent [parent]. L'identification du composant Interface Fault définit donc indirectement le contenu (ou charge utile) réel du message d'incident ;

  • {message label}, OBLIGATOIRE. Un nom de type xs:NCName. Cette propriété identifie le message auquel cet incident se rapporte parmi ceux définis dans la propriété {message exchange pattern} du composant Interface Operation dans lequel le message est contenu. La valeur de cette propriété DOIT correspondre au nom d'un message fictif défini par le modèle d'échange de messages  ;

  • {direction}, OBLIGATOIRE. Un type xs:token avec l'une des valeurs in ou out, indiquant respectivement si l'incident arrive au service ou en vient. La direction DOIT être cohérente avec celle impliquée par le règlement de propagation d'incident utilisé dans le modèle d'échange de messages de l'opération . Par exemple, si le règlement fault-replaces-message est utilisé, alors un incident se rapportant à un message sortant aurait une valeur de propriété {direction} de out. Par contre, si c'est le règlement message-triggers-fault, alors un incident se rapportant à un message sortant aurait une valeur de propriété {direction} de in puisque l'incident voyage dans la direction opposée de celle du message ;

  • {parent}, OBLIGATOIRE. Le composant Interface Operation qui contient ce composant dans sa propriété {interface fault references}.

Pour chaque composant Interface Fault Reference dans la propriété {interface fault references} d'un composant Interface Operation, la combinaison de ses propriétés {interface fault} et {message label} DOIT être unique .

2.6.2 Représentation XML du composant Interface Fault Reference

<description>
  <interface>
    <operation>
      <infault
            ref="xs:QName"
            messageLabel="xs:NCName"? >
        <documentation />*
      </infault>*
      <outfault
            ref="xs:QName"
            messageLabel="xs:NCName"? >
        <documentation />*
      </outfault>*
    </operation>
  </interface>
</description>

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

  • un nom local [local name] de infault ou outfault ;

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

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

  • 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 (cf. la section 5. Documentation) ;

    2. zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".

2.6.2.1 Item d'information d'attribut ref avec élément possesseur [owner element] infault ou outfault

L'item d'information d'attribut ref se rapporte à un composant d'incident.

L'item d'information d'attribut ref a 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.

Le type de l'item d'information d'attribut ref est xs:QName.

2.6.2.2 Item d'information d'attribut messageLabel avec élément possesseur [owner element] infault ou outfault

L'item d'information d'attribut messageLabel identifie le message dans le modèle d'échange de messages de l'item d'information d'élément operation donné qui est associé à cet incident.

L'item d'information d'attribut messageLabel a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de messageLabel ;

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

Le type de l'item d'information d'attribut messageLabel est xs:NCName.

L'item d'information d'attribut messageLabel DOIT être présent dans la représentation XML d'un composant Interface Fault Reference, avec une propriété {direction} donnée, si la propriété {message exchange pattern} du composant Interface Operation parent [parent] a plus d'un incident avec cette direction . Rappelons que le règlement de propagation d'incident de la propriété {message exchange pattern} définit la relation entre les incidents et les messages. Par exemple, le règlement fault-replaces-message dit que les incidents ont la même direction que les messages, tandis que le règlement message-triggers-fault dit que leurs directions sont opposées.

2.6.3 Correspondance de la représentation XML de Interface Fault Reference aux propriétés de composant

La correspondance de la représentation XML de l'item d'information d'élément de la référence de message (cf. la section 2.6.2 Représentation XML du composant Interface Fault Reference) aux propriétés du composant Interface Fault Reference (cf. la section 2.6.1 Le composant Interface Fault Reference) est décrite dans le tableau 2-6 et utilise les définitions suivantes.

Définir le modèle d'échange de messages de l'item d'information d'élément comme étant la propriété {message exchange pattern} du composant Interface Operation parent [parent].

Définir la direction d'incident de l'item d'information d'élément comme étant in si le nom local de celui-ci est infault, et out si le nom local est outfault.

Définir la direction de message de l'item d'information d'élément comme étant la propriété {direction} du message fictif associé à l'incident comme indiqué par le règlement de propagation d'incident du modèle d'échange de messages.

L'item d'information d'attribut messageLabel d'un item d'information d'élément de référence d'incident d'interface DOIT être présent si le modèle d'échange de messages a plus d'un message fictif dont la propriété {direction} est égale à la direction du message .

Si l'item d'information d'attribut messageLabel d'un item d'information d'élément de référence d'incident d'interface est présent, alors sa valeur réelle DOIT correspondre à la propriété {message label} d'un message fictif dont la propriété {direction} est égale à la direction du message .

Si l'item d'information d'attribut messageLabel d'un item d'information d'élément de référence d'incident d'interface est absent, alors il DOIT y avoir un seul message fictif dont la propriété {direction} est égale à la direction du message .

Définir le libellé de message effectif d'un item d'information d'élément de référence d'incident d'interface comme étant soit la valeur réelle de l'item d'information d'attribut messageLabel si présent, soit la propriété {message label} du message fictif unique dont la propriété {direction} est égale à la direction du message si l'item d'information d'attribut est absent.

Tableau 2-6. Correspondance de la représentation XML aux propriétés du composant Interface Fault Reference
Propriété Valeur
{interface fault} Le composant Interface Fault de la propriété {interface faults} du composant Interface parent, ou d'un composant Interface qui étend celui-ci directement ou indirectement, dont la propriété {name} est égale à la valeur réelle de l'item d'information d'attribut ref.
{message label} Le libellé de message effectif.
{direction} La direction d'incident.
{parent} Le composant Interface Operation correspondant à l'item d'information d'élément interface dans le parent [parent].

2.7 Liaison

2.7.1 Le composant Binding

Un composant Binding décrit un format de message et un protocole de transmission concrets que l'on peut utiliser pour définir une extrémité (cf. la section 2.13 Extrémité). C'est-à-dire qu'un composant Binding définit les détails de mise en œuvre nécessaires pour accéder au service.

Les composants Binding peuvent être utilisés pour décrire de telles informations de manière réutilisable pour toute interface ou spécifiquement pour une interface donnée. En outre, on PEUT définir des informations de liaison par opération (cf. la section 2.9.1 Le composant Binding Operation) au sein d'une interface, en plus de les définir sur toutes les opérations de l'interface.

Si un composant Binding définit des détails de liaison spécifiques d'une opération (par des composants Binding Operation) ou des détails d'incident de liaison (par des composants Binding Fault), alors il DOIT définir l'interface à laquelle il s'applique, pour indiquer de quelle interface les opérations proviennent .

Inversement, un composant Binding qui omet de détailler la liaison spécifique d'une opération et les incidents de liaison PEUT omettre d'indiquer une interface. Les composants Binding qui n'indiquent pas d'interface PEUVENT être utilisés pour définir des détails de liaison indépendants d'une opération pour les composants Service avec diverses interfaces. C'est-à-dire que ces composants Binding sont réutilisables à travers une ou plusieurs interfaces.

Cette spécification ne détaille aucune liaison concrète. La spécification complémentaire Langage de description de services web (WSDL) version 2.0 tome 2 — Compléments [WSDL 2.0 Adjuncts] définit de telles liaisons pour SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework (Second Edition)] et HTTP [IETF RFC 2616]. D'autres spécifications PEUVENT définir des détails de liaison supplémentaires. Ces spécifications sont censées annoter le composant Binding (et ses sous-composants) avec des propriétés supplémentaires et définir la correspondance de la représentation XML à ces propriétés.

Un composant Binding qui définit les liaisons d'un composant Interface DOIT définir les liaisons de toutes les opérations de ce composant Interface . Les liaisons peuvent être établies via des règles par défaut (defaulting rules) permettant de définir des liaisons par défaut pour toutes les opérations et tous les incidents (par exemple, cf. [WSDL 2.0 Adjuncts]), ou en définissant les liaisons de chaque composant Interface Operation et Interface Fault du composant Interface.

De la même façon, à chaque fois qu'un composant Binding réutilisable (c'est-à-dire l'un n'indiquant pas de composant Interface) est appliqué à un composant Interface spécifique dans le contexte d'un composant Endpoint (cf. la section 2.13.1 Le composant Endpoint), le composant Binding DOIT définir les liaisons de chaque composant Interface Operation et Interface Fault du composant Interface, via une combinaison de propriétés définies sur le composant Binding même et les règles de liaison par défaut spécifiques de son type de liaison .

Un composant Binding qui définit les liaisons d'un composant Interface DOIT définir les liaisons de tous les incidents de ce composant Interface référencés par les opérations dans ce composant Interface . Comme pour les opérations, la liaison peut être définie par des règles par défaut. Notez que seuls les incidents réellement référencés par des opérations sont tenus d'avoir des liaisons.

Les liaisons sont des structures nommées qui peuvent être appelées par un nom qualifié QName (cf. la section 2.17 Résolution des noms qualifiés QName). Les composants Endpoint, par exemple, se réfèrent aux liaisons de cette façon.

Les propriétés du composant Binding sont les suivantes :

  • {name}, OBLIGATOIRE. Un nom qualifié xs:QName ;

  • {interface}, OPTIONNELLE. Un composant Interface indiquant l'interface pour laquelle les informations de liaison sont définies ;

  • {type}, OBLIGATOIRE. Un type xs:anyURI. Cette adresse xs:anyURI DOIT être une adresse IRI absolue telle que définie par [IETF RFC 3987. La valeur de cette adresse IRI indique quelle sorte de détails de liaison concrets sont contenus dans ce composant Binding. Les spécifications (telle que [WSDL 2.0 Adjuncts]) qui définissent de tels détails de liaison concrets DOIVENT définir des valeurs appropriées pour cette propriété. La valeur de cette propriété PEUT être le nom d'espace de noms des éléments ou attributs d'extension qui définissent ces détails de liaison concrets ;

  • {binding faults}, OPTIONNELLE. Un ensemble de composants Binding Fault ;

  • {binding operations}, OPTIONNELLE. Un ensemble de composants Binding Operation.

Pour chaque composant Binding dans la propriété {bindings} d'un composant Description, la propriété {name} DOIT être unique .

2.7.2 Représentation XML du composant Binding

<description>
  <binding
        name="xs:NCName" 
        interface="xs:QName"?
        type="xs:anyURI" >
    <documentation />*
    [ <fault /> | <operation /> ]*
  </binding>
</description>

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

2.7.2.1 Item d'information d'attribut name avec élément possesseur [owner element] binding

L'item d'information d'attribut name avec l'item d'information d'attribut targetNamespace de l'item d'information d'élément description forment le nom qualifié QName de la liaison.

L'item d'information d'attribut name a 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.

Le type de l'item d'information d'attribut name est xs:NCName.

2.7.2.2 Item d'information d'attribut interface avec élément possesseur [owner element] binding

L'item d'information d'attribut interface se rapporte, par un nom qualifié QName, à un composant Interface.

L'item d'information d'attribut interface a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de interface ;

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

Le type de l'item d'information d'attribut interface est xs:QName.

2.7.2.3 Item d'information d'attribut type avec élément possesseur [owner element] binding

L'item d'information d'attribut type identifie le type des détails de liaison contenus dans le composant Binding.

L'item d'information d'attribut type a 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.

Le type de l'item d'information d'attribut type est xs:anyURI.

2.7.2.4 Éléments d'extension de liaison

On utilise des éléments d'extension de liaison pour fournir des informations spécifiques d'une liaison particulière. La sémantique de tels items d'information d'élément est décrite par les définitions de ces items d'information d'élément. Ces définitions sont censées annoter le composant Binding avec des propriétés supplémentaires et définir la correspondance de la représentation XML à ces propriétés.

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

La correspondance de la représentation XML de l'item d'information d'élément binding (cf. la section 2.7.2 Représentation XML du composant Binding) aux propriétés du composant Binding (cf. la section 2.7.1 Le composant Binding) est décrite dans le tableau 2-7.

Tableau 2-7. Correspondance de la représentation XML aux propriétés du composant Binding
Propriété Valeur
{name} Le nom qualifié QName dont le nom local est la valeur réelle de l'item d'information d'attribut name et dont le nom d'espace de noms est la valeur réelle de l'item d'information d'attribut targetNamespace de l'item d'information d'élément description parent [parent].
{interface} Le composant Interface en lequel est résolue la valeur de l'item d'information d'attribut interface (cf. la section 2.17 Résolution des noms qualifiés QName), le cas échéant.
{type} La valeur réelle de l'item d'information d'attribut type.
{binding faults} L'ensemble des composants Binding Fault correspondant aux items d'information d'élément fault dans les sous-éléments [children], le cas échéant.
{binding operations} L'ensemble des composants Binding Operation correspondant aux items d'information d'élément operation dans les sous-éléments [children], le cas échéant.

2.8 Incident de liaison

2.8.1 Le composant Binding Fault

Un composant Binding Fault décrit une liaison concrète d'un incident particulier dans une interface vers un format de message concret particulier. Un incident particulier d'une interface est identifié de manière unique par sa propriété {name}.

Notez que l'incident n'apparaît pas de lui-même, il survient dans le cadre d'un échange de messages tel que défini par un composant Interface Operation (et sa contrepartie de liaison, le composant Binding Operation). Ainsi, l'information de liaison d'incident définie dans un composant Binding Fault décrit comment les incidents survenant au cours de l'échange de messages d'une opération seront formatés et transportés.

Les propriétés du composant Binding Fault sont les suivantes :

Pour chaque composant Binding Fault dans la propriété {binding faults} d'un composant Binding, la propriété {interface fault} DOIT être unique . C'est-à-dire que l'on ne peut pas définir plusieurs liaisons pour le même incident dans un composant Binding donné.

2.8.2 Représentation XML du composant Binding Fault

<description>
  <binding>
    <fault
          ref="xs:QName" >
      <documentation />*
    </fault>
  </binding>
</description>

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

  • un nom local [local name] de fault ;

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

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

  • 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 (cf. la section 5. Documentation) ;

    2. zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl". Ces items d'information d'élément sont considérés comme étant des éléments d'extension d'incident de liaison comme décrit ci-dessous (cf. la section 2.8.2.2 Éléments d'extension d'incident de liaison).

2.8.2.1 Item d'information d'attribut ref avec élément possesseur [owner element] fault

L'item d'information d'attribut ref a 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.

Le type de l'item d'information d'attribut ref est xs:QName.

2.8.2.2 Éléments d'extension d'incident de liaison

Les éléments d'extension d'incident de liaison sont utilisés pour fournir des informations spécifiques d'un incident particulier dans une liaison. La sémantique de ces items d'information d'élément est définies par leurs définitions. Ces définitions sont censées annoter le composant Binding Fault avec des propriétés supplémentaires et définir la correspondance de la représentation XML à ces propriétés.

2.8.3 Correspondance de la représentation XML de Binding Fault aux propriétés de composant

La correspondance de la représentation XML de l'item d'information d'élément fault (cf. la section 2.8.2 Représentation XML du composant Binding Fault) aux propriétés du composant Binding Fault (cf. la section 2.8.1 Le composant Binding Fault) est décrite dans le tableau 2-8.

Tableau 2-8. Correspondance de la représentation XML aux propriétés du composant Binding Fault
Propriété Valeur
{interface fault} Le composant Interface Fault correspondant à la valeur réelle de l'item d'information d'attribut ref.
{parent} Le composant Binding correspondant à l'item d'information d'élément binding dans le parent [parent].

2.9 Opération de liaison

2.9.1 Le composant Binding Operation

Le composant Binding Operation décrit le format (ou les formats) de message et l'interaction (ou les interactions) concrets associés à une opération d'interface particulière pour une extrémité donnée. Une opération particulière d'une interface est identifiée de manière unique par sa propriété {name}.

Les propriétés du composant Binding Operation sont les suivantes :

Pour chaque composant Binding Operation dans la propriété {binding operations} d'un composant Binding, la propriété {interface operation} DOIT être unique . C'est-à-dire que l'on ne peut pas définir plusieurs liaisons pour la même opération dans un composant Binding donné.

2.9.2 Représentation XML du composant Binding Operation

<description>
  <binding>
    <operation
          ref="xs:QName" >
      <documentation />*
      [ <input /> | <output /> | <infault /> | <outfault /> ]*
    </operation>
  </binding>
</description>

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

  • un nom local [local name] de operation ;

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

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

  • 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 (cf. la section 5. Documentation) ;

    2. zéro ou plus items d'information d'élément parmi les suivants, dans un ordre quelconque :

2.9.2.1 Item d'information d'attribut ref avec élément possesseur [owner element] operation

L'item d'information d'attribut ref a 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.

Le type de l'item d'information d'attribut ref est xs:QName.

2.9.2.2 Éléments d'extension d'opération de liaison

Les éléments d'extension d'opération de liaison sont utilisés pour fournir des informations spécifiques d'une opération particulière dans une liaison. La sémantique de ces items d'information d'élément est définie par leurs définitions. Ces définitions sont censées annoter le composant Binding Operation avec des propriétés supplémentaires et définir la correspondance de la représentation XML à ces propriétés.

2.9.3 Correspondance de la représentation XML de Binding Operation aux propriétés de composant

La correspondance de la représentation XML de l'item d'information d'élément operation (cf. la section 2.9.2 Représentation XML du composant Binding Operation) aux propriétés du composant Binding Operation est décrite dans le tableau 2-9.

Tableau 2-9. Correspondance de la représentation XML aux propriétés du composant Binding Operation
Propriété Valeur
{interface operation} Le composant Interface Operation correspondant à la valeur réelle de l'item d'information d'attribut ref.
{binding message references} L'ensemble des composants Binding Message Reference correspondant aux items d'information d'élément input et output dans les sous-éléments [children], le cas échéant.
{binding fault references} L'ensemble des composants Binding Fault Reference correspondant aux items d'information d'élément infault et outfault dans les sous-éléments [children], le cas échéant.
{parent} Le composant Binding correspondant à l'item d'information d'élément binding dans le parent [parent].

2.10 Référence de message de liaison

2.10.1 Le composant Binding Message Reference

Un composant Binding Message Reference décrit une liaison concrète d'un message particulier participant à une opération vers un format de message concret particulier.

Les propriétés du composant Binding Message Reference sont les suivantes :

Pour chaque composant Binding Message Reference dans la propriété {binding message references} d'un composant Binding Operation, la propriété {interface message reference} DOIT être unique . C'est-à-dire que le même message ne peut pas être lié deux fois au sein de la même opération.

2.10.2 Représentation XML du composant Binding Message Reference

<description>
  <binding>
    <operation>
      <input
            messageLabel="xs:NCName"? >
        <documentation />*
      </input>
      <output
            messageLabel="xs:NCName"? >
        <documentation />*
      </output>
    </operation>
  </binding>
</description>

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

  • un nom local [local name] de input ou output ;

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

  • zéro ou plus items d'information d'attribut parmi ses attributs [attributes] comme suit :

  • 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 (cf. la section 5. Documentation) ;

    2. zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl". Ces items d'information d'élément sont considérés comme étant des éléments d'extension de référence de message de liaison comme décrit ci-dessous (cf. la section 2.10.2.2 Éléments d'extension de référence de message de liaison).

2.10.2.1 Item d'information d'attribut messageLabel avec élément possesseur [owner element] input ou output

L'item d'information d'attribut messageLabel a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de messageLabel ;

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

Le type de l'item d'information d'attribut messageLabel est xs:NCName.

2.10.2.2 Éléments d'extension de référence de message de liaison

Les éléments d'extension de référence de message de liaison sont utilisés pour fournir des informations spécifiques d'un message particulier dans une opération. La sémantique de ces items d'information d'élément est définie par leurs définitions. Ces définitions sont censées annoter le composant Binding Message Reference avec des propriétés supplémentaires et définir la correspondance de la représentation XML à ces propriétés.

2.10.3 Correspondance de la représentation XML de Binding Message Reference aux propriétés de composant

La correspondance de la représentation XML de l'item d'information d'élément binding (cf. la section 2.10.2 Représentation XML du composant Binding Message Reference) aux propriétés du composant Binding Message Reference est décrite dans le tableau 2-10 et utilise les définitions suivantes.

Définir le modèle d'échange de messages de l'item d'information d'élément comme étant la propriété {message exchange pattern} du composant Interface Operation lié.

Définir la direction de message de l'item d'information d'élément comme étant in si le nom local de celui-ci est input et out si le nom local est output.

Notez que l'item d'information d'attribut messageLabel de l'item d'information d'élément d'une référence de message de liaison doit être présent si le modèle d'échange de messages a plus d'un message fictif (placeholder message) dont la propriété {direction} est égale à la direction de message.

Si l'item d'information d'attribut messageLabel de l'item d'information d'élément d'une référence de message de liaison est présent, alors sa valeur réelle DOIT correspondre à la propriété {message label} d'un message fictif dont la propriété {direction} est égale à la direction de message .

Si l'item d'information d'attribut messageLabel de l'item d'information d'élément d'une référence de message de liaison est absent, alors il DOIT y avoir un message fictif unique dont la propriété {direction} est égale à la direction de message .

Définir le libellé de message effectif (effective message label) d'un item d'information d'élément de référence de message de liaison comme étant soit la valeur réelle de l'item d'information d'attribut messageLabel si présent, soit la propriété {message label} du message fictif unique dont la propriété {direction} est égale à la direction de message si l'item d'information d'attribut est absent.

Tableau 2-10. Correspondance de la représentation XML aux propriétés du composant Binding Message Reference
Propriété Valeur
{interface message reference} Le composant Interface Message Reference dans la propriété {interface message references} du composant Interface Operation lié avec la propriété {message label} égale au libellé de message effectif.
{parent} Le composant Binding Operation correspondant à l'item d'information d'élément operation dans le parent [parent].

2.11 Référence d'incident de liaison

2.11.1 Le composant Binding Fault Reference

Un composant Binding Fault Reference décrit une liaison concrète d'un incident particulier participant à une opération vers un format de message concret particulier.

Les propriétés du composant Binding Fault Reference sont les suivantes :

Pour chaque composant Binding Fault Reference dans la propriété {binding fault references} d'un composant Binding Operation, la propriété {interface fault reference} DOIT être unique . C'est-à-dire que le même incident ne peut pas être lié deux fois au sein de la même opération.

2.11.2 Représentation XML du composant Binding Fault Reference

<description>
  <binding>
    <operation>
      <infault
            ref="xs:QName"
            messageLabel="xs:NCName"?>
        <documentation />*
      </infault>
      <outfault
            ref="xs:QName"
            messageLabel="xs:NCName"?>
        <documentation />*
      </outfault>
    </operation>
  </binding>
</description>

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

2.11.2.1 Item d'information d'attribut ref avec élément possesseur [owner element] infault ou outfault

L'item d'information d'attribut ref a 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.

Le type de l'item d'information d'attribut ref est xs:QName.

2.11.2.2 Item d'information d'attribut messageLabel avec élément possesseur [owner element] infault ou outfault

L'item d'information d'attribut messageLabel a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de messageLabel ;

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

Le type de l'item d'information d'attribut messageLabel est xs:NCName.

2.11.2.3 Éléments d'extension de référence d'incident de liaison

Les éléments d'extension de référence d'incident de liaison sont utilisés pour fournir des informations spécifiques d'un incident particulier dans une opération. La sémantique de ces items d'information d'élément est définie par leurs définitions. Ces définitions sont censées annoter le composant Binding Fault Reference avec des propriétés supplémentaires et définir la correspondance de la représentation XML à ces propriétés.

2.11.3 Correspondance de la représentation XML de Binding Fault Reference aux propriétés de composant

La correspondance de la représentation XML de l'item d'information d'élément binding (cf. la section 2.11.2 Représentation XML du composant Binding Fault Reference) aux propriétés du composant Binding Fault Reference est décrite dans le tableau 2-11 et utilise les définitions suivantes.

Définir le modèle d'échange de messages (message exchange pattern) de l'item d'information d'élément comme étant la propriété {message exchange pattern} du composant Interface Operation lié.

Définir la direction d'incident (fault direction) de l'item d'information d'élément comme étant in si le nom local de celui-ci est infault et out si le nom local est outfault.

Définir la direction de message (message direction) de l'item d'information d'élément comme étant la propriété {direction} du message fictif associé à l'incident, définie par le règlement de propagation d'incident (fault propagation ruleset) du modèle d'échange de messages.

L'item d'information d'attribut messageLabel DOIT être présent si le modèle d'échange de messages a plus d'un message fictif dont la propriété {direction} est égale à la direction de message .

Si l'item d'information d'attribut messageLabel d'un item d'information d'élément de référence d'incident de liaison est présent, alors sa valeur réelle DOIT correspondre à la propriété {message label} d'un message fictif dont la propriété {direction} est égale à la direction de message .

Si l'item d'information d'attribut messageLabel d'un item d'information d'élément de référence d'incident de liaison est absent, alors il DOIT y avoir un message fictif unique dont la propriété {direction} est égale à la direction de message .

Définir le libellé de message effectif (effective message label) d'un item d'information d'élément comme étant soit la valeur réelle de l'item d'information d'attribut messageLabel si présent, soit la propriété {message label} du message fictif unique dont la propriété {direction} est égale à la direction de message si l'item d'information d'attribut est absent.

Il DOIT y avoir un composant Interface Fault Reference dans la propriété {interface fault references} du composant Interface Operation lié dont la propriété {message label} est égale au libellé de message effectif et la propriété {interface fault} est égale à un composant Interface Fault avec une propriété {name} égale à l'item d'information d'attribut ref .

Tableau 2-11. Correspondance de la représentation XML aux propriétés du composant Binding Fault Reference
Propriété Valeur
{interface fault reference} Le composant Interface Fault Reference dans la propriété {interface fault references} du composant Interface Operation lié dont la propriété {message label} est égale au libellé de message effectif et la propriété {interface fault} est égale à un composant Interface Fault avec une propriété {name} égale à la valeur réelle de l'item d'information d'attribut ref.
{parent} Le composant Binding Operation correspondant à l'item d'information d'élément operation dans le parent [parent].

2.12 Service

2.12.1 Le composant Service

Un composant Service décrit un ensemble d'extrémités (cf. la section 2.13 Extrémité) où y est fournie une mise en œuvre déployée particulière du service. Les extrémités (endpoints) sont en effet des lieux de remplacement (alternate places) où le service est fourni.

Les services sont des structures nommées auxquelles on peut se référer par un nom qualifié QName (cf. la section 2.17 Résolution des noms qualifiés QName).

Les propriétés du composant Service sont les suivantes :

Pour chaque composant Service dans la propriété {services} d'un composant Description, la propriété {name} DOIT être unique .

2.12.2 Représentation XML du composant Service

<description>
  <service
        name="xs:NCName" 
        interface="xs:QName" >
    <documentation />*
    <endpoint />+
  </service>
</description>

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

  • un nom local [local name] de service ;

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

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

  • un ou plusieurs items d'information d'élément parmi ses sous-éléments, en ordre, comme suit :

    1. zéro ou plus items d'information d'élément documentation (cf. la section 5. Documentation) ;

    2. un ou plusieurs items d'information d'élément parmi les suivants, dans un ordre quelconque :

      • un ou plusieurs items d'information d'élément endpoint (cf. la section 2.13.2 Représentation XML du composant Endpoint ;

      • zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".

2.12.2.1 Item d'information d'attribut name avec élément possesseur [owner element] service

L'item d'information d'attribut name avec l'item d'information d'attribut targetNamespace de l'item d'information d'élément description forment le nom qualifié QName du service.

L'item d'information d'attribut name a 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.

Le type de l'item d'information d'attribut name est xs:NCName.

2.12.2.2 Item d'information d'attribut interface avec élément possesseur [owner element] service

L'item d'information d'attribut interface identifie l'interface dont le service est une instance.

L'item d'information d'attribut interface a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de interface ;

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

Le type de l'item d'information d'attribut interface est xs:QName.

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

La correspondance de la représentation XML de l'item d'information d'élément service (cf. la section 2.12.2 Représentation XML du composant Service) aux propriétés du composant Service est décrite dans le tableau 2-12.

Tableau 2-12. Correspondance de la représentation XML aux propriétés du composant Service
Propriété Valeur
{name} Le nom qualifié QName dont le nom local est la valeur réelle de l'item d'information d'attribut name et le nom d'espace de noms est la valeur réelle de l'item d'information d'attribut targetNamespace de l'item d'information d'élément description parent [parent].
{interface} Le composant Interface en lequel est résolue la valeur réelle de l'item d'information d'attribut interface (cf. la section 2.17 Résolution des noms qualifiés QName).
{endpoints} Les composants Endpoint correspondant aux items d'information d'élément endpoint dans les sous-éléments [children].

2.13 Extrémité

2.13.1 Le composant Endpoint

Un composant Endpoint définit les particularités d'une extrémité spécifique à laquelle un service donné est disponible.

Les composants Endpoint sont locaux à un composant Service donné (cf. la section A.2 Identificateurs de fragment).

Le composant Binding indiqué par la propriété {binding} d'un composant Endpoint est dit appliqué au composant Interface qui est la valeur de la propriété {interface} du composant Service parent du composant Endpoint. Conformément aux contraintes indiquées ci-dessous, si ce composant Binding a une propriété {interface}, alors la valeur de celle-ci doit être le composant Interface auquel le composant Binding est appliqué.

La propriété {address} est optionnelle afin que d'autres moyens que des adresses IRI puissent être utilisés, par exemple une référence d'extrémité de type WS-Addressing (WS-Addressing Endpoint Reference) [WSA 1.0 Core]. Il est possible également, dans certains scénarios, qu'une adresse ne soit pas nécessaire, auquel cas cette propriété peut être absente.

Les propriétés du composant Endpoint sont les suivantes :

  • {name}, OBLIGATOIRE. Un nom xs:NCName ;

  • {binding}, OBLIGATOIRE. Un composant Binding ;

  • {address}, OPTIONNELLE. Un type xs:anyURI. Cette adresse xs:anyURI DOIT être une adresse IRI absolue comme défini par [IETF RFC 3987. Si présent, la valeur de cette attribut représente l'adresse de réseau où est offert le service indiqué par la propriété {interface} du composant Service parent, via la liaison indiquée par la propriété {binding}. À noter que la présence dans cette propriété de caractères « ? » et « # » peut engendrer des conflits avec ceux potentiels ajoutés par le mécanisme de sérialisation de chaîne de requête, comme défini dans la section 6.8.2 Sérialisation comme type "application/x-www-form-urlencoded" ([WSDL 2.0 Adjuncts] ;

  • {parent}, OBLIGATOIRE. Le composant Service qui contient ce composant dans sa propriété {endpoints}.

Pour chaque composant Endpoint dans la propriété {endpoints} d'un composant Service, la propriété {name} DOIt être unique. Notez que le schéma XML normatif de WSDL 2.0 fait valoir cette contrainte.

Pour chaque composant Endpoint dans la propriété {endpoints} d'un composant Service, la propriété {binding} DOIT soit être un composant Binding avec une propriété {interface} non définie, soit un composant Binding avec une propriété {interface} égale à la propriété {interface} du composant Service .

2.13.2 Représentation XML du composant Endpoint

<description>
  <service>
    <endpoint
          name="xs:NCName" 
          binding="xs:QName"
          address="xs:anyURI"? >
      <documentation />*
    </endpoint>+
  </service>
</description>

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

2.13.2.1 Item d'information d'attribut name avec élément possesseur [owner element] endpoint

L'item d'information d'attribut name avec l'item d'information d'attribut targetNamespace de l'item d'information d'élément description forment le nom qualifié QName de l'extrémité.

L'item d'information d'attribut name a 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.

Le type de l'item d'information d'attribut name est xs:NCName.

2.13.2.2 Item d'information d'attribut binding avec élément possesseur [owner element] endpoint [owner element]

L'item d'information d'attribut binding se rapporte, par un nom qualifié QName, à un composant Binding.

L'item d'information d'attribut binding a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de binding ;

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

Le type de l'item d'information d'attribut binding est xs:QName.

2.13.2.3 Item d'information d'attribut address avec élément possesseur [owner element] endpoint

L'item d'information d'attribut address indique l'adresse de l'extrémité.

L'item d'information d'attribut address a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de address ;

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

Le type de l'item d'information d'attribut address est xs:anyURI.

2.13.2.4 Éléments d'extension d'extrémité

Les éléments d'extension d'extrémité sont utilisés pour fournir des informations spécifiques d'une extrémité particulière dans un serveur. La sémantique de ces items d'information d'élément est définie par leurs définitions. Ces définitions sont censées annoter le composant Endpoint avec des propriétés supplémentaires et définir la correspondance XML à ces propriétés.

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

La correspondance de la représentation XML de l'item d'information d'élément endpoint (cf. la section 2.13.2 Représentation XML du composant Endpoint) aux propriétés du composant Endpoint est décrite dans le tableau 2-13.

Tableau 2-13. Correspondance de la représentation XML aux propriétés du composant Endpoint
Propriété Valeur
{name} La valeur réelle de l'item d'information d'attribut name.
{binding} Le composant Binding en lequel est résolue la valeur réelle de l'item d'information d'attribut binding (cf. la section 2.17 Résolution des noms qualifiés QName ).
{address} La valeur réelle de l'item d'information d'attribut address si présent ; sinon vide.
{parent} Le composant Service correspondant à l'item d'information d'élément service dans le parent [parent].

2.14 Types simples XML Schema 1.0 utilisés dans le modèle de composants

Les types simples XML Schema 1.0 [XML Schema: Datatypes] utilisés dans cette spécifications sont les suivants :

  • xs:token

  • xs:NCName

  • xs:anyURI

  • xs:QName

  • xs:boolean

2.15 Équivalence des composants

Deux instances de composant du même type sont considérées équivalentes si, pour chaque valeur de propriété du premier composant, il y a une propriété correspondante avec une valeur équivalente sur le deuxième composant, et vice versa.

  • Pour les valeurs de type simple (cf. la section 2.14 Types simples XML Schema 1.0 utilisés dans le modèle de composants), cela signifie qu'elle contiennent les mêmes valeurs. Ainsi, deux valeurs de chaîne sont équivalentes si elles contiennent la même séquence de caractères Unicode, comme décrit dans [Character Model for the WWW], ou deux valeurs booléennes le sont si elles contiennent la même valeur canonique (true ou false) ;

  • Les valeurs qui sont des références à d'autres composants sont considérées équivalentes si elles se rapportent à des composants équivalents (comme déterminé précédemment).

  • Les valeurs de listes (list-based values) sont considérées équivalentes si elles ont la même longueur et leurs éléments à des positions correspondantes sont équivalents.

  • Enfin, les valeurs d'ensembles (set-based values) sont considérées équivalentes si, pour chaque valeur dans le premier, il y a une valeur équivalente dans le deuxième, et vice versa.

Les propriétés d'extension qui ne sont pas des valeurs de chaîne, des ensembles de chaînes ou des références DOIVENT décrire les règles d'équivalence de leurs valeurs .

Du fait que les différents composants de niveau supérieur (à savoir, les composants Interface, Binding et Service) soient obligés d'avoir des noms différents, il est possible de déterminer si deux composants de niveau supérieur d'un type donné sont équivalents simplement en comparant leurs propriétés {name}.

Le composant Binding définit par la propriété {binding} d'un composant Endpoint est dit appliqué au composant Interface qui est la valeur de la propriété {interface} du composant Service {parent} du composant Endpoint. Notez que, si ce composant Binding a une propriété {interface}, alors la valeur de celle-ci DOIT être le composant Interface auquel le composant Binding s'applique.

2.16 Espaces de symboles

Cette spécification définit trois espaces de symboles, un pour chaque type de composant de niveau supérieur (Interface, Binding et Service).

Au sein d'un espace de symboles, tous les noms qualifiés (c'est-à-dire les valeurs de propriété {name}) sont uniques. Entre les espaces de symboles, les noms n'ont pas besoin d'être uniques. Ainsi, il est parfaitement cohérent d'avoir, par exemple, une liaison et une interface ayant le même nom.

Dès lors qu'on utilise XML Schema pour l'un des systèmes de typage d'une description WSDL 2.0, il existe six autres espaces de symboles, un pour chacun des types suivants : les déclarations d'élément globales, les déclarations d'attribut globales, les groupes de modèles nommés, les groupes d'attributs nommées, les définitions de type et les contraintes de clé, comme défini par [XML Schema: Structures]. D'autres systèmes de typage peuvent définir des espaces de symboles supplémentaires.

2.17 Résolution des noms qualifiés QName

Dans sa forme sérialisée, WSDL 2.0 utilise beaucoup les références entre composants. Ces références sont réalisées en utilisant le nom qualifié QName (Qualified Name) du composant appelé. Les noms qualifiés QName sont des tuples composés de deux parties : un nom d'espace de noms et un nom local. Le nom d'espace de noms d'un composant est représenté par la valeur de l'item d'information d'attribut targetNamespace de l'item d'information d'élément description parent [parent]. Le nom local est représenté par la propriété {name} du composant.

Les références QName se résolvent en examinant la propriété appropriée du composant Description. Par exemple, pour résoudre le nom qualifié QName d'une interface (tel qu'indiqué par l'item d'information d'attribut interface sur une liaison), on inspecterait la propriété {interfaces} du composant Description.

Si la propriété appropriée du composant Description ne contient pas de composant avec le nom demandé, alors la référence est une référence cassée (broken reference). Un composant Description NE DOIT PAS avoir de telles références cassées .

2.18 Comparaison des adresses URI et des adresses IRI

Cette spécification utilise des adresses URI et IRI absolues pour identifier plusieurs composants et caractéristiques de composants (par exemple, les modèles d'échange de messages et les styles d'opération). Lorsqu'on compare de telles adresses URI et IRI absolues pour déterminer une équivalence (cf. la section 2.15 Équivalence de composants), on DOIT les comparer caractère par caractère comme indiqué dans [IETF RFC 3987.

3. Types

<description>
  <types>
    <documentation />*
    [ <xs:import namespace="xs:anyURI" schemaLocation="xs:anyURI"? /> |
      <xs:schema targetNamespace="xs:anyURI"? /> |
      autres éléments d'extension ]*
  </types>
</description>

Le contenu des messages et des incidents peut être contraint en utilisant des composants de systèmes de typage. Ces contraintes sont fondées sur un modèle de données spécifique et exprimées à l'aide d'un langage de schéma particulier.

Bien que différents modèles de données soient envisageables (au travers d'extensions de WSDL 2.0), cette spécification ne définit qu'une seule méthode pour exprimer des contraintes fondée sur l'ensemble d'information XML [XML Information Set]. En outre, bien que l'on puisse utiliser d'autres langages de schéma pour contraindre l'ensemble d'information XML (à condition que ceux-ci prennent en charge la sémantique d'incorporation ou d'importation du schéma), cette spécification définit seulement l'utilisation de XML Schema [XML Schema: Structures], [XML Schema: Datatypes].

Spécifiquement, les propriétés {element declarations} et {type definitions} du composant Description sont des collections de composants de schéma importés et incorporés qui décrivent les items d'information d'élément de l'ensemble d'information (Infoset).

Lorsqu'on se sert d'extensions pour établir l'utilisation d'un modèle de données non-Infoset, ou d'un langage de contrainte non-XML Schema, on PEUT utiliser l'item d'information d'attribut wsdl:required pour imposer la gestion de cette extension.

Remarque :

La gestion du langage XML Schema du W3C [XML Schema: Structures], [XML Schema: Datatypes] fait partie des critères de conformité des documents WSDL 2.0 (cf. la section 3.1 Utilisation du langage de définition XML Schema du W3C).

Les composants de schéma contenus dans la propriété {element declarations} du composant Description fournissent le système de typage utilisé pour les composants Interface Message Reference et Interface Fault. Les composants Interface Message Reference indiquent leur structure et leur contenu en utilisant les items d'information d'attribut element standards ou, pour les autres langages de schéma où ces concepts ne correspondent pas exactement, en utilisant des extensions d'item d'information d'attribut de remplacement. Les composants Interface Fault se comportent de façon similaire. De telles extensions devraient définir comment elles référencent les composants de système de typage. Ces composants de système de typage PEUVENT apparaître dans des propriétés de collection supplémentaires sur le composant Description.

On peut utiliser des extensions ayant la forme d'items d'information d'attribut pour référencer des contraintes (des définitions de type ou des structures analogues) décrites à l'aide d'autres langages de schéma ou systèmes de typage. De tels composants PEUVENT apparaître dans des propriétés de collection supplémentaires sur le composant Description.

L'item d'information d'élément types englobe les définitions de type de données, fondées sur l'ensemble d'information XML, utilisées pour définir les messages, et a les propriétés d'ensemble d'information suivantes :

3.1 Utilisation du langage de définition XML Schema du W3C

On PEUT utiliser XML Schema comme langage de schéma via une importation ou une incorporation.

Un document WSDL 2.0 NE DOIT PAS référencer des composants XML Schema dans un espace de noms donné sauf si un item d'information d'élément xs:import ou xs:schema pour cet espace de noms est présent ou l'espace de noms est celui de XML Schema (à savoir "http://www.w3.org/2001/XMLSchema") qui contient des types intégrés comme défini dans la spécification XML Schema [XML Schema: Datatypes. C'est-à-dire que l'utilisation de l'item d'information d'élément xs:import ou xs:schema est une condition nécessaire pour permettre le référencement des composants XML Schema, hormis les composants intégrés, au sein d'un document WSDL 2.0. Les types de données XML Schema sont intégrés au modèle de composants WSDL 2.0 et contenus dans la propriété {type definitions} du composant Description. Un document WSDL 2.0 qui référence une déclaration d'élément ou une définition de type de l'espace de noms XML Schema, hormis les types primitifs et dérivés intégrés, DOIT importer le schéma à http://www.w3.org/2001/XMLSchema.

Le tableau 3-1 récapitule les possibilités de référencement (referenceability) des composants de schéma.

Tableau 3-1. Possibilités de référencement des composants de schéma
Représentation XML Possibilité de référencement des composants XML Schema
Inclusion des description description/include Les composants XML Schema dans les propriétés {element declarations} et {type definitions} dans le composant Description inclus sont référençables.
Importation des description description/import Aucun composant XML Schema dans le composant Description importé n'est référençable.
Importation de schéma XML description/types/xs:import Les composants Element Declaration et Type Definition dans l'espace de noms importé sont référençables.
Incorporation de schéma XML description/types/xs:schema Les composants Element Declaration et Type Definition dans le schéma XML incorporé sont référençables.

3.1.1 Importation d'un schéma XML

L'importation d'un schéma XML utilise la syntaxe et la sémantique du mécanisme xs:import définit par XML Schema [XML Schema: Structures], [XML Schema: Datatypes], sauf les différences définies dans cette section et la suivante. Les composants de schéma définis dans l'espace de noms importé sont référençables par nom qualifié QName (cf. la section 2.17 Résolution des noms qualifiés QName). Seuls les composants dans l'espace de noms importé sont référençables dans le document WSDL 2.0. Pour chaque composant dans l'espace de noms importé, un composant correspondant Element Declaration, ou Type Definition, DOIT apparaître respectivement dans la propriété {element declarations}, ou {type definitions}, du composant Description correspondant au document WSDL qui importe le schéma, ou qui importe directement ou indirectement un document WSDL important le schéma . Les composants de schéma qui ne sont pas dans un espace de noms importé NE DOIVENT PAS apparaître dans les propriétés {element declarations} ou {type definitions.

Un item d'information d'élément sous-élément de l'item d'information d'élément types est défini avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de import ;

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

  • un ou deux items d'information d'attribut comme suit :

    • un item d'information d'attribut namespace OBLIGATOIRE comme décrit ci-dessous ;

    • un item d'information d'attribut schemaLocation OPTIONNEL comme décrit ci-dessous.

3.1.1.1 Item d'information d'attribut namespace

L'item d'information d'attribut namespace définit l'espace de noms des déclarations d'éléments et des définitions de types importées du schéma référencé. Le schéma référencé DOIT contenir un item d'information d'attribut targetNamespace sur son item d'information d'élément xs:schema . La valeur de l'item d'information d'attribut targetNamespace de l'item d'information d'élément xs:schema d'un schéma importé DOIT être égale à celle de l'item d'information d'attribut namespace de l'item d'information d'élément import dans le document WSDL 2.0 appelant . Notez qu'un document WSDL 2.0 ne doit pas importer un schéma qui n'a pas d'item d'information d'attribut targetNamespace sur son item d'information d'élément xs:schema. Un tel schéma doit d'abord être inclus (avec xs:include) dans un schéma contenant un item d'information d'attribut targetNamespace sur son item d'information d'élément xs:schema, et il peut alors soit être importé, soit incorporé dans le document WSDL 2.0.

L'item d'information d'attribut namespace a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de namespace ;

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

Le type de l'item d'information d'attribut namespace est xs:anyURI.

3.1.1.2 Item d'information d'attribut schemaLocation

L'item d'information d'attribut schemaLocation, si présent, fournit au processeur XML Schema une indication à propos de la localisation du schéma. Des technologies de mise en cache et de catalogage peuvent fournir de meilleures informations que cette indication.

L'item d'information d'attribut schemaLocation a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de schemaLocation ;

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

Le type de l'item d'information d'attribut schemaLocation est xs:anyURI.

Chaque référence QName doit se résoudre (cf. la section 2.17 Résolution des noms qualifiés QName). Notez que, pour la résolution de références QName de définitions de schéma, le nom d'espace de noms doit être importé par le document WSDL 2.0 appelant (cf. la section 3.1 Utilisation du langage de définition XML Schema du W3C).

3.1.2 Incorporation de schéma XML

L'incorporation d'un schéma XML utilise l'item d'information d'élément xs:schema de niveau supérieur existant défini par XML Schema [XML Schema: Structures]. Conceptuellement, on peut assimiler l'incorporation au simple copier-coller d'un document de schéma existant quelque part dans l'item d'information d'élément types.

Les composants de schéma définis et déclarés dans le document de schéma incorporé sont référençables par nom qualifié QName (cf. la section 2.17 Résolution des noms qualifiés QName). Seuls les composants définis et déclarés dans le schéma même et les composants qu'il inclut via xs:include sont référençables. Pour chaque composant défini et déclaré dans le document de schéma incorporé ou inclus par xs:include, un composant Element Declaration, ou Type Definition, DOIT apparaître respectivement dans la propriété {element declarations}, ou {type definitions}, du composant Description correspondant au document WSDL qui contient le schéma, ou qui importe directement ou indirectement un document WSDL qui contient le schéma . Les composants de schéma non définis ou déclarés dans le document de schéma incorporé, ou inclus par xs:include, NE DOIVENT PAS apparaître dans les propriétés {element declarations} ou {type definitions.

Notez que les composants dans l'espace de noms que le schéma incorporé importe via xs:import ne sont pas automatiquement référençables depuis le document WSDL 2.0 contenant le schéma incorporé. Si l'espace de noms référencé dans un nom qualifié QName est contenu dans un schéma incorporé, il PEUT être importé sans attribut schemaLocation, tant que le schéma incorporé est résolu dans le modèle de composants courant.

Notez que les composants définis dans un schéma XML incorporé ne sont pas automatiquement référençables au sein du document WSDL 2.0 qui a importé (avec wsdl:import) le document WSDL 2.0 incorporant le schéma (cf. la section 4.2 Importation des descriptions pour plus de détails). Pour cette raison, il est recommandé de placer les documents de schéma XML dans des documents séparés et de les importer à l'aide de xs:import, plutôt que de les incorporer à un document WSDL 2.0.

À l'intérieur d'un schéma XML incorporé, on PEUT utiliser les items d'information d'élément xs:import et xs:include pour référencer d'autres schémas XML incorporés dans le même document WSDL 2.0 ou ailleurs, à condition de définir une valeur appropriée, telle qu'un identificateur de fragment (cf. [XML Schema: Structures], section 4.3.1) pour leurs items d'information d'attribut schemaLocation. Pour xs:import, l'attribut schemaLocation n'est pas nécessaire tant que l'espace de noms est résolu dans le modèle de composants courant. La sémantique de tels items d'information d'élément est régie exclusivement par la spécification XML Schema [XML Schema: Structures].

Un document WSDL 2.0 PEUT incorporer deux schémas ou plus du même targetNamespace. Ainsi, deux (ou plus) schémas incorporés peuvent avoir le même targetNamespace, à condition qu'ils ne définissent pas les même éléments ou types. Un document WSDL 2.0 NE DOIT PAS définir le même élément ou type dans plusieurs schémas incorporés . Notez que le processeur XML Schema sous-jacent a la charge d'établir l'ensemble cohérent des composants de schéma.

L'item d'information d'élément xs:schema a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de schema ;

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

  • des items d'information d'attribut supplémentaires OPTIONNELS comme défini pour l'item d'information d'élément xs:schema par la spécification XML Schema ;

  • zéro ou plus items d'information d'élément sous-élément comme défini pour item d'information d'élément xs:schema par la spécification XML Schema.

3.1.3 Références des déclarations d'élément et des définitions de type

Qu'elles soient incorporées ou importées, les déclarations d'élément globales présentes dans un schéma sont référençables depuis un composant Interface Message Reference ou Interface Fault. De même, indépendemment de ce qu'elles sont incorporées ou importées, les définitions de type globales présentes dans un schéma sont référençables depuis d'autres composants.

Une déclaration xs:element globale nommée est référençable depuis l'item d'information d'attribut element d'un item d'information d'élément input, output (cf. la section 2.5.2 Représentation XML du composant Interface Message Reference) ou fault (cf. la section 2.3.2 Représentation XML du composant Interface Fault). Le nom qualifié QName de la déclaration d'élément est construit à partir du targetNamespace du schéma et de la valeur de l'item d'information d'attribut name de l'item d'information d'élément xs:element. Notez que l'item d'information d'attribut element ne peut pas se référer à une définition globale xs:simpleType ou xs:complexType, puisque celles-ci se trouvent dans un espace de symboles différent des déclarations d'élément globales. Si l'item d'information d'attribut element contenait par erreur le nom qualifié QName d'une définition de type, cela se traduirait par l'échec de la résolution de la déclaration d'élément.

3.2 Utilisation d'autres langages de schéma

Puisqu'on ne peut pas raisonnablement attendre d'un seul langage de schéma qu'il puisse décrire tous les contenus et contraintes possibles des composants Interface Message Reference et Interface Fault, WSDL 2.0 permet d'indiquer d'autres langages de schéma via des éléments d'extension. Un item d'information d'élément d'extension PEUT apparaître sous l'item d'information d'élément types pour identifier le langage de schéma employé et localiser l'instance de schéma définissant la grammaire des composants Interface Message Reference et Interface Fault. Selon le langage de schéma utilisé, on PEUT définir un item d'information d'élément permettant son incorporation, si et seulement si le langage de schéma est exprimable en XML.

Une définition de syntaxe d'extension pour un autre langage de schéma DOIT inclure la déclaration d'un item d'information d'élément, destiné à apparaître comme sous-élément de l'item d'information d'élément wsdl:types, lequel référence, nomme et localise l'instance de schéma (un item d'information d'élément import. La définition d'extension DEVRAIT, au besoin, définir les propriétés supplémentaires du composant Description (et les attributs d'extension) pour tenir les composants du système de typage référencé. Il est aussi prévu de définir des attributs d'extension supplémentaires pour les composants Interface Message Reference et Interface Fault, en même temps qu'un mécanisme de résolution des valeurs de ces attributs en un composant de système de typage importé particulier.

Une définition de syntaxe d'extension d'un autre langage de schéma DOIT utiliser un espace de noms différent de celui de XML Schema . L'espace de noms de l'autre langage de schéma est utilisé pour les items d'information d'élément sous-éléments de l'item d'information d'élément wsdl:types et pour tous les items d'information d'attribut d'extension apparaissant sur d'autres composants. L'espace de noms utilisé pour un autre langage de schéma DOIT être une adresse IRI absolue .

Cf. la note [WSDL 2.0 Alternative Schema Languages Support] pour des exemples d'utilisation d'autres langages de schéma. Ces exemples réutilisent la propriété {element declarations} du composant Description et les items d'information d'attribut element des items d'information d'élément wsdl:input, wsdl:output et wsdl:fault.

Remarque :

Cette spécification ne définit pas le comportement d'un document WSDL 2.0 qui utiliserait plusieurs langages de schéma pour décrire simultanément des composants de système de typage.

3.3 Description de messages en rapport à des services et des extrémités

Les services web peuvent échanger des messages qui s'adressent à d'autres services web ou extrémités de services web. Si l'interface ou la liaison de ces services ou extrémités référencés sont connues au moment de la description, on peut alors inclure utilement cette information dans le document WSDL 2.0 qui décrit le service web. WSDL 2.0 fournit deux items d'information d'attribut globaux (wsdlx:interface et wsdlx:binding) que l'on peut utiliser pour annoter des composants XML Schema ou des composants d'autres langages de description de types.

WSDL 2.0 définit l'utilisation de ces items d'information d'attribut globaux pour annoter les composants XML Schema qui utilisent le type simple xs:anyURI dans un item d'information d'élément ou un item d'information d'attribut pour les adresses d'extrémité qui correspondent à la propriété {address} du composant Endpoint. Toutefois, l'utilisation de ces items d'information d'attribut globaux n'est pas limitée aux types simples fondés sur xs:anyURI. On peut les utiliser pour tous les autres types utilisés pour désigner des services web ou des extrémités de services web, par exemple, une référence d'extrémité WS-Addressing [WSA 1.0 Core]. Cf. l'introduction [WSDL 2.0 Primer] pour plus de renseignements et des exemples.

3.3.1 Item d'information d'attribut wsdlx:interface

WSDL 2.0 fournit un item d'information d'attribut global avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de interface ;

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

Le type de l'item d'information d'attribut wsdlx:interface est un nom qualifié xs:QName qui définit la propriété {name} d'un composant Interface .

3.3.2 Item d'information d'attribut wsdlx:binding

WSDL 2.0 fournit un item d'information d'attribut global avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de binding ;

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

Le type de l'item d'information d'attribut wsdlx:binding est un nom qualifié xs:QName qui définit la propriété {name} d'un composant Binding .

3.3.3 Cohérence de wsdlx:interface et wsdlx:binding

Les attributs wsdlx:interface et wsdlx:binding peuvent être utilisés indépendamment ou ensemble. Si wsdlx:interface et wsdlx:binding sont utilisés ensemble, alors ils DOIVENT satisfaire aux mêmes règles de cohérence qui s'appliquent à la propriété {interface} d'un composant Service et à la propriété {binding} d'un composant Endpoint niché, c'est-à-dire que la liaison se réfère soit à l'interface du service, soit ne se réfère à aucune interface .

3.3.4 Utilisation de wsdlx:interface et wsdlx:binding avec xs:anyURI

Les attributs wsdlx:interface et wsdlx:binding sont utilisés pour décrire des items d'information d'élément et des items d'information d'attribut dont le type est xs:anyURI, ou une restriction de celui-ci, ainsi que des messages qui contiennent la propriété {address} d'un composant Endpoint. Cela se fait en incluant l'item d'information d'attribut wsdlx:interface ou wsdlx:binding dans l'item d'information d'élément xs:element, xs:simpleType ou xs:attribute du composant XML Schema correspondant.

4. Modularisation des descriptions WSDL 2.0

WSDL 2.0 fournit deux mécanismes pour modulariser les descriptions WSDL 2.0. Ces mécanismes aident à produire des descriptions de services web plus claires en autorisant une séparation des divers composants d'une description. Une telle séparation peut être effectuée selon le niveau d'abstraction d'un ensemble donné de composants, ou selon l'affiliation d'espace de noms exigée d'un ensemble donné de composants, ou même selon un autre regroupement tel que l'applicabilité d'une application.

Les deux mécanismes agissent au niveau des composants WSDL 2.0 et non au niveau des ensembles d'information XML ou des sérialisations XML 1.0.

4.1 Inclusion des descriptions

<description>
  <include
        location="xs:anyURI" >
    <documentation />*
  </include>
</description>

L'item d'information d'élément include de WSDL 2.0 permet de séparer les différents composants d'une définition de service, appartenant au même espace de noms cible, en documents WSDL 2.0 indépendants.

L'item d'information d'élément include de WSDL 2.0 est modélisé d'après l'item d'information d'élément include de XML Schema (cf. [XML Schema: Structures], section 4.2.3 Références des composants de schéma dans le même espace de noms). Spécifiquement, on peut l'utiliser pour inclure les composants de descriptions WSDL 2.0 partageant un espace de noms cible avec la description incluante. Les composants dans la clôture transitive (transitive closure) des documents WSDL 2.0 inclus deviennent des parties du composant Description du document WSDL 2.0 incluant. Les composants inclus peuvent être référencés par leur nom qualifié QName. Puisque toutes les descriptions WSDL 2.0 ont un espace de noms cible, notez qu'aucune inclusion sans espace de noms — parfois appelée « inclusion déguisée » (chameleon include) — n'a jamais lieu dans WSDL 2.0.

Une inclusion mutuelle (mutual include) est l'inclusion directe par un document WSDL 2.0 d'un autre document WSDL 2.0 qui inclut le premier. Une inclusion circulaire (circular inclusion) produit le même effet avec une indirection plus grande (par exemple, A inclut B, B inclut C, et C inclut A). L'inclusion multiple d'un seul document WSDL 2.0 se résout en un seul ensemble de composants, comme si le document n'était inclus qu'une seule fois. Les inclusions mutuelles, multiples et circulaires sont explicitement permises et ne représentent pas des redéfinitions multiples des mêmes composants.

L'item d'information d'élément include a les propriétés suivantes :

  • un nom local [local name] de include ;

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

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

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

    • zéro ou plus items d'information d'élément documentation (cf. la section 5. Documentation) ;

    • zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le noms d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".

4.1.1 Item d'information d'attribut location avec élément possesseur [owner element] include

L'item d'information d'attribut location a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de location ;

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

Un item d'information d'attribut location est de type xs:anyURI. Sa valeur réelle est l'adresse de l'emplacement d'informations à propos de l'espace de noms identifié par l'item d'information d'attribut targetNamespace de l'item d'information d'élément description contenant.

L'adresse IRI indiquée par location DOIT se résoudre en un document WSDL 2.0  (cf. la section 7. Localisation des documents WSDL 2.0).

La valeur réelle de l'item d'information d'attribut targetNamespace du document WSDL 2.0 inclus DOIT correspondre à la valeur réelle de l'item d'information d'attribut targetNamespace de l'item d'information d'élément description parent [parent] de l'item d'information d'élément include .

4.2 Importation des descriptions

<description>
  <import
        namespace="xs:anyURI" location="xs:anyURI"? >
    <documentation />*
  </import>
</description>

Chaque composant de niveau supérieur WSDL 2.0 est associé à un espace de noms. Chaque document WSDL 2.0 porte un item d'information d'attribut targetNamespace sur son item d'information d'élément wsdl:description. Cet attribut associe le document à un espace de noms cible qui devient donc également l'espace de noms de chaque composant de niveau supérieur WSDL 2.0 défini dans ce document. Tout autre espace de noms que l'espace de noms du document est dit un espace de noms extérieur (foreign namespace). Tout composant associé à un espace de noms extérieur est dit un composant extérieur (foreign component). Cette section décrit la syntaxe et les mécanismes par lesquels on peut créer des références depuis un document WSDL 2.0 vers des composants extérieurs. Outre cette syntaxe, il existe une fonction (facility) optionnelle pour suggérer l'adresse IRI d'un document WSDL 2.0 contenant des définitions de composants extérieurs.

L'item d'information d'élément import de WSDL 2.0 est modelé d'après l'item d'information d'élément import de XML Schema (cf. [XML Schema: Structures], section 4.2.3 Références des composants de schéma dans le même espace de noms). Spécifiquement, on peut l'utiliser pour importer des composants WSDL 2.0 d'un espace de noms extérieur. L'item d'information d'élément import WSDL 2.0 identifie un espace de noms extérieur. La présence d'un item d'information d'élément import WSDL 2.0 signale que le document WSDL 2.0 peut contenir des références vers des composants extérieurs. L'item d'information d'élément wsdl:import apparaît donc comme une déclaration en avance pour des espaces de noms extérieurs.

Comme pour un schéma XML, tout document WSDL 2.0 qui référence un composant extérieur DOIT avoir un item d'information d'élément wsdl:import pour l'espace de noms extérieur associé (mais qui ne contient pas forcément un item d'information d'attribut location identifiant le document WSDL 2.0 dans lequel le composant référencé est défini) . À d'autres égards, la visibilité des composants est envahissante : si deux documents WSDL 2.0 importent le même espace de noms, alors ils auront accès aux mêmes composants de l'espace de noms importé (c'est-à-dire, indépendamment des valeurs d'item d'information d'attribut location, le cas échéant, fournies sur les items d'information d'élément wsdl:import respectifs).

L'utilisation de l'item d'information d'élément wsdl:import est une condition nécessaire pour mettre à la disposition d'un document WSDL 2.0 des composants extérieurs. C'est-à-dire qu'un document WSDL 2.0 ne peut référencer des composants extérieurs que s'il contient un item d'information d'élément wsdl:import pour l'espace de noms extérieur associé.

Si un document WSDL 2.0 contient plusieurs items d'information d'élément wsdl:import pour une valeur donnée de l'item d'information d'attribut namespace, alors ceux-ci DOIVENT fournir des valeurs différentes pour l'item d'information d'attribut location . La répétition de l'item d'information d'élément wsdl:import pour la même valeur de namespace PEUT être utilisée comme méthode pour fournir des emplacements de remplacement (alternative locations) où trouver des informations à propos d'un espace de noms donné.

De plus, cette spécification n'impose pas que l'item d'information d'attribut location soit résolvable. S'il n'est pas résolvable, aucune information à propos de l'espace de noms importé n'est fournie par cet item d'information d'élément wsdl:import. Cette absence d'information peut éventuellement faire que des noms qualifiés QName dans d'autres parties d'un composant Description WSDL 2.0 deviennent des références cassées (cf. la section 2.17 Résolution des noms qualifiés QName). Ces références cassées ne sont pas attribuées à l'item d'information d'élément wsdl:import mais sont plutôt des manquements aux conditions de résolution des noms qualifiés QName qui doivent être détectés comme décrit dans la section 2.17 Résolution des noms qualifiés QName.

L'item d'information d'élément import a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de import 

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

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

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

    • zéro ou plus items d'information d'élément documentation (cf. la section 5. Documentation) ;

    • zéro ou plus items d'information d'élément, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl".

4.2.1 Item d'information d'attribut namespace

L'item d'information d'attribut namespace a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de namespace ;

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

L'item d'information d'attribut namespace est de type xs:anyURI. Sa valeur réelle indique que le document WSDL 2.0 contenant PEUT contenir des références qualifiées à des composants WSDL 2.0 dans cet espace de noms (via un ou plusieurs préfixes définis par des déclarations d'espace de noms de façon normale). Cette valeur NE DOIT PAS correspondre à la valeur réelle de l'item d'information d'attribut targetNamespace dans le document WSDL 2.0 englobant . Si l'attribut location dans l'item d'information d'élément import est résolvable, alors il DOIT référencer un document WSDL 2.0 . Si l'item d'information d'attribut location de l'item d'information d'élément import est résolvable, alors la valeur réelle de l'item d'information d'attribut namespace DOIT être identique à la valeur réelle de l'item d'information d'attribut targetNamespace du document WSDL 2.0 référencé (cf. la section 7. Localisation des documents WSDL 2.0.

4.2.2 Item d'information d'attribut location avec élément possesseur [owner element] import

L'item d'information d'attribut location a les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de location ;

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

L'item d'information d'attribut location est de type xs:anyURI. Si présent, sa valeur réelle donne une indication de l'endroit où trouver une sérialisation d'un document WSDL 2.0 avec des définitions pour l'espace de noms importé.

L'item d'information d'attribut location est optionnel. Cela permet de construire des composants WSDL 2.0 à partir d'autres informations qu'une sérialisation XML 1.0 d'un document WSDL 2.0. Cela permet aussi de développer des processeurs WSDL 2.0 qui ont la connaissance préalable (c'est-à-dire intégrée) de certains espaces de noms.

4.3 Extensions

La sémantique d'une extension NE DOIT PAS dépendre de la façon dont les composants sont amenés dans une instance de modèle de composants via <import> ou <include> . C'est-à-dire que les composants définis par un document WSDL 2.0 sont déterminés par le contenu du document, sauf pour la résolution des références à d'autres composants définis dans d'autres documents et tout traitement suivant, autorisé par la spécification de l'extension, qui dépend de la résolution en leurs composants réels de ces références.

Cette restriction du comportement des extensions permet aux documents WSDL 2.0 d'être modularisés de façon flexible et traités efficacement. En comparaison, notez que le mécanisme dit d'inclusion déguisée (chameleon include) de XML Schema, qui permet d'inclure un schéma sans espace de noms dans un document de schéma qui en a un, enfreint cette restriction puisque l'espace de noms des composants XML Schema inclus est déterminé par le document XML Schema incluant (cf. [XML Schema: Structures], section 4.2.1 Assembler un schéma pour un seul espace de noms cible à partir de plusieurs documents de définition de schéma).

5. Documentation

<documentation>
  [extension elements]*
</documentation>

WSDL 2.0 utilise l'item d'information d'élément documentation optionnel comme conteneur d'une documentation lisible par un humain ou interprétable par une machine. Le contenu de l'item d'information d'élément se compose d'items d'information de caractère et d'items d'information d'élément arbitraires (contenu de type "mixed" dans XML Schema [XML Schema: Structures]). L'item d'information d'élément documentation est permis dans tout item d'information d'élément WSDL 2.0.

Comme d'autres items d'information d'élément dans l'espace de noms "http://www.w3.org/ns/wsdl", l'item d'information d'élément documentation admet des items d'information d'attribut, qualifiés dans un nom d'espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl". On PEUT utiliser l'attribut xml:lang (cf. [XML 1.0]) pour indiquer la langue employée dans le contenu de l'item d'information d'élément documentation.

L'item d'information d'élément documentation a les propriétés suivantes :

6. Extensibilité du langage

Le schéma de WSDL 2.0 a un modèle d'extensibilité en deux parties fondé sur des éléments et attributs qualifiés dans un espace de noms. Une extension est identifiée par le nom qualifié QName composé de l'adresse IRI de son espace de noms et du nom de son élément ou attribut. La signification d'une extension DEVRAIT être définie (directement ou indirectement) dans un document disponible à l'adresse IRI de son espace de noms .

6.1 Extensibilité fondée sur des éléments

WSDL 2.0 permet de définir des extensions en fonction d'items d'information d'élément. Là où indiqué, WSDL 2.0 admet la présence d'items d'information d'élément qualifiés dans un espace de noms dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl" parmi les sous-éléments [children] d'items d'information d'élément spécifiques dont le nom d'espace de noms [namespace name] est "http://www.w3.org/ns/wsdl". Ces items d'information d'élément PEUVENT servir à annoter des structures WSDL 2.0 telles que des interfaces, opérations, etc.

Les propriétés des extensions s'ajoutent à celles existantes des composants dans le modèle de composants. La spécification d'un item d'information d'élément d'extension devrait inclure les définitions de telles propriétés et la correspondance de la représentation XML de l'extension aux propriétés dans le modèle de composants.

Le schéma de WSDL 2.0 définit un type de base à utiliser par les éléments d'extension. L'exemple 6-1 montre la définition du type. L'utilisation de ce type comme type de base est optionnelle.

Exemple 6-1. Type de base pour les éléments d'extension

<xs:complexType name='ExtensionElement' abstract='true' >
  <xs:attribute ref='wsdl:required' use='optional' />
</xs:complexType>

Les éléments d'extension sont utilisés couramment pour indiquer une liaison spécifique d'une technologie. Ils permettent les innovations dans le domaine des protocoles de réseau et de message sans devoir réviser la spécification WSDL 2.0 de base. WSDL 2.0 recommande que les spécifications définissant de tels protocoles définissent aussi toutes les extensions WSDL 2.0 nécessaires utilisées pour décrire ces protocoles ou formats.

6.1.1 Extensions obligatoires

Les éléments d'extension peuvent être marqués comme obligatoires en les annotant avec un item d'information d'attribut wsdl:required (cf. la section 6.1.2 Item d'information d'attribut required) avec une valeur de "true". Une extension obligatoire est une extension qui PEUT changer la signification de l'élément auquel elle est associée, de telle sorte que la signification de l'élément n'est plus régie par cette spécification. Au contraire, la signification de l'élément contenant l'extension obligatoire est régie par cette extension. Ainsi, la définition de la signification de l'élément est déléguée à la spécification qui définit l'extension.

Une extension non marquée comme obligatoire NE DOIT PAS invalider la signification d'une partie quelconque d'un document WSDL 2.0 . Ainsi, une extension non obligatoire fournit simplement une description supplémentaire des capacités du service. Cette spécification ne fournit aucun mécanisme pour marquer comme obligatoire les attributs d'extension. De fait, aucun attribut d'extension n'est obligatoire.

Remarque :

Une extension obligatoire est considérée comme telle parce qu'elle a la capacité de changer la signification de l'élément auquel elle est associée. Ainsi, la signification de l'élément ne sera peut-être pas entièrement comprise sans que l'extension associée le soit. À l'inverse, une extension non obligatoire peut être ignorée en toute sécurité, sans risque de méprise pour le reste du document WSDL 2.0.

Si un document WSDL 2.0 déclare une extension comme étant optionnelle (c'est-à-dire non obligatoire), alors le service web NE DOIT PAS supposer que le client gère cette extension, sauf si le service web sait (par un autre moyen) que le client a en fait choisi d'engager et de gérer cette extension .

Remarque :

Un objectif primordial d'une extension est d'indiquer formellement (c'est-à-dire, d'une façon interprétable par une machine) qu'une caractéristique ou convention particulières est prise en charge ou est nécessaire. Cela permet aux technologies (toolkits) comprenant l'extension de l'engager automatiquement, tandis qu'à celles qui ne comprennent pas encore une extension obligatoire d'attirer éventuellement l'attention d'un opérateur sur elle pour un traitement manuel.

Si un service web oblige un client à suivre une convention particulière probablement automatisable dans des technologies WSDL 2.0, alors cette convention DEVRAIT être indiquée dans le document WSDL 2.0 comme extension wsdl:required, plutôt que d'être simplement communiquée hors bande (out of band), même si cette convention n'est pas actuellement mise en œuvre dans les technologies WSDL 2.0.

Cette pratique aidera à prévenir les problèmes d'interopérabilité qui peuvent survenir si une technologie nécessite une convention particulière non indiquée dans le document WSDL 2.0, alors qu'une autre technologie ne réalisera pas que cette convention est nécessaire. Elle facilitera aussi un traitement automatique futur par des technologies WSDL 2.0.

Par contre, un client PEUT engager une extension déclarée comme étant optionnelle dans le document WSDL 2.0. Le service web DOIT donc gérer chaque extension déclarée comme étant optionnelle dans le document WSDL 2.0, en plus de gérer chaque extension déclarée comme étant obligatoire .

Remarque :

Si un contrôle des extensions plus fin et sensible à la direction est souhaité, alors ces extensions peuvent être conçues de façon à dépendre de la direction (depuis le client ou depuis le service web) pour marquer séparément comme obligatoire ou optionnelle l'une ou l'autre direction. Par exemple, au lieu de définir une seule extension pour régir les deux directions, on peut définir deux extensions, une pour chaque direction.

La validité d'un document WSDL 2.0 ne peut être évaluée que dans le contexte de l'ensemble des extensions gérées. Un document WSDL 2.0 contenant une extension obligatoire mais non gérée est invalide par rapport à cet ensemble d'extensions gérées.

6.1.2 Item d'information d'attribut required

WSDL 2.0 fournit un item d'information d'attribut global 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] de "http://www.w3.org/ns/wsdl".

Le type de l'item d'information d'attribut required est xs:boolean. Sa valeur par défaut est "false" (ainsi les extensions ne sont pas obligatoires par défaut).

6.2 Extensibilité fondée sur des attributs

WSDL 2.0 permet à des items d'information d'attribut, qualifiés dans un espace de noms, dont le nom d'espace de noms [namespace name] n'est pas "http://www.w3.org/ns/wsdl", d'apparaître sur tout item d'information d'élément dont le nom d'espace de noms est "http://www.w3.org/ns/wsdl". Ces items d'information d'attribut peuvent être utilisés pour annoter des structures WSDL 2.0 telles que des interfaces, des liaisons, etc.

WSDL 2.0 n'offre aucun mécanisme pour marquer des items d'information d'attribut d'extension comme étant obligatoires.

6.3 Sémantique de l'extensibilité

Comme indiqué précédemment, la présence d'éléments et d'attributs d'extension se traduira par des propriétés supplémentaires apparaissant dans le modèle de composants.

La présence d'un élément ou d'un attribut d'extension optionnel PEUT donc augmenter la sémantique d'un document WSDL 2.0 sans que cela invalide la sémantique existante. Au contraire, la présence d'un élément d'extension obligatoire PEUT altérer la sémantique d'un document WSDL 2.0 d'une manière qui invalide la sémantique existante.

Les éléments d'extension NE DEVRAIENT PAS altérer la sémantique existante d'une façon qui serait susceptible d'embrouiller les utilisateurs.

Remarque :

En revanche, notez que si le client et le service savent tous deux qu'une extension optionnelle a été engagée (par exemple, parce que le service aura reçu un message engageant explicitement cette extension), alors la sémantique de cette extension prend le pas sur ce que le document WSDL 2.0 indiquait. Ainsi, le document WSDL 2.0 pouvait indiquer d'utiliser un schéma de message XML mais également une extension de sécurité optionnelle pour chiffrer le message. Si l'extension de sécurité est engagée, alors les messages chiffrés ne seront plus conformes au schéma de message indiqué (jusqu'à leur déchiffrement).

Remarque :

Les auteurs d'éléments d'extension devraient s'assurer d'inclure dans la spécification de ces éléments une déclaration claire des exigences pour la conformité des documents (cf. la section 1.3 Conformité des documents).

Remarque :

Les auteurs d'éléments d'extension pouvant se manifester comme des propriétés du composant Description devraient avoir conscience de l'impact des imports sur leurs extensions, ou de leurs extensions sur les imports. Au sein du modèle de composants, il n'est pas possible de définir des extensions ayant une portée réelle égale à celle d'un fichier contenant. Par conséquent, les extensions qui modifient le comportement des composants contenus dans une description peuvent aussi modifier à l'improviste celui des composants dans les descriptions importées si l'on n'y prend pas garde.

7. Localisation des documents WSDL 2.0

Un document WSDL 2.0 est un item d'information d'élément description qui est soit la racine de document d'un document XML, soit un élément au sein d'un document XML. La localisation (location) d'un document WSDL 2.0 PEUT donc être indiquée par l'adresse IRI d'une ressource XML dont la racine de document est un item d'information d'élément description, ou la référence IRI d'un item d'information d'élément description au sein d'une ressource XML.

Au titre de vocabulaire XML, les documents WSDL 2.0, les fragments de document WSDL 2.0 ou les références QName à des composants WSDL 2.0 PEUVENT apparaître au sein d'autres documents XML. Cette spécification définit un attribut global (wsdlLocation) pour aider à la résolution des noms qualifiés QName (cf. la section 2.17 Résolution des noms qualifiés QName). Cet attribut permet l'annotation d'un élément contenant de telles références pour indiquer où trouver les documents WSDL 2.0 d'un ou de plusieurs espaces de noms. En particulier, cet attribut peut se révéler utile lorsqu'on utilise des références de service dans des échanges de messages.

L'attribut global wsdlLocation est définit dans l'espace de noms "http://www.w3.org/ns/wsdl-instance" (désigné désormais ici par « wsdli:wsdlLocation » pour la brièveté). Cet attribut PEUT apparaître sur tout élément XML admettant la présence d'attributs d'autres espaces de noms. Il NE DOIT PAS apparaître sur un élément wsdl:description ou l'un de ses sous-éléments ou descendants .

On peut trouver le document XML Schema normatif [XML Schema: Structures], [XML Schema: Datatypes] de l'espace de noms wsdli:wsdlLocation à http://www.w3.org/ns/wsdl-instance.

7.1 Item d'information d'élément wsdli:wsdlLocation

WSDL 2.0 fournit un item d'information d'attribut global avec les propriétés d'ensemble d'information suivantes :

  • un nom local [local name] de wsdlLocation ;

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

Le type de l'item d'information d'attribut wsdlLocation est une liste de xs:anyURI. Sa valeur réelle DOIT être une liste de couples d'adresse IRI, où la première adresse IRI d'un couple DOIT être une adresse IRI absolue, comme défini dans [IETF RFC 3987], indiquant un nom d'espace de noms WSDL 2.0 (ou WSDL 1.1), et la deuxième une indication de la localisation d'un document WSDL 2.0 définissant des composants WSDL 2.0 (ou des éléments WSDL 1.1 [WSDL 1.1]) pour ce nom d'espace de noms . La deuxième adresse IRI d'un couple PEUT être absolue ou relative. Pour chaque couple d'adresses IRI, si l'adresse IRI de localisation du couple est résolvable, alors elle DOIT référencer un document WSDL 2.0 (ou WSDL 1.1) dont l'espace de noms cible est l'adresse IRI d'espace de noms du couple .

8. Conformité

Cette section décrit la conformité de cette spécification à d'autres spécifications. Cela se limite pour l'instant à la spécification de l'ensemble d'information XML (XML Information Set). Consultez la section 1.3 Conformité des documents pour une description des critères auxquels les documents de description de service doivent satisfaire pour être conformes à cette spécification.

8.1 Conformité avec l'ensemble d'information XML

Cette spécification est conforme à l'ensemble d'information XML [XML Information Set]. Les items d'information suivants DOIVENT être présents dans les ensembles d'information en entrée (input Infosets) pour permettre le traitement correct des documents WSDL 2.0 :

  • les items d'information de document avec les propriétés de sous-éléments [children] et d'adresse URI de base [base URI] ;

  • les items d'information d'élément avec les propriétés de nom d'espace de noms [namespace name], de nom local [local name], de sous-éléments [children], d'attributs [attributes], d'adresse URI de base [base URI] et de parent [parent] ;

  • les items d'information d'attribut avec les propriétés de nom d'espace de noms [namespace name], de nom local [local name] et de valeur normalisée [normalized value] ;

  • les items d'information de caractère avec les propriétés de code de caractère [character code], de blanc de contenu d'élément [element content whitespace] et de parent [parent].

9. Récapitulatif de la syntaxe XML (non normatif)

<description targetNamespace="xs:anyURI" >
  <documentation />*

  <import namespace="xs:anyURI" location="xs:anyURI"? >
    <documentation />*
  </import>*

  <include location="xs:anyURI" >
    <documentation />*
  </include>*

  <types>
    <documentation />*
    
      [ <xs:import namespace="xs:anyURI" schemaLocation="xs:anyURI"? /> |
        <xs:schema targetNamespace="xs:anyURI"? /> |
        autres éléments d'extension ]*
  </types>

  <interface name="xs:NCName" extends="liste de xs:QName"? styleDefault="liste de xs:anyURI"? >
    <documentation />*

    <fault name="xs:NCName" element="union de xs:QName, xs:token"? >
      <documentation />*
    </fault>*

    <operation name="xs:NCName" pattern="xs:anyURI"? style="liste de xs:anyURI"? >
      <documentation />*

      <input messageLabel="xs:NCName"? element="union de xs:QName, xs:token"? >
        <documentation />*
      </input>*

      <output messageLabel="xs:NCName"? element="union de xs:QName, xs:token"? >
        <documentation />*

      </output>*

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

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

    </operation>*

  </interface>*

  <binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI" >
    <documentation />*

    <fault ref="xs:QName" >
      <documentation />*
    </fault>*

    <operation ref="xs:QName" >
      <documentation />*

      <input messageLabel="xs:NCName"? >
        <documentation />*
      </input>*

      <output messageLabel="xs:NCName"? >
        <documentation />*
      </output>*

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

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

    </operation>*

  </binding>*

  <service name="xs:NCName" interface="xs:QName" >
    <documentation />*

    <endpoint name="xs:NCName" binding="xs:QName" address="xs:anyURI"? >
      <documentation />*
    </endpoint>+

  </service>*
</description>

10. Références

10.1 Références normatives

[Character Model for the WWW]
Modèle de caractères pour le World Wide Web 1.0 : les fondamentaux, M. Dürst, F. Yergeau, R. Ishida, M. Wolf, T. Texin, rédacteurs. Recommandation du W3C, 15 février 2005. Dernière version disponible à http://www.w3.org/TR/charmod/.
[IETF RFC 2119]
Mots-clés à utiliser dans les RFC pour indiquer les niveaux d'exigence, S. Bradner, auteur. Internet Engineering Task Force, mars 1997. Disponible à http://www.ietf.org/rfc/rfc2119.txt.
[IETF RFC 3023]
Types de médias 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 3986]
Identificateurs de resource uniforme (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.
[XLink 1.0]
Langage de liaison XML (XLink), Steve DeRose, Eve Maler, David Orchard, rédacteurs. World Wide Web Consortium, 27 juin 2001. Cette version de la recommandation XLink est celle à http://www.w3.org/TR/2001/REC-xlink-20010627/. La dernière version de XLink est disponible à http://www.w3.org/TR/xlink/.
[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 de XML 1.0 est disponible à http://www.w3.org/TR/REC-xml.
[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 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 l'ensemble d'information XML est celle à http://www.w3.org/TR/2004/REC-xml-infoset-20040204. La dernière version de l'ensemble d'information XML est disponible à http://www.w3.org/TR/xml-infoset.
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 recommandation 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.
[WSDL 2.0 Adjuncts]
Langage de description de services web (WSDL) version 2.0 tome 2 — Compléments, R. Chinnici, H. Haas, A. Lewis, J-J. Moreau, D. Orchard, S. Weerawarana, rédacteurs. World Wide Web Consortium, 26 juin 2007. Cette version de la recommandation WSDL 2.0 tome 2 est disponible à http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626. La dernière version de WSDL 2.0 tome 2 est disponible à http://www.w3.org/TR/wsdl20-adjuncts.

10.2 Références informatives

[IETF RFC 2045]
Extensions de message Internet polyvalents (MIME) tome 1 — Format des corps de message Internet, N. Freed, N. Borenstein, Authors. Internet Engineering Task Force, novembre 1996. Disponible à http://www.ietf.org/rfc/rfc2045.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.
[WSA 1.0 Core]
Adressage de services web 1.0 : noyau, M. Gudgin, M. Hadley, T. Rogers, rédacteurs. World Wide Web Consortium, 9 mai 2006. Cette version de la recommandation WSA 1.0  Core est celle à http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. La dernière version du document est disponible à http://www.w3.org/TR/ws-addr-core.
[WSDL 1.1]
Langage de description de services web (WSDL) 1.1, E. Christensen, F. Curbera, G. Meredith et S. Weerawarana, auteurs. World Wide Web Consortium, 15 mars 2002. Cette version de la note WSDL 1.1 est celle à http://www.w3.org/TR/2001/NOTE-wsdl-20010315. La dernière version de WSDL 1.1 est disponible à http://www.w3.org/TR/wsdl.
[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 WSDL 2.0 tome 0 est disponible à http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626. La dernière version de WSDL 2.0 tome 0 est disponible à http://www.w3.org/TR/wsdl20-primer.
[WSDL 2.0 Requirements]
Exigences de la description de services web, J. Schlimmer, Editor. World Wide Web Consortium, 28 octobre 2002. Cette version du document d'exigences WSDL est celle à http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028. La dernière version des exigences WSDL est disponible à http://www.w3.org/TR/ws-desc-reqs.
[WSDL 2.0 Alternative Schema Languages Support]
Discussion sur la gestion des autres langages de schéma et systèmes de typage dans WSDL 2.0, A. Lewis, B. Parsia, rédacteurs. World Wide Web Consortium, 17 août 2005. Cette version de la note de groupe de travail « Discussion sur la gestion des autres langages de schéma et systèmes de typage dans WSDL 2.0 » est celle à http://www.w3.org/TR/2005/NOTE-wsdl20-altschemalangs-20050817/. La dernière version de « Discussion sur la gestion des autres langages de schéma et systèmes de typage dans WSDL 2.0 » est disponible à http://www.w3.org/TR/wsdl20-altschemalangs.
[SOAP 1.2 Part 1: Messaging Framework (Second Edition)]
SOAP version 1.2 tome 1 — Structure pour l'échange de messages, M. Gudgin, et al., rédacteurs. World Wide Web Consortium, 24 juin 2003, révisé le 27 avril 2007. Cette version de la recommandation SOAP 1.2 tome 1 est celle à http://www.w3.org/TR/2007/REC-soap12-part1-20070427/. La dernière version de SOAP 1.2 tome 1 est disponible à http://www.w3.org/TR/soap12-part1/.
[XPointer]
Le cadre XPointer, P. Grosso, E. Maler, J. Marsh, N. Walsh, rédacteurs. World Wide Web Consortium, 25 mars 2003. Cette version de la recommandation 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/.
[notation Z Reference Manual]
The notation Z: A Reference Manual, Second Edition, J. M. Spivey, Prentice Hall, 1992.
[Fuzz 2000]
Notes de publication de Fuzz 2000, J. M. Spivey.

A. Le type de média application/wsdl+xml

Cette annexe définit le type de média "application/wsdl+xml" utilisable pour décrire des documents WSDL 2.0 sérialisés en XML.

A.1 Enregistrement

Nom de type de média MIME :

application

Nom de sous-type MIME :

wsdl+xml

Paramètres obligatoires :

aucun

Paramètres optionnels :
charset

Ce paramètre a une sémantique identique à celle du paramètre charset du type de média "application/xml" défini dans [IETF RFC 3023].

Observations sur le codage :

Identiques à celles concernant "application/xml" comme décrit dans [IETF RFC 3023], section 3.2, et appliqué à l'ensemble d'information du document WSDL.

Observations sur la sécurité :

Cf. la section A.3 Observations sur la sécurité.

Observations sur l'interopérabilité :

Aucun problème d'interopérabilité connu.

Spécifications publiées :

Ce document et [WSDL 2.0 Adjuncts].

Applications utilisant ce type de média :

Aucune application connue n'utilise actuellement ce type de média.

Informations supplémentaires :
Extension de fichier :

wsdl

Identificateurs de fragment :

Soit une syntaxe identique à celle de "application/xml" comme décrit dans [IETF RFC 3023], section 5, soit la syntaxe définie à la section A.2 Identificateurs de fragment.

Adresse URI de base :

Comme définie dans [IETF RFC 3023], section 6.

Code de type de fichier Macintosh :

WSDL

Personne à contacter et son adresse électronique pour d'autres renseignements :

World Wide Web Consortium <web-human@w3.org>

Utilisation prévue :

COMMON

Auteur ou contrôleur des changements :

La spécification WSDL 2.0 fixe le produit des travaux du groupe de travail Web Service Description du W3C. Le W3C contrôle les changements concernant ces spécifications.

A.2 Identificateurs de fragment

Cette section définit une syntaxe d'identificateur de fragment pour identifier les composants d'un document WSDL 2.0. Cette syntaxe d'identificateur de fragment est compatible avec la spécification [XPointer].

Un identificateur de fragment WSDL 2.0 est un pointeur XPointer, augmenté des parties pointeur WSDL 2.0 définies ci-dessous. Notez que beaucoup de ces parties nécessitent l'apparition préalable d'une ou plusieurs parties pointeur xmlns (cf. [XPointer], section 3.4 Contexte de liaison d'espace de noms). Les parties pointeur ont un nom de schéma qui correspond à l'un des types de composant WSDL 2.0 normalisés, et des données de schéma qui sont un chemin (path) composé des noms identifiant les composants. Les noms de schéma commencent tous par le préfixe "wsdl." afin d'éviter les conflits de noms avec d'autres schémas. Les noms dans le chemin sont de types QName, NCName, IRI, URI ou partie pointeur, selon le contexte. Les données de schéma des composants d'extension WSDL 2.0 sont définies par la spécification d'extension correspondante.

Pour les noms qualifiés QName, tout préfixe DOIT être défini par une partie pointeur xmlns précédente . Si un nom qualifié QName n'a pas de préfixe, alors son nom d'espace de noms est l'espace de noms cible du document WSDL 2.0.

L'identificateur de fragment est typiquement construit à partir de la propriété {name} du composant et des propriétés {name} de ses ancêtres comme un chemin, conformément au tableau A-1. La première colonne du tableau donne le nom du composant WSDL 2.0. Les colonnes numérotées 1 à 4 indiquent les identificateurs identifiant de manière unique le composant dans son contexte. Les identificateurs sont typiquement formés à partir de la propriété {name}, même si des références à d'autres composants sont utilisées dans plusieurs cas. Ces identificateurs servent ensuite à construire la partie pointeur dans la dernière colonne. L'identificateur de fragment dans une référence IRI de composant WSDL 2.0 DOIT se résoudre en un composant comme défini par les règles de construction du tableau A-1 .

Tableau A-1. Règles pour déterminer les parties pointeur des composants WSDL 2.0
Composant 1 2 3 4 Partie pointer
Description néant néant néant néant wsdl.description()
Element Declaration element QName néant néant néant wsdl.elementDeclaration(element)
Element Declaration element QName system IRI néant néant wsdl.elementDeclaration(element,system)
Type Definition type QName néant néant néant wsdl.typeDefinition(type)
Type Definition type QName system IRI néant néant wsdl.typeDefinition(type,system)
Interface interface NCName néant néant néant wsdl.interface(interface)
Interface Fault interface NCName fault NCName néant néant wsdl.interfaceFault(interface/fault)
Interface Operation interface NCName operation NCName néant néant wsdl.interfaceOperation(interface/operation)
Interface Message Reference interface NCName operation NCName message NCName néant wsdl.interfaceMessageReference(interface/operation/message)
Interface Fault Reference interface NCName operation NCName message NCName fault QName wsdl.interfaceFaultReference(interface/operation/message/fault)
Binding binding NCName néant néant néant wsdl.binding(binding)
Binding Fault binding NCName fault QName néant néant wsdl.bindingFault(binding/fault)
Binding Operation binding NCName operation QName néant néant wsdl.bindingOperation(binding/operation)
Binding Message Reference binding NCName operation QName message NCName néant wsdl.bindingMessageReference(binding/operation/message)
Binding Fault Reference binding NCName operation QName message NCName fault QName wsdl.bindingFaultReference(binding/operation/message/fault)
Service service NCName néant néant néant wsdl.service(service)
Endpoint service NCName endpoint NCName néant néant wsdl.endpoint(service/endpoint)
Extensions namespace URI identifier syntaxe-spécifique-de-l'extension néant néant wsdl.extension(namespace,identifier)

Notez que les règles précédentes sont définies d'après les propriétés de composant et non d'après la représentation dans l'ensemble d'information XML du modèle de composants. Les sections suivantes définissent en détails la construction des parties pointeur à partir du modèle de composants.

A.2.1 Le composant Description

wsdl.description()

A.2.2 Le composant Element Declaration

wsdl.elementDeclaration(element)

wsdl.elementDeclaration(element,system)

  1. element est la propriété {name} du composant Element Declaration ;

  2. system et l'adresse IRI absolue de l'espace de noms du système de typage d'extension utilisé pour le composant Element Declaration (cf la section 3.2 Utilisation d'autres langages de schéma). Ce paramètre est absent si le système de typage est XML Schema.

A.2.3 Le composant Type Definition

wsdl.typeDefinition(type)

wsdl.typeDefinition(type,system)

  1. type est la propriété {name} du composant Type Definition ;

  2. system est l'adresse IRI absolue de l'espace de noms du système de typage d'extension utilisé pour le composant Type Definition (cf. la section 3.2 Utilisation d'autres langages de schéma). Ce paramètre est absent si ce système de typage est XML Schema.

A.2.4 Le composant Interface

wsdl.interface(interface)

  1. interface est le nom local de la propriété {name} du composant Interface.

A.2.5 Le composant Interface Fault

wsdl.interfaceFault(interface/fault)

  1. interface est le nom local de la propriété {name} du composant Interface parent ;

  2. fault est le nom local de la propriété {name} du composant Interface Fault parent.

A.2.6 Le composant Interface Operation

wsdl.interfaceOperation(interface/operation)

  1. interface est le nom local de la propriété {name} du composant Interface parent ;

  2. operation est le nom local de la propriété {name} du composant Interface Operation.

A.2.7 Le composant Interface Message Reference

wsdl.interfaceMessageReference(interface/operation/message)

  1. interface est le nom local de la propriété {name} du composant Interface grand-parent ;

  2. operation est le nom local de la propriété {name} du composant Interface Operation parent ;

  3. message est la propriété {message label} du composant Interface Message Reference.

A.2.8 Le composant Interface Fault Reference

wsdl.interfaceFaultReference(interface/operation/message/fault)

  1. interface est le nom local de la propriété {name} du composant Interface grand-parent ;

  2. operation est le nom local de la propriété {name} du comosant Interface Operation parent ;

  3. message est la propriété {message label} du composant Interface Fault Reference ;

  4. fault est la propriété {name} du composant Interface Fault désigné par la propriété {interface fault} du composant Interface Fault Reference.

A.2.9 Le composant Binding

wsdl.binding(binding)

  1. binding est le nom local de la propriété {name} du composant Binding.

A.2.10 Le composant Binding Fault

wsdl.bindingFault(binding/fault)

  1. binding est le nom local de la propriété {name} du composant Binding parent ;

  2. fault est la propriété {name} du composant Interface Fault désigné par la propriété {interface fault} du composant Binding Fault.

A.2.11 Le composant Binding Operation

wsdl.bindingOperation(binding/operation)

  1. binding est le nom local de la propriété {name} du composant Binding parent ;

  2. operation est la propriété {name} du composant Interface Operation désigné par la propriété {interface operation} du composant Binding Operation.

A.2.12 Le composant Binding Message Reference

wsdl.bindingMessageReference(binding/operation/message)

  1. binding est le nom local de la propriété {name} du composant Binding grand-parent ;

  2. operation est le nom local de la propriété {name} du composant Interface Operation désigné par la propriété {interface operation} du composant Binding Operation parent ;

  3. message est la propriété {message label} du composant Interface Message Reference désigné par la propriété {interface message reference} du composant Binding Message Reference.

A.2.13 Le composant Binding Fault Reference

wsdl.bindingFaultReference(binding/operation/message/fault)

  1. binding est le nom local de la propriété {name} du composant Binding grand-parent ;

  2. operation est la propriété {name} du composant Interface Operation désigné par la propriété {interface operation} du composant Binding Operation parent ;

  3. message est la propriété {message label} du composant Interface Fault Reference désigné par la propriété {interface fault reference} du composant Binding Fault Reference ;

  4. fault est la propriété {name} du composant Interface Fault désigné par la propriété {interface fault} du composant Interface Fault Reference désigné par la propriété {interface fault reference} du composant Binding Fault Reference.

A.2.14 Le composant Service

wsdl.service(service)

  1. service est le nom local de la propriété {name} du composant Service.

A.2.15 Le composant Endpoint

wsdl.endpoint(service/endpoint)

  1. service est le nom local de la propriété {name} du composant Service parent ;

  2. endpoint est la propriété {name} du composant Endpoint.

A.2.16 Composants d'extension

WSDL 2.0 est extensible et une extension peut définir des types de composants nouveaux. Le schéma de cadre XPointer pour les composants d'extension est le suivant :

wsdl.extension(namespace, identifier)

  1. namespace est l'adresse URI de l'espace de noms identifiant l'extension ; par exemple, pour la liaison SOAP 1.2 WSDL 2.0, l'espace de noms est "http://www.w3.org/ns/wsdl/soap" ;

  2. identifier est défini par l'extension au moyen d'une syntaxe spécifique. Le propriétaire de l'extension doit définir tous les composants apportés par l'extension et une syntaxe pour les identifier.

A.3 Observations sur la sécurité

Ce type de média utilise la convention "+xml" ; il s'y applique les mêmes observations sur la sécurité que celles décrites dans [IETF RFC 3023], section 10.

B. Remerciements (non normatif)

Ce document est le résultat des travaux 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 en 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 étaients : 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).

Les personnes ayant contribué aux discussions sur www-ws-desc@w3.org sont également vivement remerciée.

C. Références IRI des composants WSDL 2.0 (non normatif)

Cette annexe fournit une syntaxe pour les références IRI de tous les composants trouvés dans un document WSDL 2.0. Les références IRI sont faciles à comprendre et comparer, tout en n'imposant aucune charge au créateur WSDL 2.0.

C.1 Adresses IRI de WSDL 2.0

Il y a deux cas principaux d'adresses IRI pour WSDL 2.0 :

  • l'adresse IRI d'un document WSDL 2.0 ;

  • l'adresse IRI d'un espace de noms WSDL 2.0.

L'adresse IRI d'un document WSDL 2.0 peut être résolue pour donner une représentation de ressource apportant des définitions de composant à un seul espace de noms WSDL 2.0. Si le type de média est celui de WSDL 2.0, on peut utiliser les identificateurs de fragment pour identifier les composants principaux définis dans le document.

Toutefois, en suivant la recommandation de la section 2.1.1 Le composant Description selon laquelle l'adresse URI de l'espace de noms se résoud en un document WSDL 2.0, cette annexe définit l'utilisation de l'adresse IRI de l'espace de noms avec les identificateurs de fragment WSDL 2.0 afin de former une référence IRI.

L'adresse IRI dans la référence IRI d'un composant WSDL 2.0 est le nom d'espace de noms soit de la propriété {name} du composant lui-même, dans le cas des composants Interface , Binding et Service, soit de la propriété {name} du composant de niveau supérieur ancêtre. L'adresse IRI fournie par le nom d'espace de noms de la propriété {name} est combinée à zéro ou plus parties pointeur xmlns (cf. [XPointer], section  3.4 Contexte de liaison d'espace de noms) suivies d'une seule partie pointeur WSDL 2.0 comme défini dans la section A.2 Identificateurs de fragment.

C.2 Forme canonique des indicateurs de composant WSDL 2.0

Les références IRI décrites ci-dessus PEUVENT être utilisées comme indicateurs de composant WSDL 2.0. Pour faciliter la comparaison, l'identificateur de fragment des indicateurs de composant WSDL 2.0 DEVRAIT se conformer aux règles de canonisation suivantes :

  • L'identificateur de fragment consiste en une séquence de zéro ou plus parties pointeur xmlns() suivies exactement d'une seule partie pointeur wsdl.*()  ;

  • Chaque partie pointeur xmlns() apparaissant dans l'identificateur de fragement définit un espace de noms référencé par la partie pointeur wsdl.*()  ;

  • Chaque partie pointeur xmlns() définit un espace de noms unique  ;

  • La partie pointeur xmlns() définit les espaces de noms dans le même ordre d'appel que dans la partie pointeur wsdl.*()  ;

  • Les préfixes d'espace de noms définis par les parties pointeur xmlns() sont nommées ns1, ns2, etc., dans l'ordre de leur apparition  ;

  • L'identificateur de fragment ne contient aucun blanc (whitespace)  ;

  • Aucune partie pointeur xmlns() ne définit d'espace de noms pour l'attribut targetNamespace du document WSDL 2.0 .

C.3 Exemple

Étudions le document WSDL 2.0 suivant trouvé à http://example.org/TicketAgent.wsdl :

Exemple C-1. Références IRI — Exemple de document WSDL 2.0


<?xml version="1.0" encoding="UTF-8"?>
<wsdl:description 
    targetNamespace="http://example.org/TicketAgent.wsdl20" 
    xmlns:xsTicketAgent="http://example.org/TicketAgent.xsd" 
    xmlns:wsdl="http://www.w3.org/ns/wsdl" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://www.w3.org/ns/wsdl http://www.w3.org/2007/06/wsdl/wsdl20.xsd">
        
    <wsdl:types>
        <xs:import schemaLocation="TicketAgent.xsd" 
                   namespace="http://example.org/TicketAgent.xsd" />
    </wsdl:types>
        
    <wsdl:interface name="TicketAgent">
        <wsdl:operation name="listFlights"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
            <wsdl:input element="xsTicketAgent:listFlightsRequest"/>
            <wsdl:output element="xsTicketAgent:listFlightsResponse"/>
        </wsdl:operation>
                
        <wsdl:operation name="reserveFlight"
                        pattern="http://www.w3.org/ns/wsdl/in-out">
            <wsdl:input element="xsTicketAgent:reserveFlightRequest"/>
            <wsdl:output element="xsTicketAgent:reserveFlightResponse"/>
        </wsdl:operation>
    </wsdl:interface>
</wsdl:description>

Ses composants ont les références IRI suivantes, qui obéissent aux règles de canonisation précédentes sauf en ce qui concerne la présence de blancs optionnels, ajoutés pour des raisons de formatage :

Example C-2. Références IRI — exemple d'adresses IRI

http://example.org/TicketAgent.wsdl20#
  wsdl.description() 

http://example.org/TicketAgent.wsdl20#
  xmlns(ns1=http://example.org/TicketAgent.xsd)
  wsdl.elementDeclaration(ns1:listFlightsRequest) 

http://example.org/TicketAgent.wsdl20#
  xmlns(ns1=http://example.org/TicketAgent.xsd)
  wsdl.elementDeclaration(ns1:listFlightsResponse) 

http://example.org/TicketAgent.wsdl20#
  xmlns(ns1=http://example.org/TicketAgent.xsd)
  wsdl.elementDeclaration(ns1:reserveFlightRequest) 

http://example.org/TicketAgent.wsdl20#
  xmlns(ns1=http://example.org/TicketAgent.xsd)
  wsdl.elementDeclaration(ns1:reserveFlightResponse) 

http://example.org/TicketAgent.wsdl20#
  wsdl.interface(TicketAgent) 

http://example.org/TicketAgent.wsdl20#
  wsdl.interfaceOperation(TicketAgent/listFlights) 

http://example.org/TicketAgent.wsdl20#
  wsdl.interfaceMessageReference(TicketAgent/listFlights/In) 

http://example.org/TicketAgent.wsdl20#
  wsdl.interfaceMessageReference(TicketAgent/listFlights/Out) 

http://example.org/TicketAgent.wsdl20#
  wsdl.interfaceOperation(TicketAgent/reserveFlight)

http://example.org/TicketAgent.wsdl20#
  wsdl.interfaceMessageReference(TicketAgent/reserveFlight/In) 

http://example.org/TicketAgent.wsdl20#
  wsdl.interfaceMessageReference(TicketAgent/reserveFlight/Out) 

D. Récapitulatif des composants (non normatif)

Le tableau D-1 liste tous les composants dans le modèle de composants abstrait WSDL 2.0 et toutes leurs propriétés. Notez que certaines propriétés ont une définition générique utilisée dans plusieurs composants. Auquel cas, la colonne « Composant » contient un caractère « - » afin de signaler cette définition générique de la propriété.

Tableau D-1. Récapitulatif des composants WSDL 2.0 et leurs propriétés
Composant Propriétés définies
- {name}, {parent}
Binding {binding faults}, {binding operations}, {interface}, {name}, {type}
Binding Fault {interface fault}, {parent}
Binding Fault Reference {interface fault reference}, {parent}
Binding Message Reference {interface message reference}, {parent}
Binding Operation {binding fault references}, {binding message references}, {interface operation}, {parent}
Description {bindings}, {element declarations}, {interfaces}, {services}, {type definitions}
Element Declaration {name}, {system}
Endpoint {address}, {binding}, {name}, {parent}
Interface {extended interfaces}, {interface faults}, {interface operations}, {name}
Interface Fault {element declaration}, {message content model}, {name}, {parent}
Interface Fault Reference {direction}, {interface fault}, {message label}, {parent}
Interface Message Reference {direction}, {element declaration}, {message content model}, {message label}, {parent}
Interface Operation {interface fault references}, {interface message references}, {message exchange pattern}, {name}, {parent}, {style}
Service {endpoints}, {interface}, {name}
Type Definition {name}, {system}
Propriété Là où définie
address Endpoint.{address}
binding Endpoint.{binding}
binding fault references Binding Operation.{binding fault references}
binding faults Binding.{binding faults}
binding message references Binding Operation.{binding message references}
binding operations Binding.{binding operations}
bindings Description.{bindings}
direction Interface Fault Reference.{direction}, Interface Message Reference.{direction}
element declaration Interface Fault.{element declaration}, Interface Message Reference.{element declaration}
element declarations Description.{element declarations}
endpoints Service.{endpoints}
extended interfaces Interface.{extended interfaces}
interface Binding.{interface}, Service.{interface}
interface fault Binding Fault.{interface fault}, Interface Fault Reference.{interface fault}
interface fault reference Binding Fault Reference.{interface fault reference}
interface fault references Interface Operation.{interface fault references}
interface faults Interface.{interface faults}
interface message reference Binding Message Reference.{interface message reference}
interface message references Interface Operation.{interface message references}
interface operation Binding Operation.{interface operation}
interface operations Interface.{interface operations}
interfaces Description.{interfaces}
message content model Interface Fault.{message content model}, Interface Message Reference.{message content model}
message exchange pattern Interface Operation.{message exchange pattern}
message label Interface Fault Reference.{message label}, Interface Message Reference.{message label}
name .{name}, Binding.{name}, Element Declaration.{name}, Endpoint.{name}, Interface.{name}, Interface Fault.{name}, Interface Operation.{name}, Service.{name}, Type Definition.{name}
parent .{parent}, Binding Fault.{parent}, Binding Fault Reference.{parent}, Binding Message Reference.{parent}, Binding Operation.{parent}, Endpoint.{parent}, Interface Fault.{parent}, Interface Fault Reference.{parent}, Interface Message Reference.{parent}, Interface Operation.{parent}
services Description.{services}
style Interface Operation.{style}
system Element Declaration.{system}, Type Definition.{system}
type Binding.{type}
type definitions Description.{type definitions}

E. Récapitulatif des assertions (non normatif)

Cette annexe récapitule les assertions concernant les documents et composants WSDL 2.0 que le schéma WSDL 2.0 ne fait pas valoir. Chaque assertion est affectée d'un identificateur unique que les processeurs WSDL 2.0 peuvent utiliser pour signaler des erreurs.

Tableau E-1. Récapitulatif des assertions concernant les documents WSDL 2.0
Id Assertion
Description-1004 Si un document WSDL 2.0 est scindé en plusieurs documents WSDL 2.0 (lesquels peuvent être combinés au besoin selon les indications de la section 4.1 Inclusion des descriptions), alors l'item d'information d'élément targetNamespace DEVRAIT se résoudre en un document WSDL 2.0 maître comprenant tous les documents WSDL 2.0 nécessaires pour cette description de service.
Description-1005 zéro ou plus items d'information d'élément parmi ses sous-éléments [children], en ordre, comme suit
Description-1006 Sa valeur DOIT être une adresse IRI absolue (cf. [IETF RFC 3987]) et devrait être résolvable.
Import-1082 Comme pour un schéma XML, tout document WSDL 2.0 qui référence un composant extérieur DOIT avoir un item d'information d'élément wsdl:import pour l'espace de noms extérieur associé (mais qui ne contient pas forcément un item d'information d'attribut location identifiant le document WSDL 2.0 dans lequel le composant référencé est défini).
Import-1083 Si un document WSDL 2.0 contient plusieurs items d'information d'élément wsdl:import pour une valeur donnée de l'item d'information d'attribut namespace, alors ceux-ci DOIVENT fournir des valeurs différentes pour l'item d'information d'attribut location.
Import-1084 Cette valeur NE DOIT PAS correspondre à la valeur réelle de l'item d'information d'attribut targetNamespace dans le document WSDL 2.0 englobant.
Import-1085 Si l'attribut location dans l'item d'information d'élément import est résolvable, alors il DOIT référencer un document WSDL 2.0.
Import-1086 Si l'item d'information d'attribut location de l'item d'information d'élément import est résolvable, alors la valeur réelle de l'item d'information d'attribut namespace DOIT être identique à la valeur réelle de l'item d'information d'attribut targetNamespace du document WSDL 2.0 référencé (cf. la section 7. Localisation des documents WSDL 2.0).
Include-1080 L'adresse IRI indiquée par location DOIT se résoudre en un document WSDL 2.0.
Include-1081 La valeur réelle de l'item d'information d'attribut targetNamespace du document WSDL 2.0 inclus DOIT correspondre à la valeur réelle de l'item d'information d'attribut targetNamespace de l'item d'information d'élément description parent [parent] de l'item d'information d'élément include.
Interface-1012 Si présent, sa valeur DOIT contenir des adresses IRI absolues (cf. [IETF RFC 3987]).
InterfaceFault-1017 Si l'item d'information d'attribut element a une valeur, alors elle DOIT se résoudre dans le composant Element Declaration de la propriété {element declarations} du composant Description.
InterfaceFaultReference-1040 L'item d'information d'attribut messageLabel DOIT être présent dans la représentation XML d'un composant Interface Fault Reference, avec une propriété {direction} donnée, si la propriété {message exchange pattern} du composant Interface Operation parent [parent] a plus d'un incident avec cette direction.
InterfaceMessageReference-1036 Si l'item d'information d'attribut element a une valeur, alors elle DOIT se résoudre en un composant Element Declaration de la propriété {element declarations} du composant Description.
Location-1092 Il NE DOIT PAS apparaître sur un élément wsdl:description ou l'un de ses sous-éléments ou descendants.
Location-1094 Pour chaque couple d'adresses IRI, si l'adresse IRI de localisation de couple est résolvable, alors elle DOIT référencer un document WSDL 2.0 (ou WSDL 1.1) dont l'espace de noms cible est l'adresse IRI d'espace de noms du couple.
MessageLabel-1030 Si l'item d'information d'attribut messageLabel d'un item d'information d'élément d'une référence de message d'interface est présent, alors sa valeur réelle DOIT correspondre à la propriété {message label} d'un message fictif dont la propriété {direction} est égale à la direction du message.
MessageLabel-1031 Si l'item d'information d'attribut messageLabel d'un item d'information d'élément d'une référence de message d'interface est absent, alors il DOIT y avoir un message fictif unique dont la propriété {direction} est égale à la direction du message.
MessageLabel-1032 Si le nom local est input, alors le modèle d'échange de messages DOIT avoir au moins un message fictif avec une direction de "In".
MessageLabel-1033 Si le nom local est output, alors le modèle d'échange de messages DOIT avoir au moins un message fictif avec une direction de "Out".
MessageLabel-1034 Si le nom local est infault, alors le modèle d'échange de messages DOIT comporter au moins un incident dans la direction "In".
MessageLabel-1035 Si le nom local est outfault, alors le modèle d'échange de messages DOIT comporter au moins un incident dans la direction "Out".
MessageLabel-1041 L'item d'information d'attribut messageLabel d'un item d'information d'élément de référence d'incident d'interface DOIT être présent si le modèle d'échange de messages a plus d'un message fictif dont la propriété {direction} est égale à la direction du message.
MessageLabel-1042 Si l'item d'information d'attribut messageLabel d'un item d'information d'élément de référence d'incident d'interface est présent, alors sa valeur réelle DOIT correspondre à la propriété {message label} d'un message fictif dont la propriété {direction} est égale à la direction du message.
MessageLabel-1043 Si l'item d'information d'attribut messageLabel d'un item d'information d'élément de référence d'incident d'interface est absent, alors il DOIT y avoir un seul message fictif dont la propriété {direction} est égale à la direction du message.
MessageLabel-1053 Si l'item d'information d'attribut messageLabel de l'item d'information d'élément d'une référence de message de liaison est présent, alors sa valeur réelle DOIT correspondre à la propriété {message label} d'un message fictif dont la propriété {direction} est égale à la direction de message.
MessageLabel-1054 Si l'item d'information d'attribut messageLabel de l'item d'information d'élément d'une référence de message de liaison est absent, alors il DOIT y avoir un message fictif unique dont la propriété {direction} est égale à la direction de message.
MessageLabel-1056 L'item d'information d'attribut messageLabel DOIT être présent si le modèle d'échange de messages a plus d'un message fictif dont la propriété {direction} est égale à la direction de message.
MessageLabel-1057 Si l'item d'information d'attribut messageLabel d'un item d'information d'élément de référence d'incident de liaison est présent, alors sa valeur réelle DOIT correspondre à la propriété {message label} d'un message fictif dont la propriété {direction} est égale à la direction de message.
MessageLabel-1058 Si l'item d'information d'attribut messageLabel d'un item d'information d'élément de référence d'incident de liaison est absent, alors il DOIT y avoir un message fictif unique dont la propriété {direction} est égale à la direction de message.
QName-resolution-1064 Un composant Description NE DOIT PAS avoir de telles références cassées.
Schema-1066 Un document WSDL 2.0 NE DOIT PAS référencer des composants XML Schema dans un espace de noms donné sauf si un item d'information d'élément xs:import ou xs:schema pour cet espace de noms est présent ou l'espace de noms est celui de XML Schema (http://www.w3.org/2001/XMLSchema) qui contient des types intégrés comme défini dans la spécification XML Schema tome 2 — Types de données (deuxième édition) [XML Schema: Datatypes].
Schema-1069 Le schéma référencé DOIT contenir un item d'information d'attribut targetNamespace sur son item d'information d'élément xs:schema.
Schema-1070 La valeur de l'item d'information d'attribut targetNamespace de l'item d'information d'élément xs:schema d'un schéma importé DOIT être égale à celle de l'item d'information d'attribut namespace de l'item d'information d'élément import dans le document WSDL 2.0 appelant.
Schema-1073 Un document WSDL 2.0 NE DOIT PAS définir le même élément ou type dans plusieurs schémas incorporés.
Schema-1075 Une définition de syntaxe d'extension d'un autre langage de schéma DOIT utiliser un espace de noms différent de celui de XML Schema.
Schema-1076 L'espace de noms utilisé pour un autre langage de schéma DOIT être une adresse IRI absolue.
Schema-1079 Si wsdlx:interface et wsdlx:binding sont utilisés ensemble, alors ils DOIVENT satisfaire aux mêmes règles de cohérence qui s'appliquent à la propriété {interface} d'un composant Service et à la propriété {binding} d'un composant Endpoint niché, c'est-à-dire que la liaison se réfère soit à l'interface du service, soit ne se réfère à aucune interfaceSi wsdlx:interface et wsdlx:binding sont utilisés ensemble, alors ils DOIVENT satisfaire aux mêmes règles de cohérence qui s'appliquent à la propriété {interface} d'un composant Service et à la propriété {binding} d'un composant Endpoint niché, c'est-à-dire que la liaison se réfère soit à l'interface du service, soit ne se réfère à aucune interface.
Types-1074 Une définition de syntaxe d'extension pour un autre langage de schéma DOIT inclure la déclaration d'un item d'information d'élément, destiné à apparaître comme sous-élément de l'item d'information d'élément wsdl:types, lequel référence, nomme et localise l'instance de schéma (un item d'information d'élément import).
Types-1077 Le type de l'item d'information d'attribut wsdlx:interface est un nom qualifié xs:QName qui définit la propriété {name} d'un composant Interface.
Types-1078 Le type de l'item d'information d'attribut wsdlx:binding est un nom qualifié xs:QName qui définit la propriété {name} d'un composant Binding.
Tableau E-2. Récapitulatif des assertions concernant les composants WSDL 2.0
Id Assertion
Binding-1044 Si un composant Binding définit des détails de liaison spécifiques d'une opération (par des composants Binding Operation) ou des détails d'incident de liaison (par des composants Binding Fault), alors il DOIT définir l'interface à laquelle il s'applique, pour indiquer de quelle interface les opérations proviennent.
Binding-1045 Un composant Binding qui définit les liaisons d'un composant Interface DOIT définir les liaisons de toutes les opérations de ce composant Interface.
Binding-1046 De la même façon, à chaque fois qu'un composant Binding réutilisable (c'est-à-dire l'un n'indiquant pas de composant Interface) est appliqué à un composant Interface spécifique dans le contexte d'un composant Endpoint (cf. la section 2.13.1 Le composant Endpoint), le composant Binding DOIT définir les liaisons de chaque composant Interface Operation et Interface Fault du composant Interface, via une combinaison de propriétés définies sur le composant Binding même et les règles de liaison par défaut spécifiques de son type de liaison.
Binding-1047 Un composant Binding qui définit les liaisons d'un composant Interface DOIT définir les liaisons de tous les incidents de ce composant Interface référencés par les opérations dans ce composant Interface.
Binding-1048 Cette adresse xs:anyURI DOIT être une adresse IRI absolue telle que définie par [IETF RFC 3987].
Binding-1049 Pour chaque composant Binding dans la propriété {bindings} d'un composant Description, la propriété {name} DOIT être unique.
BindingFault-1050 Pour chaque composant Binding Fault dans la propriété {binding faults} d'un composant Binding, la propriété {interface fault} DOIT être unique.
BindingFaultReference-1055 Pour chaque composant Binding Fault Reference dans la propriété {binding fault references} d'un composant Binding Operation, la propriété {interface fault reference} DOIT être unique.
BindingFaultReference-1059 Il DOIT y avoir un composant Interface Fault Reference dans la propriété {interface fault references} du composant Interface Operation lié dont la propriété {message label} est égale au libellé de message effectif et la propriété {interface fault} est égale à un composant Interface Fault avec une propriété {name} égale à l'item d'information d'attribut ref.
BindingMessageReference-1052 Pour chaque composant Binding Message Reference dans la propriété {binding message references} d'un composant Binding Operation, la propriété {interface message reference} DOIT être unique.
BindingOperation-1051 Pour chaque composant Binding Operation dans la propriété {binding operations} d'un composant Binding, la propriété {interface operation} DOIT être unique.
CanonFragId-1097 L'identificateur de fragment consiste en une séquence de zéro ou plus parties pointeur xmlns() suivies d'exactement une seule partie pointeur wsdl.*().
CanonFragId-1098 Chaque partie pointeur xmlns() apparaissant dans l'identificateur de fragement définit un espace de noms référencé par la partie pointeur wsdl.*().
CanonFragId-1099 Chaque partie pointeur xmlns() définit un espace de noms unique.
CanonFragId-1100 La partie pointeur xmlns() définit les espaces de noms dans le même ordre d'appel que dans la partie pointeur wsdl.*().
CanonFragId-1101 Les préfixes d'espace de noms définis par les parties pointeur xmlns() sont nommées ns1, ns2, etc., dans l'ordre de leur apparition.
CanonFragId-1102 L'identificateur de fragment ne contient aucun blanc (whitespace).
CanonFragId-1103 Aucune partie pointeur xmlns() ne définit d'espace de noms pour l'attribut targetNamespace du document WSDL 2.0.
Compare-URI-IRI-1065 Lorsqu'on compare de telles adresses URI et IRI absolues pour déterminer une équivalence (cf. la section 2.15 Équivalence de composants), on DOIT les comparer caractère par caractère comme indiqué dans [IETF RFC 3987].
Description-1001 La valeur de l'item d'information d'attribut targetNamespace DEVRAIT être résolvable.
Description-1002 Elle DEVRAIT se résoudre en un document exploitable par un humain ou une machine définissant directement ou indirectement la sémantique attendue de ces composants.
Description-1003 Elle PEUT se résoudre en un document WSDL 2.0 fournissant une information de description de service pour cet espace de noms.
Description-1067 Pour chaque composant dans l'espace de noms importé, un composant correspondant Element Declaration, ou Type Definition, DOIT apparaître respectivement dans la propriété {element declarations}, ou {type definitions}, du composant Description correspondant au document WSDL qui importe le schéma, ou qui importe directement ou indirectement un document WSDL important le schéma.
Description-1068 Les composants de schéma qui ne sont pas dans un espace de noms importé NE DOIVENT PAS apparaître dans les propriétés {element declarations} ou {type definitions}.
Description-1071 Pour chaque composant défini et déclaré dans le document de schéma incorporé ou inclus par xs:include, un composant Element Declaration, ou Type Definition, DOIT apparaître respectivement dans la propriété {element declarations}, ou {type definitions}, du composant Description correspondant au document WSDL qui contient le schéma, ou qui importe directement ou indirectement un document WSDL qui contient le schéma.
Description-1072 Les composants de schéma non définis ou déclarés dans le document de schéma incorporé, ou inclus par xs:include, NE DOIVENT PAS apparaître dans les propriétés {element declarations} ou {type definitions}.
Endpoint-1061 Ce type xs:anyURI DOIT être une adresse IRI absolue comme défini par [IETF RFC 3987].
Endpoint-1062 Pour chaque composant Endpoint dans la propriété {endpoints} d'un composant Service, la propriété {binding} DOIT soit être un composant Binding avec une propriété {interface} non définie, soit un composant Binding avec une propriété {interface} égale à la propriété {interface} du composant Service.
Equivalence-1063 Les propriétés d'extension qui ne sont pas des valeurs de chaîne, des ensembles de chaînes ou des références DOIVENT décrire les règles d'équivalence de leurs valeurs.
Extensibility-1089 Une extension non marquée comme obligatoire NE DOIT PAS invalider la signification d'une partie quelconque d'un document WSDL 2.0.
Extensibility-1090 Si un document WSDL 2.0 déclare une extension comme étant optionnelle (c'est-à-dire non obligatoire), alors le service web NE DOIT PAS supposer que le client gère cette extension, sauf si le service web sait (par un autre moyen) que le client a en fait choisi d'engager et de gérer cette extension.
Extensibility-1091 Le service web DOIT donc gérer chaque extension déclarée comme étant optionnelle dans le document WSDL 2.0, en plus de gérer chaque extension déclarée comme étant obligatoire.
Extension-1088 La signification d'une extension DEVRAIT être définie (directement ou indirectement) dans un document disponible à l'adresse IRI de son espace de noms.
FragId-1095 Pour les noms qualifiés QName, tout préfixe DOIT être défini par une partie pointeur xmlns précédente.
FragId-1096 L'identificateur de fragment dans une référence IRI de composant WSDL 2.0 DOIT se résoudre en un composant comme défini par les règles de construction du tableau A-1.
ImportInclude-1087 La sémantique d'une extension NE DOIT PAS dépendre de la façon dont les composants sont amenés dans une instance de modèle de composants via <import> ou <include>.
Interface-1009 Afin d'éviter les définitions circulaires, une interface NE DOIT PAS apparaître dans l'ensemble d'interfaces qu'elle étend, que ce soit directement ou indirectement.
Interface-1010 Pour chaque composant Interface dans la propriété {interfaces} d'un composant Description, la propriété {name} DOIT être unique.
Interface-1011 La liste des noms qualifiés xs:QName dans un item d'information d'attribut extends NE DOIT PAS contenir de doubles.
InterfaceFault-1013 Un type xs:token ayant l'une des valeurs suivantes : #any, #none, #other ou #element.
InterfaceFault-1014 Lorsque la propriété {message content model} a la valeur #any ou #none, la propriété {element declaration} DOIT être vide.
InterfaceFault-1015 Au cas où deux (ou plus) composants Interface Fault ont des propriétés {name} de même valeur, à cause d'une interface étendant une ou plusieurs autres interfaces, alors les modèles de composant de ces composants Interface Fault DOIVENT être équivalents (cf. la section 2.15 Équivalence des composants).
InterfaceFault-1016 Pour la raison précédente, une bonne pratique DEVRAIT être de s'assurer, le cas échéant, que le nom local de la propriété {name} des composants Interface Fault au sein d'un espace de noms soit unique, rendant ainsi possible une telle dérivation sans erreur accidentelle.
InterfaceFaultReference-1037 La valeur de cette propriété DOIT correspondre au nom d'un message fictif défini par le modèle d'échange de messages.
InterfaceFaultReference-1038 La direction DOIT être cohérente avec celle impliquée par le règlement de propagation d'incident utilisé dans le modèle d'échange de messages de l'opération.
InterfaceFaultReference-1039 Pour chaque composant Interface Fault Reference dans la propriété {interface fault references} d'un composant Interface Operation, la combinaison de ses propriétés {interface fault} et {message label} DOIT être unique.
InterfaceMessageReference-1025 Un type xs:token ayant la valeur in ou out, indiquant respectivement si le message arrive au service ou en vient.
InterfaceMessageReference-1026 La direction DOIT être la même que celle du message identifié par la propriété {message label} dans la propriété {message exchange pattern} du composant Interface Operation contenant le message.
InterfaceMessageReference-1027 Un type xs:token avec l'une des valeurs suivantes : #any, #none, #other ou #element.
InterfaceMessageReference-1028 Lorsque la propriété {message content model} a la valeur #any ou #none, la propriété {element declaration} DOIT être vide.
InterfaceMessageReference-1029 Pour chaque composant Interface Message Reference dans la propriété {interface message references} d'un composant Interface Operation, sa propriété {message label} DOIT être unique.
InterfaceOperation-1018 Cette adresse xs:anyURI DOIT être une adresse IRI absolue (cf. [IETF RFC 3987]).
InterfaceOperation-1019 Ces adresses xs:anyURI DOIVENT être des adresses IRI absolues (cf. [IETF RFC 3986]).
InterfaceOperation-1020 Au cas où deux (ou plus) composants Interface Operation ont des propriétés {name} de même valeur, à cause d'une interface étendant une ou plusieurs interfaces, alors les modèles de composant de ces composants Interface Operation DOIVENT être équivalents (cf. la section 2.15 Équivalence des composants).
InterfaceOperation-1021 Pour la raison précédente, une bonne pratique DEVRAIT être de s'assurer, le cas échéant, que le nom local de la propriété {name} des composants Interface Operation au sein d'un espace de noms soit unique, rendant ainsi possible une telle dérivation sans erreur accidentelle.
InterfaceOperation-1023 Un composant Interface Operation DOIT satisfaire aux indications fournies par chaque style d'opération identifié par sa propriété {style}.
Location-1093 Sa valeur réelle DOIT être une liste de couples d'adresse IRI, où la première adresse IRI d'un couple DOIT être une adresse IRI absolue, comme défini dans [IETF RFC 3987], indiquant un nom d'espace de noms WSDL 2.0 (ou WSDL 1.1), et la deuxième une indication de la localisation d'un document WSDL 2.0 définissant des composants WSDL 2.0 (ou des éléments WSDL 1.1 [WSDL 1.1]) pour ce nom d'espace de noms.
MEP-1022 Un modèle d'échange de message est lui-même identifié par une adresse IRI absolue, qui est utilisée comme valeur de la propriété {message exchange pattern} du composant Interface Operation et qui définit le règlement de propagation d'incident auquel ses incidents obéissent.
MessageLabel-1024 La valeur de cette propriété DOIT correspondre au nom d'un message fictif défini par le modèle d'échange de messages.
Service-1060 Pour chaque composant Service dans la propriété {services} d'un composant Description, la propriété {name} DOIT être unique.
Types-1007 Chaque déclaration d'élément XML Schema DOIT avoir un nom qualifié QName unique.
Types-1008 Chaque définition de type XML Schema DOIT avoir un nom qualifié QName unique.