SOAP Version 1.2 Partie 2 : Ajouts

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]).

Table 1: Préfixes et Espaces de nommage utilisés dans cette spécification.
Préfixe	Espace de nommage	Notes
env	"http://www.w3.org/2003/05/soap-envelope"	Défini par [SOAP Partie 1].
enc	"http://www.w3.org/2003/05/soap-encoding"	Un Schéma XML normatif [XML Schema Partie 1], [XML Schema Partie 2] pour l'espace de nommage "http://www.w3.org/2003/05/soap-encoding" se trouve à http://www.w3.org/2003/05/soap-encoding.
rpc	"http://www.w3.org/2003/05/soap-rpc"	Un Schéma XML normatif [XML Schema Partie 1], [XML Schema Partie 2] pour l'espace de nommage "http://www.w3.org/2003/05/soap-rpc" se trouve à http://www.w3.org/2003/05/soap-rpc.
xs	"http://www.w3.org/2001/XMLSchema"	Défini dans la spécification Schéma XML (XML Schema) du W3C [XML Schema Partie 1], [XML Schema Partie 2].
xsi	"http://www.w3.org/2001/XMLSchema-instance"	Défini dans la spécification Schéma XML (XML Schema) du W3C [XML Schema Partie 1], [XML Schema Partie 2].

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 :
1. Leurs valeurs d'espace de nommage sont absentes.
2. 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 entrants.

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") :
- L'item d'information élément représentant un noeud tableau POURRAIT avoir parmi ses attributs un item d'information attribut itemType (voir 3.1.4.1 Item d'Information Attribut itemType).
- L'item d'information élément représentant un noeud tableau POURRAIT avoir parmi ses attributs un item d'information attribut arraySize (voir 3.1.6 Item d'Information Attribut arraySize).
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 [local name] id .
Un [namespace name] vide.
Une propriété [specified] ayant pour valeur "true".

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 [local name] ref .
Un [namespace name] vide.
Une propriété [specified] ayant pour valeur "true".

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 [local name] arraySize .
Le [namespace name] "http://www.w3.org/2003/05/soap-encoding".

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 :

DEVRAIT générer une faute SOAP "env:Sender" avec un sous-code enc:MissingID si le message contient un item d'information attribut ref mais pas d'item d'information attribut id correspondant (voir 3.1.5.3 Contraintes sur les items d'information attributs id et ref ).
DEVRAIT générer une faute SOAP "env:Sender" avec un sous-code enc:DuplicateID si le message contient deux items d'information attributs id ou plus ayant la même valeur. (voir 3.1.5.3 Contraintes sur les items d'information attributs id et ref ).
POURRAIT générer une faute SOAP "env:Sender" avec un sous-code enc:UntypedValue si la propriété nom du type d'un noeud d'un graphe est non spécifiée.

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 :

Les conventions décrites dans 4.1.1 Identification of RPC Resources sont utilisées pour identifier la ressource par une URI.
Dans les cas où tous les arguments ont été représentés dans l'URI, il n'est pas nécessaire de transmettre des blocs d'en-tête SOAP et l'opération est une récupération d'information sûre, 6.4 Caractéristique de spécification de méthode Web et 6.3 Séquence d'échange de message SOAP Réponse sont utilisées. En conséquence, aucune enveloppe SOAP n'est transmise pour la requête et la propriété http://www.w3.org/2003/05/soap/features/web-method/Method est mise à "GET". Les résultats de la récupération sont une réponse RPC SOAP telle que décrite dans 4.2.2 Réponse RPC
Dans les cas où l'opération à effectuer n'est pas une récupération, lorsque des blocs d'en-tête SOAP sont à transmettre (une signature numérique, par exemple), ou lorsqu'une récupération n'est pas sûre, 6.4 Caractéristique de spécification de méthode Web et 6.2 Séquence d'échange de messages SOAP de type Requête-Réponse sont utilisées. L'enveloppe de la requête est encodée comme décrit dans 4.2.1 Invocation RPC, et les résultats sont tels que décrits dans 4.2.2 Réponse RPC. La propriété http://www.w3.org/2003/05/soap/features/web-method/Method est mise à "POST".

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 :

L'invocation est représentée par un simple "struct" contenant un arc sortant pour chaque paramètre en [entrée] ou [entrée/sortie]. Le "struct" a le même nom que la procédure ou méthode et 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 méthodes qui ne sont pas légaux en XML.
Chaque arc sortant possède 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.

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 :
1. 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.
2. 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.

Model describing properties shared between SOAP and Binding

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.1 Nom de caractéristique SOAP

Cette séquence d'échange de messages est identifié par l'URI (voir SOAP 1.2 partie 1 [SOAP Partie 1] Caractéristiques SOAP) :

"http://www.w3.org/2003/05/soap/mep/request-response/"

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.

Request-Response MEP State Transition Diagram.

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)
"Requesting"	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)
"Sending+Receiving"	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).
"Receiving"	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).
"Receiving+Sending"	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.1 Nom de caractéristique SOAP

Cette séquence d'échange de message est identifiée par l'URI (voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1] Caractéristiques SOAP) :

"http://www.w3.org/2003/05/soap/mep/soap-response/"

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.

SOAP Response MEP State Transition Diagram.

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)
"Requesting"	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)
"Receiving" (réception)	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).
"Receiving" (Réception)	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).
"Sending" (Envoi)	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) :

"http://www.w3.org/2003/05/soap/features/web-method/"

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 pour envoyer un message SOAP.

Les liaisons supportant cette caractéristique DEVRAIENT utiliser l'incarnation appropriée de cette méthode si elle est fournie par le protocole sous-jacent ; par exemple, la liaison HTTP fournie avec cette spécification représente la méthode Web "GET" comme une requête HTTP GET et la méthode Web "POST" comme une requête HTTP POST (voir 7. Liaison SOAP sur HTTP). Les liaisons supportant cette caractéristique DEVRAIENT fournir au noeud récepteur une indication de la méthode Web utilisée pour la transmission.

La caractéristique de spécification Méthode Web de SOAP POURRAIT être implémentée par des liaisons sur des transports sous-jacents n'ayant pas d'incarnation privilégiée de méthodes Web particulières (par ex. ne distinguant pas GET de POST). De telles liaisons DEVRAIENT fournir au noeud récepteur une indication de la méthode Web utilisée pour la transmission, mais n'ont pas d'autre chose à faire pour supporter la caractéristique.

6.4.3 Machine à États de la caractéristique Méthode Web

La caractéristique Méthode Web définit une seule propriété, décrite dans Table 13.

Table 13: Définition de propriété pour la caractéristique Méthode Web
Nom de la propriété	Description de la propriété	Type de la propriété
`http://www.w3.org/2003/05/soap/features/web-method/Method`	Une méthode parmi "GET", "POST", "PUT", "DELETE" (ou d'autres qui pourraient ainsi s'ajouter à la liste de méthodes Web).	Non spécifié

Cette spécification prévoit l'utilisation de la caractéristique Méthode Web en conjonction avec les séquences d'échange de messages (MEP) 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. Cette caractéristique POURRAIT être utilisée avec d'autres MEPs si et seulement si elle est prévue dans la spécification de ces MEPs.

Un noeud émettant un message de requête DOIT fournir une valeur de la propriété http://www.w3.org/2003/05/soap/features/web-method/Method . Une liaison sur un protocole supportant cette caractéristique DEVRAIT fixer la valeur de la propriété http://www.w3.org/2003/05/soap/features/web-method/Method au noeud récepteur correspondant à celle donnée par l'émetteur ; la manière de transmettre la propriété méthode est spécifique à la liaison.

Un noeud répondant DEVRAIT répondre de manière cohérente avec la méthode Web demandée (par ex. un "GET" pourrait conduire à récupérer une représentation de la ressource identifiée) ou POURRAIT provoquer une faute selon une manière spécifique à l'application si la méthode Web ne peut être supportée.

Les liaisons implémentant cette caractéristique DOIVENT employer une séquence d'échange de message (MEP) dont la sémantique est compatible avec la méthode Web choisie. Par exemple, la séquence d'échange de message Réponse SOAP (voir 6.3 Séquence d'échange de message SOAP Réponse) est compatible avec GET.

6.5 Caractéristique Action SOAP

Cette section définit la "Caractéristique Action SOAP".

6.5.1 Nom de caractéristique SOAP

La caractéristique Action SOAP est identifiée par l'URI (voir SOAP 1.2 Partie 1 [SOAP Partie 1] Caractéristiques SOAP):

"http://www.w3.org/2003/05/soap/features/action/"

6.5.2 Description

De nombreux protocoles sous-jacents à SOAP 1.2 seront susceptibles d'utiliser le type de media "application/soap+xml" (décrit dans A. Le type de media application/soap+xml) pour transmettre des sérialisations de messages SOAP. Le type de media spécifie un paramètre optionnel action (voir A.3 Le paramètre action), qui peut être utilisé entre autres pour optimiser la répartition ou le routage. La caractéristique Action spécifie les URIs répandues pour indiquer le support du paramètre action dans les liaisons utilisant MIME et également pour se référer à la valeur du paramètre lui-même.

6.5.3 Machine à États de la caractéristique Action SOAP

La caractéristique Action SOAP définit une seule propriété, décrite dans Table 14.

Table 14: Définition de propriété pour la caractéristique SOAP
Nom de la propriété	Type de la propriété
`http://www.w3.org/2003/05/soap/features/action/Action`	`xsd:anyURI`

Si la propriété http://www.w3.org/2003/05/soap/features/action/Action possède une valeur au niveau d'un émetteur SOAP utilisant une liaison qui supporte cette caractéristique, l'émetteur DOIT utiliser la valeur de la propriété commen valeur du paramètre action dans le descripteur du type de media.

Réciproquement, si une valeur arrive dans le paramètre action du descripteur de type de media au niveau d'un récepteur SOAP, ce récepteur DOIT la placer comme valeur de la propriété http://www.w3.org/2003/05/soap/features/action/Action .

7. Liaison SOAP sur HTTP

7.1 Introduction

La liaison SOAP HTTP fournit une liaison de SOAP sur le protocole HTTP. Cette liaison est conforme à la structure pour liaisons SOAP sur un protocole (voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1] Structure pour liaison SOAP sur protocole) et supporte les séquences d'échange de messages et les caractéristiques décrite dans 6. Séquences d'échange de messages et Caractéristiques fournies dans SOAP.

7.1.1 Caractère optionnel

La liaison de SOAP sur HTTP est optionnelle et les noeuds SOAP NE sont PAS obligés de l'implémenter. Un noeud SOAP qui implémente correctement et complètement la liaison SOAP HTTP peut être dit "conforme à la liaison SOAP 1.2 sur HTTP".

La spécification de SOAP version 1.2 n'exclut pas le développement d'autres liaisons sur HTTP ou sur d'autres protocoles, mais la communication entre noeuds par ces autres liaisons n'est pas un but. Notez que d'autres liaisons de SOAP sur HTTP POURRAIENT être écrite pour supporter d'autres séquences d'échange de messages que 6.2 Séquence d'échange de messages SOAP de type Requête-Réponse ou 6.3 Séquence d'échange de message SOAP Réponse. Ces liaisons alternatives POURRAIENT par conséquent utiliser des caractéristiques et des codes d'état de HTTP non imposés dans la présente liaison. Par exemple, une autre liaison pourrait fournir un état de réponse HTTP 202 ou 204 pour renvoyer en réponse à une HTTP POST ou PUT (par ex. une MEP à sens unique "poussé" avec confirmation).

7.1.2 Utilisation de HTTP

La liaison SOAP HTTP définit une URI de base selon les règles de HTTP/1.1[RFC 2616]. Cad l'URI de base est la Request-URI HTTP ou la valeur du champ d'en-tête HTTP Content-Location.

La liaison de SOAP sur HTTP vise à utiliser convenablement HTTP comme protocole d'application. Par exemple, les réponses avec succès sont envoyées avec le code d'état 200 et les échecs sont indiqués par 4XX ou 5XX. Cette liaison ne cherche pas à exploiter toutes les caractéristiques de HTTP mais plutôt à utiliser HTTP spécifiquement pour les besoins de communication avec d'autres noeuds SOAP implémentant la même liaison. Par conséquent, cette liaison HTTP pour SOAP ne spécifie pas l'utilisation et/ou la signification de toutes les méthodes HTTP, champs d'en-tête et états de réponse possibles. Elle spécifie seulement ceux qui sont pertinents dans 6.2 Séquence d'échange de messages SOAP de type Requête-Réponse ou 6.3 Séquence d'échange de message SOAP Réponse, ou qui sont susceptibles d'être introduits par des mécanismes HTTP (comme les proxy) agissant entre les noeuds.

Certaines caractéristiques optionnelles fournies par cette liaison dépendent des capacités de HTTP/1.1, par exemple la négociation de contenu. Les implémentations DEVRAIENT donc utiliser HTTP/1.1 [RFC 2616] (ou versions supérieures compatibles ayant le même numéro majeur de version). Les implémentations POURRAIENT également être déployées avec HTTP/1.0, bien que dans ce cas certaines caractéristiques optionnelles de la liaison pourraient ne pas être fournies.

Note:

Les implémentations de la liaison SOAP HTTP doivent prendre en considération le fait que des intermédiaires HTTP/1.0 (pouvant être aussi ou ne pas être des intermédiaires SOAP) pourraient modifier la représentation des messages SOAP, même dans des situations où aussi bien l'émetteur SOAP initial que le récepteur SOAP final utilisent HTTP/1.1

7.1.3 Interopérabilité avec des implémentations HTTP non-SOAP

Particulièrement avec l'utilisation de la 6.3 Séquence d'échange de message SOAP Réponse, les messages HTTP produits par cette liaison sont susceptibles d'être indistinguibles de ceux produits par des implémentations non SOAP exécutant des opérations semblables. En conséquence, un certain degré d'interopération peut être rendu possible entre noeuds SOAP et autres implémentations HTTP, lorsque l'on utilise cette liaison. Par exemple, un serveur Web conventionnel (cad non développé spécialement pour se conformer à cette spécification) peut être utilisé pour répondre à un HTTP GET initié via SOAP avec des représentations de Content-Type "application/soap+xml". Une telle interopération n'est pas une caractéristique normative de cette spécification.

Même si HTTP est souvent utilisé sur le port TCP 80, l'utilisation de HTTP n'est pas limitée à ce port. Par conséquent, il est possible d'avoir un serveur HTTP dédié à la gestion du traitement SOAP sur un port TCP différent. Il est également possible d'utiliser un hôte virtuel séparé pour s'occuper du traitement SOAP. Toutefois, le choix de configuration est un problème pratique et n'est pas une clause de cette spécification (voir dans la partie 1 de SOAP 1.2 [SOAP Partie 1] Liaison sur protocoles applicatifs spécifiques).

7.1.4 Type de media HTTP (HTTP Media-Type)

Les implémentations conformes de cette liaison :

DOIVENT être capable d'envoyer et recevoir des messages sérialisés utilisant le type de media "application/soap+xml" dont l'utilisation adéquate et les paramètres sont décrits dans A. Le type de media application/soap+xml.
POURRAIENT envoyer des requêtes et réponses utilisant d'autres types de media pour autant que ces types de media prévoient au moins le transfert d'Infoset XML SOAP.
POURRAIENT, lors de l'envoi de requêtes, fournir un champ d'en-tête HTTP Accept. Ce champ d'en-tête :
- DEVRAIT indiquer la capacité d'accepter au moins "application/soap+xml".
- POURRAIT en plus indiquer la volonté d'accepter d'autres types de media qui satisfassent le point 2 ci-dessus.

7.2 Nom de liaison

La liaison est identifiée par l'URI (voir dans la partie 1 de SOAP 1.2 Structure pour une liaison SOAP sur un protocole ) :

"http://www.w3.org/2003/05/soap/bindings/HTTP/"

7.3 Séquences d'échange de messages supportées

Une implémentation de la liaison SOAP HTTP DOIT supporter les séquences d'échange de messages (MEPs) suivantes :

"http://www.w3.org/2003/05/soap/mep/request-response/" (voir 6.2 Séquence d'échange de messages SOAP de type Requête-Réponse)
"http://www.w3.org/2003/05/soap/mep/soap-response/" (voir 6.3 Séquence d'échange de message SOAP Réponse)

7.4 Caractéristiques supportées

Une implémentation de la liaison SOAP HTTP DOIT supporter les caractéristiques suivantes :

"http://www.w3.org/2003/05/soap/features/web-method/" (voir 6.4 Caractéristique de spécification de méthode Web )
"http://www.w3.org/2003/05/soap/features/action/" (voir 6.5 Caractéristique Action SOAP)

Les valeurs possibles de la propriété http://www.w3.org/2003/05/soap/features/web-method/Method sont restreintes dans cette liaison HTTP selon la MEP en utilisation (indiquée dans http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName ) :

Table 15: Valeurs possibles de la propriété Web-Method
`http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName`	`http://www.w3.org/2003/05/soap/features/web-method/Method`
"http://www.w3.org/2003/05/soap/mep/request-response/"	"POST"
"http://www.w3.org/2003/05/soap/mep/soap-response/"	"GET"

Note:

D'autres liaisons de SOAP 1.2 sur HTTP pourraient permettre d'autres combinaisons de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName et de http://www.w3.org/2003/05/soap/features/web-method/Method .

7.5 Exécution de MEP

Pour des instances de liaison conformes à cette spécification :

Un noeud SOAP instancié sur un client HTTP peut assumer le rôle (c-a-d la propriété http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role ) de "RequestingSOAPNode".
Un noeud SOAP instancié sur un serveur HTTP peut assumer le rôle (c-a-d la propriété http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role ) de "RespondingSOAPNode".

Le reste de cette section décrit la machine à états de la MEP et sa relation avec le protocole HTTP. Dans le tableau d'état ci-dessous, les états sont définis comme valeurs de la propriété http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State (voir 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), et sont du type xs:anyURI . Pour abréger, des URIs relatives sont utilisées, l'URI de base étant la valeur de http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role .

La séquence d'échange de messages en cours d'utilisation est indiquée par la méthode HTTP utilisée dans la requête. HTTP GET correspond à la MEP Réponse SOAP, HTTP POST correspond à la MEP Requête-Réponse SOAP.

7.5.1 Comportement du noeud SOAP demandeur

Le flux du comportement d'ensemble d'un noeud SOAP demandeur suit une description de machine à états cohérente avec soit 6.2 Séquence d'échange de messages SOAP de type Requête-Réponse, soit 6.3 Séquence d'échange de message SOAP Réponse (des différences sont indiquées si nécessaire). Cette liaison supporte la diffusion en flux continu, par conséquent les noeuds SOAP demandeurs DOIVENT éviter le verrou mortel en acceptant et en traitant si nécessaire des informations de réponse SOAP alors que la requête est en cours de transmission (voir 6.2.3 Description de la Machine à États). Les sous-sections suivantes décrivent chaque état en détails.

7.5.1.1 Init

Dans l'état "Init", une requête HTTP est formulée selon Table 16 et la transmission de la requête est commencée.

Table 16: Champs de la requête HTTP
Champ	Valeur
Méthode HTTP	En fonction de la propriété `http://www.w3.org/2003/05/soap/features/web-method/Method` (typiquement POST ou GET).
Request-URI	La valeur de l'URI transportée dans la propriété `http://www.w3.org/2003/05/soap/mep/ImmediateDestination` du contexte d'échange de messages.
Champ d'en-tête Content-Type (type de contenu)	Le type de media (media type) de l'entité corps de la requête (s'il est présent), sinon omis (voir 7.1 Introduction pour une description des types de media permis). Si l'infoset enveloppe SOAP dans la propriété `http://www.w3.org/2003/05/soap/mep/OutboundMessage` est "null", alors le champ d'en-tête `Content-Type` POURRAIT être omis.
Paramètre Action	En fonction de la propriété `http://www.w3.org/2003/05/soap/features/action/Action` .
Champ d'en-tête Accept (optionnel)	Liste de types de media acceptables en réponse au message de requête.
Champs d'en-tête supplémentaires	Générés en accord avec les règles pour l'expression spécifique à la liaison de toute caractéristique optionnelle utilisée pour cet échange demessages. Par exemple, un champ d'en-tête Content-Encoding (voir [RFC 2616], section 14.11) pourrait être utilisé pour exprimée une caractéristique optionnelle de compression.
Entité corps HTTP	Message SOAP sérialisé selon les règles pour transporter des messages SOAP dans le type de media donné par le champ d'en-tête Content-Type. Les règles pour transporter des messages SOAP dans le type de media "application/soap+xml" sont données dans A. Le type de media application/soap+xml. Si l'infoset enveloppe SOAP dans la propriété `http://www.w3.org/2003/05/soap/mep/OutboundMessage` est "null", alors l'entité corps est omise.

7.5.1.2 Requesting

Dans l'état "Requesting", l'envoi de la requête continue pendant l'attente du début du message de réponse. Table 17 détaille les transitions qui ont lieu lorsqu'un noeud SOAP demandeur reçoit une ligne d'état HTTP et des champs d'en-tête de réponse. Pour certains codes d'état, il existe un choix d'états suivants possibles. Dans les cas où "Fail" (Echec) est l'un de ces choix, la transition dépend de la présence d'un message SOAP dans la réponse. S'il y a un message SOAP dans la réponse HTTP, l'état suivant est "Sending+Receiving" (Envoi+Réception) ou "Receiving" (Réception), sinon l'état suivant est "Fail" (Echec). Le choix entre "Sending+Receiving" et "Receiving" dépend de la MEP utilisée : "Sending+Receiving" est l'état suivant pour la Requête-Réponse alors que "Receiving" est l'état suivant pour la Réponse SOAP.

Table 17: Transitions dépendant du code d'état HTTP
Code d'état	Phrase de raison	Signification/Action	Etat suivant
2xx	Successful
200	OK	Le message de réponse suit dans l'entité corps de la réponse HTTP. Commencer à construire une abstraction de message de réponse disponible dans `http://www.w3.org/2003/05/soap/mep/InboundMessage` .	"Sending+Receiving" (Envoi+Réception) ou "Receiving" (Réception)
3xx	Redirection	La ressource demandée a été déplacée et la requête HTTP DEVRAIT être retentée en utilisant l'URI véhiculée dans le champ d'en-tête associé Location comme nouvelle valeur de la propriété `http://www.w3.org/2003/05/soap/mep/ImmediateDestination` .	"Init"
4xx	Client Error
400	Bad Request	Indique un problème avec le message de requête HTTP reçu.	"Sending+Receiving" (Envoi+Réception), "Receiving" (Réception) ou "Fail" (Echec)
401	Unauthorized	Indique que la requête HTTP requiert une autorisation. Si la caractéristique de simple authentification n'est pas disponible ou que son exécution échoue finalement, alors l'échange de message est considéré comme terminé sans succès.	"Requesting" (Requête) ou "Fail" (Echec)
405	Method not allowed	Indique que le serveur HTTP pair ne supporte pas la méthode HTTP demandée pour l'URI de requête donnée. L'échange de message est considéré comme terminé sans succès.	"Fail" (Echec)
415	Unsupported Media Type	Indique que le serveur HTTP pair ne supporte pas le type de contenu (Content-type) utilisé pour encoder le message de requête. L'échange de message est considéré comme terminé sans succès.	"Fail" (Echec)
5xx	Server Error
500	Internal Server Error	Indique un problème du serveur ou un problème avec la requête reçue	"Sending+Receiving" (Envoi+Réception) , "Receiving" (Réception) ou "Fail" (Echec)

Table 17 se réfère à certains mais pas tous les codes d'état existant dans HTTP/1.1 [RFC 2616]. En plus de ces codes d'état, HTTP fournit un mécanisme ouvert pour supporter des codes définis dans des extensions de HTTP (voir [RFC 2817] pour le mécanisme d'enreigstrement de nouveaux codes d'état). Les codes d'état HTTP sont divisés en classes de codes, comme décrit dans HTTP [RFC 2616], section 6.1.1. La liaison SOAP HTTP suit les règles de toute application HTTP ce qui signifie qu'une implémentation de la liaison SOAP HTTP doit comprendre la classe de tout code d'état, indiquée par le premier chiffre, et traiter toute réponse non reconnue comme équivalente au code x00 de cette classe, avec l'exception qu'une réponse non reconnue ne doit pas être mise en cache.

Note:

Il peut y avoir des éléments dans l'infrastructure HTTP configurés de manière à modifier les entités corps de réponses HTTP pour les réponses de code d'état 4xx et 5xx. Par exemple, certains serveurs HTTP ont cette fonctionnalité comme option de configuration. Ce comportement pourrait interférer avec l'utilisation de réponses de code d'état 4xx et 5xx transportant des messages de faute SOAP sur HTTP et il est recommandé de désactiver ce comportement pour les ressources acceptant des requêtes SOAP/HTTP. Si le comportement de réécriture ne peut être désactivé, SOAP/HTTP ne peut pas être utilisé dans cette configuration.

7.5.1.3 Envoi+Réception (Sending+Receiving)

Dans l'état "Sending+Receiving" (6.2 Séquence d'échange de messages SOAP de type Requête-Réponse seulement), la transmission du message de requête et la réception du message de réponse sont terminés. Le message de réponse est supposé contenir une enveloppe SOAP sérialisée selon les règles de transport de messages SOAP dans le type de media donné par le champ d'en-tête Content-Type.

La réponse POURRAIT être d'un type de contenu autre que "application/soap+xml". Une telle utilisation est considérée non normative et en conséquence n'est pas modélisée dans la machine à états. L'interprétation de ces réponses est à la discrétion du récepteur.

7.5.1.4 Réception (Receiving)

Dans l'état "Receiving" (6.3 Séquence d'échange de message SOAP Réponse seulement), la réception du message de réponse est terminée. Le message de réponse est supposé contenir une enveloppe SOAP sérialisée selon les règles de transport de messages SOAP dans le type de media donné par le champ d'en-tête Content-Type.

La réponse POURRAIT être d'un type de contenu autre que "application/soap+xml". Ce résultat est particulièrement susceptible de se produire lorsqu'une requête SOAP envoyée avec une http://www.w3.org/2003/05/soap/features/web-method/Method "GET" est adressée (intentionnellement ou non) à un serveur HTTP non-SOAP. Une telle utilisation est considérée non normative et en conséquence n'est pas modélisée dans la machine à états. L'interprétation de ces réponses est à la discrétion du récepteur.

7.5.1.5 Succès (Success) et Echec (Fail)

"Success" (succès) et "Fail" (échec) sont les états terminaux des MEPs Requête-Réponse et Réponse-SOAP. Le contrôle du contexte d'échange de messages revient au noeud SOAP local.

7.5.2 Comportement du noeud SOAP répondant

Le flux du comportement d'ensemble d'un noeud SOAP répondant suit une machine à états cohérente avec soit 6.2 Séquence d'échange de messages SOAP de type Requête-Réponse ou 6.3 Séquence d'échange de message SOAP Réponse (les différences sont indiquées si nécessaire). Les sous-sections suivantes décrivent chaque état en détails.

7.5.2.1 Init

Dans l'état "Init", la liaison attend le début d'un message de requête entrant. Table 18 décrit les erreurs qu'un noeud SOAP répondant pourrait générer dans l'état "Init". Dans cet état aucun message SOAP n'a été reçu, donc le noeud SOAP ne peut pas générer de faute SOAP.

Table 18: Erreurs générées dans l'état Init
Problème avec le message	Code d'état HTTP	Phrase de raison HTTP (informative)
Message de requête malformé	400	Bad request
La méthode HTTP n'est ni POST ni GET	405	Method Not Allowed
Méthode d'encapsulation de message non supportée	415	Unsupported Media

7.5.2.2 Réception (Receiving)

Dans l'état "Receiving" (Réception), la liaison reçoit la requête et tout message associé, et attend que le début d'un message de réponse soit disponible. Table 19 décrit les champs d'en-tête de la réponse HTTP générés par le noeud SOAP répondant. Table 20 décrit les codes d'état HTTP associés aux fautes SOAP pouvant être générées par le noeud SOAP répondant.

Table 19: Champ d'en-tête de la réponse HTTP
Champ	Valeur
Ligne d'état	200, ou fixé selon Table 20 si une faute SOAP a été générée.
Champ d'en-tête "Content-Type"	Le type de media du corps de la réponse, voir 7.1 Introduction pour une description des types de media possibles.
Champs d'en-tête supplémentaires	Généré selon les règles pour l'expression spécifique à la liaison de toute caractéristique optionnelle utilisée pour cet échange de messages. Par exemple, un champ d'en-tête "Content-Encoding" (voir HTTP [RFC 2616], section 14.11) pourrait être utilisé pour exprimer une caractéristique optionnelle de compression.
Entité corps HTTP	Message SOAP sérialisé selon les règles pour transporter des messages SOAP dans le type de media donné par le champ d'en-tête Content-Type. Les règles pour transporter des messages SOAP dans le type de media "application/soap+xml" sont données dans A. Le type de media application/soap+xml.

Table 20: Correspondance entre faute SOAP et état HTTP
Faute SOAP	Code d'état HTTP	Phrase de raison HTTP (informative)
env:VersionMismatch	500	Internal server error
env:MustUnderstand	500	Internal server error
env:Sender	400	Bad request
env:Receiver	500	Internal server error
env:DataEncodingUnknown	500	Internal server error

7.5.2.3 Réception+Envoi (Receiving+Sending)

Dans l'état "Receiving+Sending" (6.2 Séquence d'échange de messages SOAP de type Requête-Réponse seulement) la liaison termine la réception du message de requête et la transmission du message de réponse.

7.5.2.4 Envoi (Sending)

Dans l'état "Sending" (6.3 Séquence d'échange de message SOAP Réponse seulement) la liaison termine la transmission du message de réponse.

7.5.2.5 Succès (Success) et Echec (Fail)

"Success" (succès) et "Fail" (échec) sont les états terminaux pour les MEPs Requête-Réponse et Réponse-SOAP. Du point de vue du noeud local cet échange de messages est terminé.

7.6 Considérations de sécurité

La liaison SOAP HTTP (voir 7. Liaison SOAP sur HTTP) peut être considérée comme une extension du protocole applicatif HTTP. De cette manière, toutes les considérations de sécurité identifiées et décrites dans la section 15 de la spécification HTTP [RFC 2616] s'appliquent à la liaison SOAP HTTP en plus de celles décrites dans dans la partie 1 de SOAP 1.2 [SOAP Partie 1] Considérations de sécurité. Les implémenteurs de la liaison SOAP HTTP devraient examiner attentivement ces informations.

8. Références

8.1 Références normatives

[SOAP Partie 1]: W3C Proposed Recommendation "SOAP Version 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (Voir http://www.w3.org/TR/2003/REC-soap12-part1-20030624).
[RFC 2616]: IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, January 1997. (Voir http://www.ietf.org/rfc/rfc2616.txt).
[RFC 2119]: IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (Voir http://www.ietf.org/rfc/rfc2119.txt).
[XML Schema Partie 1]: W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (Voir http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/).
[XML Schema Partie 2]: W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (Voir http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/).
[RFC 2396]: IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (Voir http://www.ietf.org/rfc/rfc2396.txt).
[Namespaces in XML]: W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (Voir http://www.w3.org/TR/1999/REC-xml-names-19990114/).
[XML 1.0]: W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (Voir http://www.w3.org/TR/2000/REC-xml-20001006).
[XML InfoSet]: W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (Voir http://www.w3.org/TR/2001/REC-xml-infoset-20011024/).
[RFC 3023]: IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, July 1998. (Voir http://www.ietf.org/rfc/rfc3023.txt).

8.2 Références informatives

[SOAP Partie 0]: W3C Proposed Recommendation "SOAP Version 1.2 Part 0: Primer", Nilo Mitra, 24 June 2003 (Voir http://www.w3.org/TR/2003/REC-soap12-part0-20030624).
[SOAP MediaType]: IETF Internet Draft "The 'application/soap+xml' media type", M. Baker, M. Nottingham, "draft-baker-soap-media-reg-03.txt" May 29, 2003. Notez que ce brouillon expire en novembre 2003. (Voir http://www.ietf.org/internet-drafts//draft-baker-soap-media-reg-03.txt).
[XMLP Comments]: XML Protocol Comments Archive (Voir http://lists.w3.org/Archives/Public/xmlp-comments/).
[XMLP Dist-App]: XML Protocol Discussion Archive (Voir http://lists.w3.org/Archives/Public/xml-dist-app/).
[XMLP Charter]: XML Protocol Charter (Voir http://www.w3.org/2000/09/XML-Protocol-Charter).
[RFC 2045]: IETF "RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed, N. Borenstein, November 1996. (Voir http://www.ietf.org/rfc/rfc2045.txt).
[RFC 2026]: IETF "RFC 2026: The Internet Standards Process -- Revision 3", section 4.2.3, S. Bradner, October 1996. (Voir http://www.ietf.org/rfc/rfc2026.txt).
[RFC 2817]: IETF "RFC 2817: Upgrading to TLS Within HTTP/1.1", R. Khare, S. Lawrence, May 2000. (Voir http://www.ietf.org/rfc/rfc2817.txt).
[CharMod]: W3C Working Draft "Character Model for the World Wide Web 1.0", Martin J. Durst, Francois Yergeau, Richard Ishida, Misha Wolf, Asmus Freytag, Tex Texin, 30 April 2002. (Voir http://www.w3.org/TR/charmod/).

SOAP Version 1.2 Partie 2 : Ajouts

Recommandation W3C 24 June 2003

Résumé

Statut de ce document

Table des matières abrégée

Table des matières

Annexes

1. Introduction

1.1 Conventions de notation

2. Modèle de Données SOAP

2.1 Arcs d'un graphe

2.1.1 Étiquettes d'arcs

2.2 Noeuds d'un graphe

2.2.1 Noeuds référence simple et multiple

2.3 Valeurs

3. Encodage SOAP

3.1 Correspondance entre XML et le modèle de données SOAP

3.1.1 Encodage d'arcs et de noeuds de graphe

3.1.2 Encodage de valeurs simples

3.1.3 Encodage de valeurs composées

3.1.4 Calcul de la propriété nom du type (Type Name)

3.1.4.1 Item d'Information Attribut itemType

3.1.5 Identifiants uniques

3.1.5.1 Item d'Information Attribut id

3.1.5.2 Item d'Information Attribut ref

3.1.5.3 Contraintes sur les items d'information attributs id et ref

3.1.6 Item d'Information Attribut arraySize

3.1.7 Item d'information attribut NodeType

3.2 Décodage de fautes

4. Représentation SOAP RPC

4.1 Utilisation de RPC sur le World Wide Web

4.1.1 Identification of RPC Resources

4.1.2 Distinction entre récupération de ressource et autres RPCs

4.2 RPC and SOAP Body

4.2.1 Invocation RPC

4.2.2 Réponse RPC

4.2.3 Restriction de l'encodage SOAP

4.3 RPC et en-tête SOAP

4.4 Fautes RPC

5. Une convention de description de caractéristiques et liaisons

5.1 Modèle et prorpiétés

5.1.1 Propriétés

5.1.2 Portée de propriété

5.1.2.1 Contexte d'échange de messages

5.1.2.2 Contexte d'environnement

5.1.3 Propriétés et caractéristiques

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

6.2 Séquence d'échange de messages SOAP de type Requête-Réponse

6.2.1 Nom de caractéristique SOAP

6.2.2 Description

6.2.3 Description de la Machine à États

6.2.4 Gestion de faute

6.3 Séquence d'échange de message SOAP Réponse

6.3.1 Nom de caractéristique SOAP

6.3.2 Description

6.3.3 Description de la machine à états

6.3.4 Gestion de faute

6.4 Caractéristique de spécification de méthode Web

6.4.1 Nom de caractéristique SOAP

6.4.2 Description

6.4.3 Machine à États de la caractéristique Méthode Web

6.5 Caractéristique Action SOAP

6.5.1 Nom de caractéristique SOAP

6.5.2 Description

6.5.3 Machine à États de la caractéristique Action SOAP

7. Liaison SOAP sur HTTP

7.1 Introduction

7.1.1 Caractère optionnel

7.1.2 Utilisation de HTTP

7.1.3 Interopérabilité avec des implémentations HTTP non-SOAP

7.1.4 Type de media HTTP (HTTP Media-Type)

7.2 Nom de liaison

7.3 Séquences d'échange de messages supportées

7.4 Caractéristiques supportées

7.5 Exécution de MEP

7.5.1 Comportement du noeud SOAP demandeur

7.5.1.1 Init

7.5.1.2 Requesting

7.5.1.3 Envoi+Réception (Sending+Receiving)

A.3 Le paramètre `action`