Ce document est une traduction susceptible d'évoluer. Toute amélioration est la bienvenue : e-mail.
La version française de cette traduction est :
http://www.w
3.org/2002/07/soap-translation/soap12-part1.html
Traductrice : Carine Bournez - <carine@w3.org>
La version française peut contenir des erreurs. La version anglaise de cette
spécification est l'unique version normative.
SOAP Version 1.2 Partie 2 : Ajouts
Recommandation W3C 24 June 2003
- Cette version :
- http://www.w3.org/TR/2003/REC-soap12-part2-20030624
- Latest version:
- http://www.w3.org/TR/soap12-part2
- Previous versions:
- http://www.w3.org/TR/2003/PR-soap12-part2-20030507
- Editeurs :
- Martin Gudgin, Microsoft
- Marc Hadley, Sun Microsystems
- Noah Mendelsohn, IBM
- Jean-Jacques Moreau, Canon
- Henrik Frystyk Nielsen, Microsoft
Copyright©2003W3C® (MIT, ERCIM, Keio), Tous droits réservés. W3C liability, trademark, document use, and software licensing rules apply.
1. Introduction
SOAP Version 1.2 (SOAP) est un protocole léger destiné à l'échange
d'informations structurées entre entités paires dans un environnement
décentralisé, distribué. La spécification SOAP est constituée de trois
parties. La partie 2 (le présent document) définit un ensemble d'ajouts
qui POURRAIENT être utilisés en conjonction avec la structure pour l'échange de messages
de SOAP :
-
Le Modèle de Données SOAP représente les structures de données
applicatives et les valeurs comme un graphe orienté étiqueté de noeuds
(voir 2. Modèle de Données SOAP).
-
L'Encodage SOAP définit un ensemble de règles pour encoder des
instances de données conformes au Modèle de Données SOAP pour les inclure
dans des messages SOAP (voir 3. Encodage SOAP).
-
La représentation RPC SOAP définit une convention d'utilisation
du Modèle de Données de SOAP pour représenter des appels et réponses RPC
(voir 4. Représentation SOAP RPC).
-
La section décrivant les caractéristiques et des liaisons définit
une convention pour décrire des caractéristiques et des liaisons
(voir 5. Une convention de description de caractéristiques et liaisons).
-
La section sur les Séquences d'échange de messages et Caractéristiques fournies dans SOAP définit
une séquence d'échange de messages requête-réponse et une séquence d'échange de messages supportant les requêtes non-SOAP pour des réponses SOAP (voir 6. Séquences d'échange de messages et Caractéristiques fournies dans SOAP).
-
La caractéristique de spécification de méthode Web définit une caractéristique pour contrôler les méthodes utilisées
sur le World Wide Web (voir 6.4 Caractéristique de spécification de méthode Web ).
-
La liaison SOAP HTTP définit une liaison de SOAP sur HTTP (voir [RFC 2616]) selon les règles de la structure pour les liaisons SOAP sur des protocoles, [SOAP Partie 1] (voir 7. Liaison SOAP sur HTTP).
[SOAP Partie 0] est un document non-normatif destiné à fournir
un tutoriel facile à comprendre sur les caractéristiques des spécifications SOAP Version 1.2.
[SOAP Partie 1] définit la structure SOAP pour l'échange de
messages.
Note:
Dans les versions précédentes de cette spécification, le nom
SOAP était un acronyme. Ce n'est plus le cas.
1.1 Conventions de notation
Les mots-clés "DOIT" ("MUST"), "NE DOIT PAS" ("MUST NOT"),
"OBLIGATOIRE" ("REQUIRED"), "DEVRA" ("SHALL"), "NE DEVRA PAS" ("SHALL NOT"),
"DEVRAIT" ("SHOULD"), "NE DEVRAIT PAS" ("SHOULD NOT"), "RECOMMANDÉ"
("RECOMMENDED"), "POURRAIT" ("MAY") et "OPTIONNEL" ("OPTIONAL") dans ce
document sont à interpréter comme décrit dans la RFC 2119
[RFC 2119].
Cette spécification utilise un certain nombre de préfixes d'espaces
de nommage ; ils sont répertoriés dans Table 1.
Notez que le choix de tout préfixe d'espace de nommage est arbitraire et
n'a pas de sémantique (voir [XML InfoSet]).
Les noms d'espaces de nommage de la forme générale "http://example.org/..." et "http://example.com/..." représentent
des URIs dépendantes d'une application ou d'un contexte [RFC 2396].
Cette spécification utilise la Forme de Backus-Naur Etendue (Extended Backus-Naur Form, EBNF), décrite dans XML 1.0 [XML 1.0].
Toute partie de cette spécification est normative, à l'exception des
exemples et des sections explicitement marquées comme "non normatifs".
2. Modèle de Données SOAP
Le Modèle de Données SOAP représente les structures de données et
valeurs applicatives par un graphe orienté étiqueté de noeuds.
Les composants de ce graphe sont décrits dans les sections suivantes.
Le but du modèle de données SOAP est de fournir une correspondance
entre données non basées sur XML et une représentation concrète à envoyer.
Il est important de noter que l'utilisation du modèle de données SOAP, de
l'encodage SOAP associé (voir 3. Encodage SOAP) et/ou de la
représentation RPC SOAP (voir 4. Représentation SOAP RPC) est OPTIONNELLE.
Les applications qui modélisent déjà les données en XML, par exemple grâce
au Schéma XML du W3C [XML Schema Partie 1],[XML Schema Partie 2]
pourraient se passer du modèle de données SOAP. Du fait de cette nature
optionnelle, il n'est PAS obligatoire d'implémenter le modèle de données
de SOAP, l'encodage SOAP et/ou la représentation RPC SOAP comme partie
intégrante d'un noeud SOAP.
2.1 Arcs d'un graphe
On dit des arcs d'un graphe qu'ils proviennent d'un noeud
du graphe et se terminent à un noeud du graphe. Un arc qui
provient d'un noeud du graphe est appelé arc sortant par
rapport à ce noeud. Un arc qui se termine à un noeud du graphe est appelé
arc entrant par rapport à ce noeud. Un arc POURRAIT provenir
et se terminer au même noeud d'un graphe.
Un arc POURRAIT avoir seulement un noeud de
provenance, c'est-à-dire être uniquement sortant. Un arc POURRAIT avoir
seulement un noeud de terminaison, c'est-à-dire être uniquement sortant.
Les arcs sortants d'un graphe donné POURRAIENT être distingués par une
étiquette ou leur position, ou les deux. La position est un ordre total
pour de tels arcs ; par conséquent tout arc sortant POURRAIT être
identifié par sa position.
2.1.1 Étiquettes d'arcs
Une étiquette d'arc est un nom qualifié en XML. Deux étiquettes d'arcs sont égales
si et seulement si leurs noms XML étendus sont équivalents, c-a-d si ces deux conditions sont vraies :
-
Leurs valeurs de nom local sont identiques.
-
Et l'une de ces conditions est vérifiée :
-
Leurs valeurs d'espace de nommage sont absentes.
-
Leurs valeurs d'espace de nommage sont présentes et identiques.
Voir 2.3 Valeurs pour l'utilisation d'étiquettes d'arcs
et de position pour distinguer les membres de valeurs encodées et
[XML Schema Partie 2] pour plus d'information sur la
comparaison de noms qualifiés en XML.
2.2 Noeuds d'un graphe
Un noeud d'un graphe possède zéro ou plus arcs sortants.
Un noeud qui n'a pas d'arc sortant a une valeur lexicale optionnelle. Tous les noeuds d'un
graphe ont un nom de type optionnel, du type xs:QName dans l'espace de nommage
"http://www.w3.org/2001/XMLSchema" (voir XML Schema [XML Schema Partie 2])
2.2.1 Noeuds référence simple et multiple
Un noeud d'un graphe pourrait être référence simple ou
référence multiple. Une référence simple a un seul arc
entrant. Un noeud référence multiple a plusieurs arcs sortants.
2.3 Valeurs
Une valeur simple est représentée comme un noeud d'un graphe avec une valeur lexicale.
Une valeur composée est représentée comme un noeud d'un graphe avec zéro ou plusieurs
arcs sortants, comme ceci :
-
Un noeud d'un graphe dont les arcs sortants sont
distingués seulement par leur étiquette est appelé "struct" (structure).
Les arcs sortants d'un "struct" DOIVENT être étiquetés avec des noms
distincts (voir 2.1.1 Étiquettes d'arcs).
-
Un noeud d'un graphe dont les arcs sortants sont
distingués seulement par leur position est appelé "array" (tableau).
Les arcs sortants d'un "array" NE DOIVENT PAS être étiquetés.
3. Encodage SOAP
L'encodage SOAP donne une manière d'encoder des instances de données
conformes au modèle de données décrit dans 2. Modèle de Données SOAP.
Cet encodage POURRAIT être utilisé pour transmettre des données dans
des blocs d'en-tête SOAPet/ou des corps SOAP. D'autres modèles de
données, d'autres encodages du modèle de données SOAP de même que des
données non encodées POURRAIENT aussi être utilisées dans les messages
SOAP (voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1], Attribut SOAP encodingStyle -style
d'encodage- pour la spécification de styles d'encodages autres
et voir 4. Représentation SOAP RPC pour les restrictions sur les
modèles de données et les encodages utilisés pour représenter des
appels de procédure distante -Remote Procedure Calls- SOAP).
Les règles de sérialisation définies dans cette section sont
identifiée par l'URI
"http://www.w3.org/2003/05/soap-encoding". Les messages
SOAP utilisant cette sérialisation particulière DEVRAIENT l'indiquer
grâce à l'item d'information attribut SOAP encodingStyle
(voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1] Attribut SOAP encodingStyle).
3.1 Correspondance entre XML et le modèle de données SOAP
XML permet un encodage des données très flexible. L'encodage SOAP
définit un ensemble de règles restreint pour encoder les graphes
décrit dans 2. Modèle de Données SOAP. Cette section
définit l'encodage à un haut niveau et les sections suivantes
décrivent les règles d'encodage plus en détails. Les encodages
décrits dans cette section peuvent être utilisé en conjonction
avec la correspondance des appels et réponses RPC spécifiée
dans 4. Représentation SOAP RPC.
Les encodages sont décrits ci-après du point de vue du
désérialiseur. Dans chaque cas, on suppose la présence d'une
sérialisation XML et on décrit la correspondance avec un graphe.
Classiquement, un graphe donné peut avoir plusieurs encodages.
Lorsqu'on sérialise un graphe pour le transmettre dans un message
SOAP, on DOIT utiliser une représentation qui se
désérialise en un graphe identique ; si plusieurs représentations
sont possibles sous cette contrainte, n'importe laquelle de celles-ci POURRAIT
être utilisée. Lorsqu'on reçoit un
message SOAP encodé, toutes les représentations DOIVENT être
acceptées.
3.1.1 Encodage d'arcs et de noeuds de graphe
Chaque arc d'un graphe est encodé comme un item d'information
élément et chaque item d'information élément
représente un arc d'un graphe. 3.1.3 Encodage de valeurs composées
décrit la relation entre les étiquettes d'arcs et les propriétés
[local name] et [namespace name]
de ces items d'information éléments.
Le noeud d'un graphe où se termine un arc est déterminé en
examinant le XML sérialisé de la manière suivante :
-
Si l'item d'information élément représentant
l'arc n'a pas d'item d'information attribut
ref (voir 3.1.5.2 Item d'Information Attribut ref) parmi ses
attributs, alors on dit que cet item d'information
élément représente un noeud dans le graphe
et l'arc se termine sur ce noeud.
Dans ce cas, l'item d'information
élément représente à la fois un arc et un noeud du graphe
-
Si l'item d'information élément représentant
l'arc possède un item d'information attribut
ref (voir 3.1.5.2 Item d'Information Attribut ref) parmi ses
attributs, alors la valeur de cet item d'information
attribut DOIT être identique à la valeur d'exactement
un item d'information attribut id
(voir 3.1.5.1 Item d'Information Attribut id) dans la même enveloppe.
Dans ce cas, l'arc se termine au noeud représenté par l'
item d'information élément sur lequel l'
item d'information attribut id apparaît.
Cet item d'information élément DOIT se trouver
dans la portée d'un attribut encodingStyle avec la
valeur "http://www.w3.org/2003/05/soap-encoding"
(voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1],
Attribut SOAP encodingStyle).
Tous les noeuds du graphe sont encodés selon le point 1 ci-dessus.
Les arcs entrants supplémentaires pour les noeuds référence multiple
sont encodés comme indiqué dans le point 2 ci-dessus.
3.1.2 Encodage de valeurs simples
La valeur lexicale d'un noeud d'un graphe représentant une valeur simple
est la séquence de caractères Unicode identifiée par l'
item d'information caractère fils de l'
item d'information élément représentant ce noeud.
L'item d'information élément représentant un noeud valeur simple POURRAIT
avoir parmi ses attributs un item d'information attribut nodeType
(voir 3.1.7 Item d'information attribut NodeType).
Notez que certains caractères Unicode ne peuvent
pas être représentés en XML (voir [XML 1.0]).
3.1.3 Encodage de valeurs composées
Un arc sortant d'un noeud d'un graphe est encodé comme un
item d'information élément fils de l'
item d'information élément représentant le noeud (voir
3.1.1 Encodage d'arcs et de noeuds de graphe). Des règles particulières
s'appliquent en fonction du type de valeur composée que le noeud
du graphe représente. Ces règles sont les suivantes :
-
Pour un arc de graphe distingué par son étiquette, les propriétés
[local name] et [namespace name] de l'item d'information élément
fils déterminent ensemble la valeur de l'étiquette de l'arc.
-
Pour un arc de graphe distingué par sa position :
-
La position ordinale de l'arc du graphe correspond à la
position de l'item d'information élément relativement
à ses frères.
-
Les propriétés [local name] et [namespace name]
de l'item d'information élément fils ne sont pas
significatives.
-
L'item d'information élément représentant un noeud valeur
composée POURRAIT avoir parmi ses attributs un item d'information
attribut nodeType (voir 3.1.7 Item d'information attribut NodeType).
-
Les règles suivantes d'appliquent à l'encodage d'un noeud
d'un graphe représentant un tableau ("array") :
-
Si un arc d'un graphe ne se termine pas sur un noeud du graphe,
alors il peut soit être omis dans la sérialisation soit être
encodé comme un item d'information élément avec un
item d'information attribut xsi:nil
dont la valeur est "true".
3.1.4 Calcul de la propriété nom du type (Type Name)
La propriété nom du type (Type Name) d'un noeud d'un graphe est une paire
{nom d'espace de nommage (namespace name), nom local (local name)}
calculée comme suit :
-
Si l'item d'information élément représentant le noeud
du graphe possède un item d'information attribut
xsi:type parmi ses attributs, alors la propriété nom du type
du noeud est la valeur de l'item d'information attribut
xsi:type .
Note:
Cet attribut est du type xs:QName
(voir XML Schema [XML Schema Partie 2]) ; sa valeur est constituée
de la paire
{nom d'espace de nommage (namespace name), nom local (local name)}.
Ni le préfixe utilisé pour construire le QName (nom qualifié) ni
une autre information
relative à la définition du type ne sont considérés comme faisant
partie de la valeur. Le graphe SOAP transporte seulement le nom
qualifié du type.
-
Si l'item d'information élément parent de l'
item d'information élément représentant le noeud du
graphe possède un item d'information attribut
enc:itemType (voir 3.1.4.1 Item d'Information Attribut itemType) parmi
ses attributs, alors la propriété nom du type du noeud du graphe est
la valeur de l'item d'information attribut
enc:itemType .
-
Sinon, la valeur de la propriété nom du type du noeud du graphe est
non spécifiée.
Note:
Ces règles définissent comment la propriété nom du type d'un noeud
dans un graphe est calculée à partir d'un encodage sérialisé. Cette
spécification n'impose pas de validation par quel langage de schéma
ou système de typage que ce soit. Elle n'inclut pas non plus de types
pré-construits ou de fautes standardisées pour refléter les conflits
valeur/nom du type.
Cependant, rien n'empêche de développer des spécifications
supplémentaires pour décrire l'utilisation de l'encodage SOAP avec des
langages de schéma ou des systèmes de typage particuliers. De telles
spécifications supplémentaires POURRAIENT imposer une validation
utilisant un langage de schéma particulier et POURRAIENT spécifier
des fautes à générer si la validation échoue. De telles
spécifications supplémentaires POURRAIENT spécifier des ajouts au
graphe désérialisé basés sur l'information déterminée par cette
validation. L'utilisation par l'encodage SOAP de xsi:type
est destinée à faciliter l'intégration avec le langage XML Schema
du W3C (voir C. Utilisation de W3C XML Schema avec l'encodage SOAP). D'autres langages de schéma
basés sur XML, schémas de données et systèmes de typage programmatiques
POURRAIENT être utilisés à la seule condition d'être compatibles avec
la sérialisation décrite dans cette spécification.
3.1.4.1 Item d'Information Attribut itemType
L'item d'information attribut itemType possède
les propriétés d'Infoset suivantes :
-
Le [local name] itemType .
-
Le [namespace name] "http://www.w3.org/2003/05/soap-encoding".
-
Une propriété [specified] ayant la valeur "true".
Le type de l'item d'information attribut
itemType est xs:QName.
La valeur de l'item d'information attribut
itemType est utilisée pour calculer la propriété
nom du type (voir 3.1.4 Calcul de la propriété nom du type (Type Name)) des membres d'un
tableau.
3.1.5 Identifiants uniques
3.1.5.1 Item d'Information Attribut id
L'item d'information attribut id possède les
propriétés d'Infoset suivantes :
Le type de l'item d'information attribut id
est xs:ID.
La valeur de l'item d'information attribut id
est un identifiant unique auquel on peut faire référence par
un item d'information attribut ref
(voir 3.1.5.2 Item d'Information Attribut ref).
3.1.5.2 Item d'Information Attribut ref
L'item d'information attribut ref
possède les propriétés d'Infoset suivantes :
Le type de l'item d'information attribut ref
est xs:IDREF.
La valeur de l'item d'information attribut ref
est une référence à un identifiant unique défini par un
item d'information attribut id
(voir 3.1.5.1 Item d'Information Attribut id).
3.1.5.3 Contraintes sur les items d'information attributs id et ref
La valeur de l'item d'information attribut ref
DOIT aussi être la valeur d'exactement un
item d'information attribut id .
Un item d'information attribut ref et
un item d'information attribut id NE DOIVENT
PAS apparaître sur le même item d'information élément.
3.1.6 Item d'Information Attribut arraySize
L'item d'information attribut arraySize
(tailleDuTableau) possède les propriétés d'Infoset suivantes :
Le type de l'item d'information attribut arraySize
est enc:arraySize.
La valeur de l'item d'information attribut arraySize DOIT être conforme à la grammaire EBNF suivante
| [1] | valeurTailleTableau | ::= | ("*" | tailleConcrete) tailleConcreteSuivante* |
| [2] | nextConcreteSize | ::= | espaceblanc tailleConcrete |
| [3] | tailleConcrete | ::= | [0-9]+ |
| [4] | espaceblanc | ::= | (#x20 | #x9 | #xD | #xA)+ |
Les dimensions du tableau sont représentées par chaque item dans
la liste des tailles (taille non spécifiée dans le cas d'une
astérisque). Le nombre d'items dans la liste représente le nombre
de dimensions du tableau. L'astérisque, si elle est présente, DOIT
apparaître seulement en première position dans la liste.
La valeur par défaut de l'item d'information
attribut arraySize est "*", ce qui signifie que par
défaut les tableaux sont considérés de taille non spécifiée.
3.1.7 Item d'information attribut NodeType
L'item d'information attribut nodeType
(typeValeur) possède les propriétés d'Infoset suivantes :
-
Le [local name] nodeType .
-
Le [namespace name] "http://www.w3.org/2003/05/soap-encoding".
-
Une propriété [specified] ayant pour valeur "true".
Le type de l'item d'information attribut nodeType
est enc:nodeType.
La valeur de l'item d'information attribut nodeType
DOIT, si elle est présente, être l'une des chaînes "simple", "struct" ou "array".
La valeur indique le genre de valeur que ce noeud représente -valeur simple, valeur
composée structure (struct) ou valeur composée tableau (array) respectivement.
3.2 Décodage de fautes
Lors de la désérialisation, un récepteur SOAP :
4. Représentation SOAP RPC
Un des buts de SOAP en terme de conception est de faciliter
l'échange de messages qui correspondent bien aux définitions et invocations
de méthode et aux appels de procédure dans les langages de programmation
courants. Pour ce faire, cette section définit une représentation
uniforme de requêtes et réponses RPC (Remote Procedure Call). Elle ne définit pas de correspondance
réelle avec un langage de programmation en particulier. La représentation
est entièrement indépendante de toute plate-forme et des efforts
importants ont été réalisés pour encourager une utilisation cohérente
avec le Web en général.
Comme indiqué dans la section 2. Modèle de Données SOAP,
l'utilisation et l'implémentation de la représentation SOAP RPC est
OPTIONNELLE.
L'item d'information attribut encodingStyle
(voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1] Attribut SOAP encodingStyle)
est utilisé pour indiquer le style d'encodage de la représentation RPC.
L'encodage ainsi spécifié DOIT supporter le 2. Modèle de Données SOAP.
Le style d'encodage défini dans 3. Encodage SOAP supporte ces constructions et convient par conséquent
à une utilisation avec la représentation SOAP RPC.
Cette représentation SOAP RPC n'est fondée sur aucune liaison de SOAP
sur un protocole. Lorsque SOAP est lié à HTTP, une invocation RPC
correspond naturellement à une requête HTTP et une réponse RPC à une
réponse HTTP (voir 7. Liaison SOAP sur HTTP). Cependant, la
représentation SOAP RPC n'est pas limité à la seule liaison SOAP sur HTTP.
Pour invoquer un appel RPC, les informations suivantes sont
nécessaires :
L'adresse du noeud SOAP visé.
Un nom de procédure ou de méthode.
Les identités et valeurs de tout argument à passer à la
procédure ou méthode. Les arguments utilisés pour identifier des ressources
Web DEVRAIENT être distingués de ceux représentant des données ou
informations de contrôle (voir 4.1.1 Identification of RPC Resources.)
Les valeurs de propriétés requises par toute caractéristique
de la liaison à utiliser. Par exemple "GET" ou
"POST" pour la propriété http://www.w3.org/2003/05/soap/features/web-method/Method de 6.4 Caractéristique de spécification de méthode Web .
Des données d'en-tête optionnelles.
Le RPC SOAP repose sur la liaison sur protocole pour fournir un
mécanisme transportant l'URI du noeud SOAP cible. Pour HTTP, l'URI de
la requête indique la ressource sur laquelle l'invocation est effectuée.
Plutôt que d'imposer que ce soit une URI valide, SOAP ne met aucune
restriction sur la forme de l'identifiant (voir RFC 2396 [RFC 2396]
pour plus d'informations sur les URIs). La section
4.1.1 Identification of RPC Resources discute plus avant de l'utilisation des
URIs pour identifier les ressources RPC.
La représentation SOAP RPC emploie la 6.2 Séquence d'échange de messages SOAP de type Requête-Réponse
et 6.3 Séquence d'échange de message SOAP Réponse. Utiliser la représentation SOAP RPC avec
d'autres séquences d'échange de messages POURRAIT être possible, mais ceci
est hors de la portée de cette spécification.
4.1 Utilisation de RPC sur le World Wide Web
Les guides suivants DEVRAIENT être suivis pour le déploiement
d'applications SOAP RPC sur le World Wide Web.
4.1.1 Identification of RPC Resources
Le World Wide Web identifie les ressources par des URIs, mais les
conventions de programmation courantes véhiculent les informations
d'identification dans les arguments des procédures ou dans leur nom. Par
exemple, l'appel :
majQuantiteEnStock(PieceNumero="123", NouvQuantite="200")
suggère que la ressource à mettre à jour est la
QuantiteEnStock de PieceNumero "123".
En conséquence, lorsque l'on fait la correspondance de ou vers un appel de
méthode ou procédure dans un langage de programmation, tout argument
servant à identifier les ressources (comme le numéro de pièce ci-dessus)
devrait si nécessaire être représenté dans l'URI à laquelle le message
SOAP est adressé.
Lorsque l'on fait la correspondance de ou vers un appel de
méthode ou procédure dans un langage de programmation, dont le nom
identifie ou qualifie l'identification d'une ressource (comme
QuantiteEnStock ci-dessus), ce nom ou cette qualification devrait si
nécessaire être représenté dans l'URI à laquelle le message SOAP
est adressé.
Aucune manière standard de représenter les arguments ou les noms de
méthodes n'est fournie par cette spécification.
Note:
Des conventions d'encodage spécifique dans des URIs de noms de procédure
et arguments, ainsi que de contrôle d'inclusion de tels
arguments dans le corps d'appels RPC SOAP, peuvent être établies en
conjonction avec le développement de langages de description d'interfaces
de Services Web. Elles peuvent être développées lorsque SOAP est lié à
un langage de programmation particulier ou établies pour une application
ou sur une base spécifique à une procédure.
4.1.2 Distinction entre récupération de ressource et autres RPCs
Le World Wide Web dépend de mécanismes optimisant les tâches couramment
réalisées de récupérations d'informations. En particulier, les protocoles
comme HTTP [RFC 2616] fournissent une méthode GET,
utilisée pour effectuer des récupérations sûres, c'est-à-dire idempotentes,
sans effets de bord et pour lesquelles des considérations de sécurité
n'empêchent pas l'utilisation de résultats mis en cache ou basés sur
une identification de ressource par URI.
Certains appels de procédure ou méthode représentent des requêtes de
récupération d'information. Par exemple, l'appel :
obtenirQuantiteEnStock(PieceNumero="123")
peut être utilisé pour récupérer la quantité établie dans l'exemple
précédent.
Les conventions suivantes peuvent être employées pour implémenter des
récupérations en SOAP et d'autres RPC sur le Web :
La représentation SOAP RPC ne définit pas d'autre valeur pour
http://www.w3.org/2003/05/soap/features/web-method/Method .
4.2 RPC and SOAP Body
Les invocations RPC (sauf pour les récupérations sûres : voir
4.1.2 Distinction entre récupération de ressource et autres RPCs) et les réponses sont toutes
deux transportées dans l'élément SOAP Body (corps) (voir dans la partie 1 de SOAP 1.2
[SOAP Partie 1] SOAP Body) en utilisant
les représentations suivantes :
4.2.1 Invocation RPC
Une invocation RPC est modélisée comme suit :
Les applications POURRAIENT traiter les invocations avec des
paramètres manquants mais POURRAIENT aussi échouer dans le traitement
de l'invocation et renvoyer une faute.
4.2.2 Réponse RPC
Une réponse RPC est modélisée comme suit :
La réponse est représentée par un simple
"struct" contenant un arc sortant pour la valeur de retour et chaque
paramètre en [sortie] ou [entrée/sortie].
-
Chaque paramètre est représenté par un arc sortant
avec une étiquette correspondant au nom du paramètre. Les conventions
de B. Correspondance de noms définis par une application avec des noms XML DEVRAIENT être utilisées pour représenter
les noms de paramètres qui ne sont pas légaux en XML.
Une valeur de retour non vide (non-void) est représentée comme suit :
Il DOIT y avoir un arc sortant, avec le nom local result
et l'espace de nommage "http://www.w3.org/2003/05/soap-rpc", se
terminant sur un noeud terminal.
Le type de ce noeud terminal est xs:QName et
sa valeur est le nom de l'arc sortant qui termine sur la valeur de retour
réelle.
Si la valeur de retour de la procédure est vide (void) alors il NE DOIT PAS y
avoir d'arc sortant avec le nom local result et l'espace de nommage
"http://www.w3.org/2003/05/soap-rpc".
Les fautes d'invocation sont gérées selon les règles
de 4.4 Fautes RPC. Si une liaison sur un protocole ajoute
des règles supplémentaires pour l'expression des fautes, celles-ci
DOIVENT aussi être suivies.
4.2.3 Restriction de l'encodage SOAP
Lorsque l'on utilise l'encodage SOAP (voir
3. Encodage SOAP) en conjonction avec les conventions
décrites ici, le Body (corps) SOAP DOIT contenir un seul
item d'information élément fils, qui est l'invocation
ou la réponse RPC en "struct" sérialisé.
4.3 RPC et en-tête SOAP
Des informations supplémentaires applicables à l'encodage
d'invocation RPC mais ne faisant pas partie de la signature formelle
de la procédure ou méthode POURRAIENT être exprimées dans une enveloppe
SOAP transportant une invocation ou réponse RPC.
De telles informations supplémentaires DOIVENT être exprimées sous
forme de blocs d'en-tête SOAP.
4.4 Fautes RPC
La représentation SOAP RPC introduit des sous-codes de faute SOAP
supplémentaires à utiliser en conjonction avec les codes de fautes
décrits dans la partie 1 SOAP 1.2 [SOAP Partie 1] Codes de faute SOAP.
Les erreurs survenant pendant les invocations RPC sont rapportées
selon les règles suivantes (par ordre de préséance décroissante) :
Une faute avec pour Value (valeur) de Code
"env:Receiver" DEVRAIT être générée lorsque le
récepteur ne peut pas traiter le message pour une raison temporaire,
par ex. s'il n'a plus de mémoire.
Note:
Au long de ce document, le terme Value (valeur) de Code
est utilisé pour abréger "valeur de l'item d'information élément
Value fils de l'item d'information élément Code
(voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1],
Élément SOAP Code ).
Une faute avec pour Value (valeur) de Code
"env:DataEncodingUnknown" DEVRAIT être générée lorsque
les arguments sont encodés avec un encodage de données inconnu du
récepteur.
Une faute avec pour Value (valeur) de Code
"env:Sender" et pour Value (valeur) de
Subcode "rpc:ProcedureNotPresent"
POURRAIT être générée lorsque le récepteur ne supporte pas la
procédure ou la méthode spécifiée.
Note:
Au long de ce document, le terme Value (valeur) de Subcode
est utilisé pour abréger "valeur de l'item d'information élément
Value fils de l'item d'information élément Subcode
(voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1],
Élément SOAP Subcode ).
Une faute avec pour Value (valeur) de Code
"env:Sender" et pour Value (valeur) de
Subcode "rpc:BadArguments" DOIT être générée
lorsque le récepteur ne peut pas faire l'analyse des arguments ou
lorsqu'il se produit un décalage dans le nombre et/ou le type d'arguments
entre ce que le récepteur attend et ce qui a été envoyé.
D'autres fautes se produisant dans une extension ou depuis
l'application DEVRAIENT être générée comme décrit dans la partie 1 de SOAP 1.2
[SOAP Partie 1] Codes de faute SOAP.
Dans tous les cas, les valeurs des items d'information
éléments Detail (détail) et Reason (raison)
sont définis par l'implémentation. Les détails de leur utilisation
POURRAIENT être spécifiés par un document externe.
Note:
Les émetteurs peuvent recevoir différentes fautes parmi
celles listées ci-dessus en réponse à une invocation RPC si le
récepteur ne supporte pas la convention RPC (optionnelle) décrite ici.
5. Une convention de description de caractéristiques et liaisons
Cette section décrit une convention de description de caractéristiques
(MEPs inclus) et de liaisons, en termes de propriétés et valeurs de propriétés.
La convention est suffisant pour décrire les états distribués de spécifications
de caractéristiques et de liaisons, comme demandé par la structure
pour les liaisons (voir dans la partie 1 de SOAP 1.2
[SOAP Partie 1] Structure pour liaison SOAP
sur un protocole). Elle est utilisée pour décrire
une séquence d'échange de messages (MEP) Requête-Réponse (voir
6.2 Séquence d'échange de messages SOAP de type Requête-Réponse), une MEP Réponse (voir 6.3 Séquence d'échange de message SOAP Réponse), la caractéristiques Méthode Web (Web Method) (voir
6.4 Caractéristique de spécification de méthode Web ) et la liaison de SOAP sur HTTP (voir
7. Liaison SOAP sur HTTP) dans le reste de ce document.
En même temps que cette convention elle-même, un modèle informel est
défini pour décrire comment les propriétés se propagent dans un système SOAP.
Notez que ce modèle se veut seulement illustratif et n'est pas censé impliquer
une quelconque contrainte sur la structure ou l'organisation en couches d'une
implémentation SOAP.
5.1 Modèle et prorpiétés
En général, un message SOAP est l'information qu'un noeud SOAP souhaite
échanger avec un autre noeud SOAP en respectant un ensemble particulier de
caractéristiques, notamment une séquence d'échange (MEP). De plus, des
informations essentielles pour l'échange peuvent ne pas faire partie du
message lui-même. Elles sont parfois appelées méta-données. Dans le modèle,
le message, toute méta-donnée de message et les items d'information divers
qui permettent les caractéristiques sont représentés comme des abstractions
appelées propriétés.
5.1.1 Propriétés
Selon la convention, les propriétés sont représentés comme suit :
Les propriétés sont dénommées par des URIs
Lorsque cela est approprié, les valeurs de propriété DEVRAIENT
avoir un type en Schéma XML [XML Schema Partie 1] [XML Schema Partie 2] listé dans la spécification qui introduit
la propriété.
5.1.2 Portée de propriété
Les propriétés dans un noeud SOAP peuvent différer en termes de portée
et d'origine de leur valeur.
Comme l'indique la figure
ci-dessous, on fait une distinction entre les propriétés pour un échange de
messages et celles à plus large portée en les assignant à différents
conteneurs appelés respectivement Contexte d'échange de messages
(Message Exchange Context) et Contexte d'environnement (Environment Context). Toutes les
propriétés, indépendamment de leur portée, sont partagées par SOAP
et une liaison particulière.
Figure 1: Modèle décrivant les propriétés partagées entre SOAP et liaison
5.1.2.1 Contexte d'échange de messages
Un contexte d'échange de messages est une collection de propriétés dont la portée
est limitée à une instance d'une séquence d'échange de messages (MEP) donnée. Un exemple
de propriété d'un contexte d'échange de message est l'identifiant de la séquence d'échange
de messages utilisée.
5.1.2.2 Contexte d'environnement
Le contexte d'environnement est une collection de propriétés dont la portée
s'étend au-delà d'une instance d'une séquence d'échange de messages (MEP).
L'adresse IP du noeud SOAP ou la date et l'heure courante sont des exemples
de propriétés de contexte d'environnement.
Les valeurs de propriétés dans l'environnement pourraient dépendre de
circonstances locales (comme décrit par la flèche externe de l'environnement
dans la figure ci-dessus).
Plus spécifiquement, les propriétés dans l'exemple peuvent être influencées
par un ID d'utilisateur dans un système d'exploitation sous le nom duquel
un échange de messages est effectué. La correspondance entre informations
dans une implémentation particulière et de telles propriétés est hors
sujet pour une structure pour liaisons, bien que la représentation
abstraite de ces informations sous forme de propriétés ne le soit pas.
5.1.3 Propriétés et caractéristiques
Une caractéristique peut être exprimée au travers de propriétés multiples
et une seule propriété peut permettre plusieurs caractéristiques. Par exemple,
les propriétés appelées ID utilisateur et Mot de passe peuvent être utilisées
pour permettre une caractéristique appelée Authentification. Dans un second
exemple, une seule propriété appelée ID message pourrait être utilisée pour
permettre une caractéristique appelée Transaction et une seconde caractéristique
appelée Corrélation de message.
6. Séquences d'échange de messages et Caractéristiques fournies dans SOAP
6.1 Conventions de propriétés pour séquances d'échange de messages (MEPs) SOAP
Table 2 décrit les propriétés
(en accord avec la convention de dénommination de propriété
définie dans ce document) qui supportent la description de
séquences d'échange de messages (MEPs). D'autres propriétés pourraient
être impliquées dans la spécification de MEPs particulières mais
les propriétés de ce tableau sont généralement applicables à tous
les MEPs.
Table 2: Définitions de propriété supportant la description de MEPs
| Nom de propriété |
Description de propriété |
Type de propriété |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName |
Le nom de la MEP en action. |
xs:anyURI |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason |
Une valeur qui dénote une raison
spécifique à la séquence, indépendante de la liaison, de l'échec
d'un échange de message. Les spécifications de liaisons sur protocoles
sous-jacents pourraient définir des propriétés pour transporter
plus de détails sur l'échec, spécifiques à la liaison. |
xs:anyURI |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role |
L'identifiant du rôle, spécifique à une séquence, d'un noeud
local SOAP participant à l'échange de message. |
xs:anyURI |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State |
L'identifiant de l'état courant de l'échange de message.
Cette valeur est gérée par l'instance de la liaison et pourrait
être inspectée par d'autres entités surveillant la progression de
l'échange de message. |
xs:anyURI |
6.2 Séquence d'échange de messages SOAP de type Requête-Réponse
Cette section définit la séquence d'échange de messages (MEP) appelée
"Requête-Réponse". La description est une présentation abstraite de
l'opération de cette MEP. Elle ne vise pas à décrire une implémentation
réelle ni suggérer comment une implémentation réelle devrait être
construite.
6.2.2 Description
La séquence d'échange de messages (MEP) Requête-Réponse définit une
séquence pour l'échange d'un message SOAP agissant comme une requête suivi d'un
message SOAP agissant comme une réponse. En l'absence d'échec sur le protocole
sous-jacent, cette MEP est constituée d'exactement deux messages SOAP.
Dans le déroulement normal d'un échange de messages
conforme à la MEP Requête-Réponse, un message de requête est d'abord transféré
du noeud SOAP émettant la requête vers le noeud SOAP y répondant. Suite au
traitement avec succès du message de requête par le noeud répondant, un
message de réponse est transféré du noeud SOAP répondant vers le noeud SOAP
demandeur.
Un déroulement anormal de l'échange de messages Requête-Réponse
peut être causé par un échec du transfert du message de requête, un échec
de traitement de la requête par le noeud SOAP répondant, ou un échec du
transfert du message de réponse. Ces échecs peuvent être silencieux pour
l'un ou les deux noeuds SOAP impliqués, ou peut résulter en une génération
d'une faute SOAP ou spécifique à la liaison (voir 6.2.4 Gestion de faute).
De plus, lors d'un déroulement anormal, chaque noeud SOAP impliqué dans
l'échange de message peut avoir sa propre détermination du succès de
l'échange de messages.
La portée de la MEP Requête-Réponse est limitée à
l'échange d'un message de requête et un message de réponse entre un
noeud SOAP demandeur et un noeud SOAP répondant. Cette séquence
ne requiert pas de corrélation entre requêtes mutiples ni de
synchronisation spécifique pour les requêtes multiples.
Les implémentations POURRAIENT choisir de supporter les requêtes
multiples (et le traitement de réponses associé) survenant en
même temps.
6.2.3 Description de la Machine à États
La MEP Requête-Réponse définit un ensemble de propriétés décrites dans
Table 3.
Table 3: Définitions de propriétés pour la MEP Requête-Réponse
| Nom de la propriété |
Description de la propriété |
Type de la propriété |
http://www.w3.org/2003/05/soap/mep/OutboundMessage |
Une structure abstraite représentant le message sortant actuel
de l'échange de messages. Ceci est une abstraction à la fois de
l'enveloppe SOAP et de toute autre structure d'information transférée
avec l'enveloppe |
Not specified |
http://www.w3.org/2003/05/soap/mep/InboundMessage |
Une structure abstraite représentant le message entrant actuel
de l'échange de messages. Ceci est une abstraction à la fois de
l'enveloppe SOAP et de toute autre structure d'information transférée
avec l'enveloppe |
Not specified |
http://www.w3.org/2003/05/soap/mep/ImmediateDestination |
L'identifiant de la destination immédiate d'un message sortant. |
xs:anyURI |
http://www.w3.org/2003/05/soap/mep/ImmediateSender |
L'identifiant de l'émetteur immédiate d'un message entrant. |
xs:anyURI |
Pour initier un échange de messages conforme à la MEP Requête-Réponse,
le noeud SOAP demandeur instancie un contexte local d'échange de messages.
Table 4 décrit comment le contexte est initialisé.
Table 4: Instanciation d'un Contexte d'échange de messages pour
un noeud SOAP émettant une requête.
| Nom de la propriété |
Valeur de la propriété |
Notes |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName |
"http://www.w3.org/2003/05/soap/mep/request-response/"
|
|
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason |
"None" |
Une URI relative dont l'URI de base est la valeur de
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role |
"RequestingSOAPNode/" |
Une URI relative dont l'URI de base est la valeur de
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State |
"Init" |
Une URI relative dont l'URI de base est la valeur de
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role |
http://www.w3.org/2003/05/soap/mep/OutboundMessage |
Une abstraction du message de requête |
|
http://www.w3.org/2003/05/soap/mep/ImmediateDestination |
Un identifiant (URI) qui désigne le noeud SOAP répondant |
|
Il pourrait y avoir d'autres propriétés concernant la mise en
oeuvre de l'instance de contexte d'échange de messages. Ces
propriétés sont initialisées selon leur propre spécification de
caractéristique.
Une fois que le contexte d'échange de message est initialisé,
le contrôle du contexte est passé à une instance locale (conforme)
de liaison.
Le diagramme ci-dessous montre les transitions
d'états logiques aux noeuds SOAP demandeur et répondant pendant la
durée de l'échange de messages. À chaque noeud SOAP, l'instance locale
de liaison met à jour (logiquement) la valeur de la propriété
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State
pour refléter l'état courant de l'échange de messages. Les noms d'état sont
des URIs relatives à une URI de base transportée dans la propriété
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role
du contexte d'échange de message local.
Figure 2: Diagramme de transition de la MEP Requête-Réponse.
Lorsque l'instance locale de liaison au noeud répondant commence
à recevoir un message de requête entrant, elle instancie (logiquement)
un contexte d'échange de message. Table 5 décrit
les propriétés que la liaison initialise lors de l'instanciation du
contexte.
Table 5: Instanciation du contexte d'échange de messages pour
un message de requête entrant
| Nom de la propriété |
Valeur de la propriété |
Notes |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName |
"http://www.w3.org/2003/05/soap/mep/request-response/"
|
Initialisée dès que possible pendant la durée de l'échange de message. |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason |
"None" |
Une URI relative dont l'URI de base est la valeur de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role |
"RespondingSOAPNode"
|
Une URI relative dont l'URI de base est la valeur de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName
Initialisée dès que possible pendant la durée de l'échange de message. |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State |
"Init" |
Une URI relative dont l'URI de base est la valeur de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role |
Lorsque les noeuds SOAP demandeur et répondant passent une transition
entre états, l'instance locale de liaison met à jour (logiquement) un
certain nombre de propriétés.
Table 6 et Table 7 décrivent ces mises à jour pour les noeuds
demandeur et répondant, respectivement.
Table 6: Transitions d'état pour le noeud SOAP émettant la requête
| EtatCourant |
Condition de transition |
EtatSuivant |
Action |
| "Init" |
Inconditionnelle |
"Requesting" (Émission de la requête) |
Démarre la transmission du message de requête
sous forme abstraite dans http://www.w3.org/2003/05/soap/mep/OutboundMessage . |
| "Requesting" |
Échec de la transmission de message |
"Fail" (échoue) |
Fixer
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason (RaisonEchec) à
"transmissionFailure" (echecTransmission) |
| Commence à recevoir le message de réponse |
"Sending+Receiving" (envoi+réception) |
Fixer
http://www.w3.org/2003/05/soap/mep/ImmediateSender de manière à indiquer l'émetteur du message de réponse (pourrait varier parmi les valeurs de
http://www.w3.org/2003/05/soap/mep/ImmediateDestination ).
Commence à mettre à disposition une abstraction du message de réponse dans http://www.w3.org/2003/05/soap/mep/InboundMessage . |
| "Sending+Receiving" |
Échec de l'échange de message |
"Fail" (échec) |
Fixer
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason (RaisonEchec) to
"exchangeFailure" (echecEchange) |
| Envoi du message de requête terminé. Réception du message de réponse terminée. |
"Success" (succès) |
|
Table 7: Transitions d'état du noeud SOAP répondant
| Etat courant |
Condition de transition |
EtatSuivant |
Action |
| "Init" |
Commence à recevoir le message de requête |
"Receiving" (Réception) |
Fixer
http://www.w3.org/2003/05/soap/mep/ImmediateSender de manière à indiquer l'émetteur du message de requête (si déterminable).
Commence à mettre à disposition un message de requête dans http://www.w3.org/2003/05/soap/mep/InboundMessage .
Passer le contrôle du contexte d'échange de messages au processeur SOAP. |
| "Receiving" |
Échec de réception du message |
"Fail" (échec) |
Fixer
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason (RaisonEchec) à
"receptionFailure" (echecReception). |
Commence un message de réponse disponible dans
http://www.w3.org/2003/05/soap/mep/OutboundMessage |
"Receiving+Sending" (Réception+Envoi) |
Démarrer la transmission du message de réponse sous forme abstraite dans http://www.w3.org/2003/05/soap/mep/OutboundMessage . |
| "Receiving+Sending" |
Échec de l'échange de message |
"Fail" (échec) |
Fixer http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason (RaisonEchec) à "exchangeFailure" (echecEchange). |
| Réception du message de requête terminé. Envoi du message de réponse terminée. |
"Success" (succès) |
|
Les liaisons implémentant cette MEP POURRAIENT offrir la transmission
en flux continu de réponses SOAP. C'est-à-dire que les noeuds SOAP répondants POURRAIENT commencer la transmission de la réponse SOAP alors qu'une requête SOAP est encore en train d'être reçue et traitée. Lorsque des noeuds SOAP implémentent des liaisons supportant le flux continu, les règles suivantes s'appliquent :
Toutes les règles de la [SOAP Partie 1]
Structure pour liaisons
concernant le flux continu de messages SOAP individuels
DOIVENT être suivies, aussi bien pour les messages SOAP de requête que ceux
de réponses.
Lorsqu'ils utilisent des liaisons SOAP avec flux continu, les
noeuds émettant une requête DOIVENT éviter le verrou mortel en acceptant
et si nécessaire en traitant l'information de réponse SOAP alors que la
requête SOAP est en cours de transmission.
Note:
En fonction de l'implémentation utilisée et de la taille des
messages en cause, cette règle POURRAIT nécessiter que les applications
SOAP transmettent en flux continu le traitement de la réponse au niveau
applicatif en parallèle de la génération de requête.
Un noeud SOAP émettant une requête POURRAIT entrer dans l'état
"Fail" (échec), et ainsi couper la transmission de la requête
SOAP sortante, en fonction de l'information contenu dans une réponse
entrant en flux continu.
6.2.4 Gestion de faute
Pendant le déroulement de la MEP Requête-Réponse, les noeuds SOAP
participants pourraient générer des fautes SOAP.
Si une faute SOAP est générée par le noeud SOAP répondant dans
l'état "Receiving" (réception), la faute SOAP est mise
à disposition dans http://www.w3.org/2003/05/soap/mep/OutboundMessage et la transition
de la machine à états dans l'état "Receiving+Sending"
(réception+envoi).
Cette MEP ne pose pas d'exigence à propos du règlement ou
gestion de fautes SOAP générées par le noeud émettant la requête pendant
tout traitement du message de réponse consécutif à l'état
"Success" dans la table de transition d'état du noeud
demandeur (voir Table 6).
6.3 Séquence d'échange de message SOAP Réponse
Cette section définit la séquence d'échange de message (message exchange pattern, MEP) appelée "Réponse SOAP". La description est une présentation
abstraite du déroulement de cette séquence. Elle ne vise pas à décrire une
implémentation réelle ou suggérer la manière dont une implémentation
réelle devrait être structurée.
6.3.2 Description
La MEP Réponse SOAP définit une séquence pour l'échange d'un
message non-SOAP agissant comme une requête suivi d'un message SOAP
agissant comme une réponse. En l'absence d'erreurs ou de fautes, cette
séquence d'échange de message est constituée de deux messages, dont un
seul est une enveloppe SOAP :
-
Une requête transmise de manière spécifique à la liaison
n'incluant pas d'enveloppe SOAP et par voie de conséquence n'implique pas
de traitement SOAP par le noeud récepteur.
-
Un message de réponse contenant une enveloppe SOAP.
La MEP est terminée par le traitement de l'enveloppe SOAP selon les règles
du modèle de traitement SOAP (voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1], section
Modèle de traitement SOAP).
Un déroulement anormal de la séquence d'échange de message SOAP
de type Réponse peut être causé par l'échec du transfert du message de requête
ou du message de réponse. Ces échecs peuvent être silencieux pour l'un ou les
deux noeuds demandeur et répondant impliqués, ou peut résulter dans la
génération d'une faute SOAP ou spécifique à la liaison (voir
section 6.3.4 Gestion de faute).
De plus, lors d'un déroulement anormal, chaque noeud SOAP impliqué dans
l'échange de message peut avoir sa propre détermination du succès de
l'échange de messages.
La portée de la MEP Réponse SOAP est limitée à
la requête d'un échange d'un message de réponse entre un
noeud SOAP demandeur et un noeud SOAP répondant. Cette séquence
ne requiert pas de corrélation entre requêtes mutiples ni de
synchronisation spécifique pour les requêtes multiples.
Les implémentations POURRAIENT choisir de supporter les requêtes
multiples (et le traitement de réponses associé) survenant en
même temps.
Note:
Cette MEP ne peut pas être utilisée en conjonction avec des
caractéristiques exprimées sous forme de blocs d'en-tête SOAP car il n'y
a pas d'enveloppe SOAP pour les transporter.
6.3.3 Description de la machine à états
La MEP Réponse SOAP définit un ensemble de propriétés décrites
dans Table 8.
Table 8: Définitions de propriétés pour la MEP Réponse SOAP
| Nom de la propriété |
Description de la propriété |
Type de la propriété |
http://www.w3.org/2003/05/soap/mep/OutboundMessage
|
Une structure abstraite représentant le message
sortant courant dans l'échange de message. Elle abstrait à la fois l'infoset enveloppe SOAP (qui POURRAIT être "null") et toute autre structure d'information transférée avecl'enveloppe. |
Non specifié |
http://www.w3.org/2003/05/soap/mep/InboundMessage
|
Une structure abstraite représentant le message
entrant courant dans l'échange de message. Elle abstrait à la fois l'infoset enveloppe SOAP (qui POURRAIT être "null") et toute autre structure d'information transférée avec l'enveloppe. |
Non specifié |
http://www.w3.org/2003/05/soap/mep/ImmediateDestination
|
L'identifiant de la destination immédiate d'un message sortant. |
xs:anyURI |
http://www.w3.org/2003/05/soap/mep/ImmediateSender
|
L'identifiant de l'émetteur immédiat d'un message entrant.
|
xs:anyURI |
Pour démarrer un échange de messages conforme à la MEP Réponse SOAP, le noeud SOAP émettant la requête instancie un contexte d'échange de message local. Table 9 décrit maintenant comment le contexte est
initialisé.
Table 9: Instanciation d'un contexte d'échange de message
pour un noeud SOAP demandeur
| Nom de la propriété |
Valeur de la propriété |
Notes |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName
|
"http://www.w3.org/2003/05/soap/mep/soap-response/"
|
|
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason
|
"None" |
Une URI relative dont l'URI de base est la valeur de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role
|
"RequestingSOAPNode" |
Une URI relative dont l'URI de base est la valeur de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State
|
"Init" |
Une URI relative dont l'URI de base
est la valeur de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role |
http://www.w3.org/2003/05/soap/mep/OutboundMessage
|
Une abstraction du message de requête qui n'inclut
pas d'infoset enveloppe SOAP |
|
http://www.w3.org/2003/05/soap/mep/ImmediateDestination
|
Un identifiant (URI) indiquant le noeud SOAP
répondant |
|
Il peut y avoir d'autres propriétés relatives à l'opération
d'instanciation du contexte d'échange de messages. Elles sont initialisées
selon leur propre spécification de caractéristique.
Une fois que le contexte d'échange de message est initialisé, le
contrôle est passé à une instance locale (conforme) de liaison.
Le diagramme ci-dessous montre les transitions logiques d'état
aux noeuds demandeur et répondant durant la vie de l'échange de messages.
A chaque noeud SOAP, l'instance locale de la liaison met à jour
(logiquement) la valeur de la propriété http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State de manière
à refléter l'état courant de l'échange de message. Les noms d'états sont des
URIs relatives dont l'URI de base est transportée dans la propriété
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role du contexte d'échange de message local.
Figure 3: Diagramme de transition de la MEP Réponse SOAP
Lorsque l'instance locale de liaison du noeud SOAP répondant
commence à recevoir un message de requête entrant, elle instancie
(logiquement) un contexte d'échange de message. Table 10
décrit les propriétés que la liaison initialise lors de l'instanciation
du contexte.
Table 10: Instanciation de contexte d'échange de message pour
un message de requête entrant
| Nom de la propriété |
Valeur de la propriété |
Notes |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName
|
"http://www.w3.org/2003/05/soap/mep/soap-response/"
|
Initialisée dès que possible pendant la durée l'échange de message. |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason
|
"None" |
Une URI relative dont l'URI de base
est la valeur de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role
|
"RespondingSOAPNode" |
Une URI relative dont
l'URI de base est la valeur de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName
Initialisée dès que possible pendant la durée de l'échange de message. |
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State
|
"Init" |
Une URI relative dont l'URI de base
est la valeur de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role |
Lorsque les noeuds SOAP demandeur et répondant passent une
transition d'états, l'instance locale de liaison met à jour (logiquement) un
certain nombre de propriétés.
Table 11 et Table 12 décrivent ces mises à jour, pour les noeuds demandeur et répondant, respectivement.
Table 11: Transitions d'état du noeud SOAP demandeur
| EtatCourant |
Condition de transition |
EtatSuivant |
Action |
| "Init" |
Inconditionnelle |
"Requesting" (demande) |
Lance la requête |
| "Requesting" |
Échec de transmission du message |
"Fail" |
Fixer
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason (RaisonEchec) à
"transmissionFailure" (echecTransmission)
|
| Commence à recevoir le message de réponse |
"Receiving" (réception) |
Fixer
http://www.w3.org/2003/05/soap/mep/ImmediateSender (emetteurImmediat) pour indiquer
l'émetteur du message de réponse (peut être différent des valeurs de
http://www.w3.org/2003/05/soap/mep/ImmediateDestination (destinationImmediate)). Commence
à faire une abstraction du message de réponse, disponible dans
http://www.w3.org/2003/05/soap/mep/InboundMessage . |
| "Receiving" (réception) |
Échec d'échange de message |
"Fail" |
Fixer
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason (RaisonEchec) à
"exchangeFailure" (echecEchange)
|
| Réception du message de réponse terminée. |
"Success" |
|
Table 12: Transitions d'états pour le noeud SOAP répondant
| EtatCourant |
Condition de transition |
EtatSuivant |
Action |
| "Init" |
Commence à recevoir la requête |
"Receiving" (réception) |
Fixer
http://www.w3.org/2003/05/soap/mep/ImmediateSender pour indiquer l'émetteur du message
de requête (si déterminable).
Passer le contrôle du contexte d'échange de message au processeur SOAP. |
| "Receiving" (Réception) |
Échec de la réception du message |
"Fail" |
Fixer
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason (RaisonEchec) à
"receptionFailure" (echecReception). |
Début du message de réponse disponible dans http://www.w3.org/2003/05/soap/mep/OutboundMessage
|
"Sending" (Envoi) |
Lancer la transmission du message de réponse abstrait dans reqres:OutboundMessage . |
| "Sending" (Envoi) |
Échec d'échange de message |
"Fail" |
Fixer http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason
(RaisonEchec) à "exchangeFailure" (echecEchange). |
| Envoi du message de réponse terminé. |
"Success" |
|
6.3.4 Gestion de faute
Pendant l'exécution d'une MEP Réponse SOAP, les noeuds
participants pourraient générer des fautes.
Si une faute SOAP est générée
par le noeud SOAP répondant alors qu'il est dans l'état
"Receiving" (réception), la faute SOAP est placée dans
http://www.w3.org/2003/05/soap/mep/OutboundMessage et la transition de la machine à états
passe à l'état "Sending" (Envoi).
Cette MEP n'impose rien sur le caractère ou la gestion
de fautes SOAP générée par le noeud SOAP demandeur lors de tout traitement
du message de réponse qui suit l'état "Success" dans la
table de transitions du noeud SOAP demandeur (voir Table 11).
6.4 Caractéristique de spécification de méthode Web
Cette section définit la "Caractéristique de spécification de méthode Web".
6.4.1 Nom de caractéristique SOAP
Cette Caractéristique de spécification de méthode Web
est identifiée par l'URI (voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1] Caractéristiques SOAP) :
6.4.2 Description
Les protocoles sous-jacents conçus pour être utilisés sur le World
Wide Web permettent de manipuler des ressources grâce à un petit ensemble
de méthodes Web telles que GET, PUT, POST, and DELETE.
Ces méthodes sont définies formellements dans la spécification de HTTP
[RFC 2616], mais d'autres protocoles sous-jacents pourraient
également les supporter. Les liaisons sur HTTP ou de tels autres protocoles
DEVRAIENT utiliser la Caractéristique de spécification Méthode Web
pour donner aux applications le contrôle sur la méthode Web à utiliser