SOAP Version 1.2 Partie 2 : Ajouts (original) (raw)

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 :

1. 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).
2. 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).
3. 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).
4. 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).
5. 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).
6. 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 ).
7. 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.

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 :

1. Leurs valeurs de nom local sont identiques.
2. 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 :

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

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

1. 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.
2. 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.
3. 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).
4. 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).
5. 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 :

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

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) :

1. 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 ).
2. 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.
3. 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 ).
4. 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é.
5. D'autres fautes se produisant dans une extension ou depuis l'application DEVRAIENT être générée comme décrit dans la partie 1 de SOAP 1.2[SOAP Partie 1] Codes de faute SOAP.

Dans tous les cas, les valeurs des items d'information éléments Detail (détail) et Reason (raison) sont définis par l'implémentation. Les détails de leur utilisation POURRAIENT être spécifiés par un document externe.

Note:

Les émetteurs peuvent recevoir différentes fautes parmi celles listées ci-dessus en réponse à une invocation RPC si le récepteur ne supporte pas la convention RPC (optionnelle) décrite ici.

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

Cette section décrit une convention de description de caractéristiques (MEPs inclus) et de liaisons, en termes de propriétés et valeurs de propriétés. La convention est suffisant pour décrire les états distribués de spécifications de caractéristiques et de liaisons, comme demandé par la structure pour les liaisons (voir dans la partie 1 de SOAP 1.2[SOAP Partie 1] Structure pour liaison SOAP sur un protocole). Elle est utilisée pour décrire une séquence d'échange de messages (MEP) Requête-Réponse (voir 6.2 Séquence d'échange de messages SOAP de type Requête-Réponse), une MEP Réponse (voir 6.3 Séquence d'échange de message SOAP Réponse), la caractéristiques Méthode Web (Web Method) (voir 6.4 Caractéristique de spécification de méthode Web ) et la liaison de SOAP sur HTTP (voir 7. Liaison SOAP sur HTTP) dans le reste de ce document. En même temps que cette convention elle-même, un modèle informel est défini pour décrire comment les propriétés se propagent dans un système SOAP. Notez que ce modèle se veut seulement illustratif et n'est pas censé impliquer une quelconque contrainte sur la structure ou l'organisation en couches d'une implémentation SOAP.

5.1 Modèle et prorpiétés

En général, un message SOAP est l'information qu'un noeud SOAP souhaite échanger avec un autre noeud SOAP en respectant un ensemble particulier de caractéristiques, notamment une séquence d'échange (MEP). De plus, des informations essentielles pour l'échange peuvent ne pas faire partie du message lui-même. Elles sont parfois appelées méta-données. Dans le modèle, le message, toute méta-donnée de message et les items d'information divers qui permettent les caractéristiques sont représentés comme des abstractions appelées propriétés.

5.1.1 Propriétés

Selon la convention, les propriétés sont représentés comme suit :

• Les propriétés sont dénommées par des URIs
• Lorsque cela est approprié, les valeurs de propriété DEVRAIENT avoir un type en Schéma XML [XML Schema Partie 1] [XML Schema Partie 2] listé dans la spécification qui introduit la propriété.

5.1.2 Portée de propriété

Les propriétés dans un noeud SOAP peuvent différer en termes de portée et d'origine de leur valeur. Comme l'indique la figure ci-dessous, on fait une distinction entre les propriétés pour un échange de messages et celles à plus large portée en les assignant à différents conteneurs appelés respectivement Contexte d'échange de messages (Message Exchange Context) et Contexte d'environnement (Environment Context). Toutes les propriétés, indépendamment de leur portée, sont partagées par SOAP et une liaison particulière.

Figure 1: Modèle décrivant les propriétés partagées entre SOAP et liaison

5.1.2.1 Contexte d'échange de messages

Un contexte d'échange de messages est une collection de propriétés dont la portée est limitée à une instance d'une séquence d'échange de messages (MEP) donnée. Un exemple de propriété d'un contexte d'échange de message est l'identifiant de la séquence d'échange de messages utilisée.

5.1.2.2 Contexte d'environnement

Le contexte d'environnement est une collection de propriétés dont la portée s'étend au-delà d'une instance d'une séquence d'échange de messages (MEP). L'adresse IP du noeud SOAP ou la date et l'heure courante sont des exemples de propriétés de contexte d'environnement.

Les valeurs de propriétés dans l'environnement pourraient dépendre de circonstances locales (comme décrit par la flèche externe de l'environnement dans la figure ci-dessus). Plus spécifiquement, les propriétés dans l'exemple peuvent être influencées par un ID d'utilisateur dans un système d'exploitation sous le nom duquel un échange de messages est effectué. La correspondance entre informations dans une implémentation particulière et de telles propriétés est hors sujet pour une structure pour liaisons, bien que la représentation abstraite de ces informations sous forme de propriétés ne le soit pas.

5.1.3 Propriétés et caractéristiques

Une caractéristique peut être exprimée au travers de propriétés multiples et une seule propriété peut permettre plusieurs caractéristiques. Par exemple, les propriétés appelées ID utilisateur et Mot de passe peuvent être utilisées pour permettre une caractéristique appelée Authentification. Dans un second exemple, une seule propriété appelée ID message pourrait être utilisée pour permettre une caractéristique appelée Transaction et une seconde caractéristique appelée Corrélation de message.

6. Séquences d'échange de messages et Caractéristiques fournies dans SOAP

6.1 Conventions de propriétés pour séquances d'échange de messages (MEPs) SOAP

Table 2 décrit les propriétés (en accord avec la convention de dénommination de propriété définie dans ce document) qui supportent la description de séquences d'échange de messages (MEPs). D'autres propriétés pourraient être impliquées dans la spécification de MEPs particulières mais les propriétés de ce tableau sont généralement applicables à tous les MEPs.

Table 2: Définitions de propriété supportant la description de MEPs

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 dansTable 3.

Table 3: Définitions de propriétés pour la MEP Requête-Réponse

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.

Il pourrait y avoir d'autres propriétés concernant la mise en oeuvre de l'instance de contexte d'échange de messages. Ces propriétés sont initialisées selon leur propre spécification de caractéristique.

Une fois que le contexte d'échange de message est initialisé, le contrôle du contexte est passé à une instance locale (conforme) de liaison.

Le diagramme ci-dessous montre les transitions d'états logiques aux noeuds SOAP demandeur et répondant pendant la durée de l'échange de messages. À chaque noeud SOAP, l'instance locale de liaison met à jour (logiquement) la valeur de la propriété http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State pour refléter l'état courant de l'échange de messages. Les noms d'état sont des URIs relatives à une URI de base transportée dans la propriété http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role du contexte d'échange de message local.

Figure 2: Diagramme de transition de la MEP Requête-Réponse.

Lorsque l'instance locale de liaison au noeud répondant commence à recevoir un message de requête entrant, elle instancie (logiquement) un contexte d'échange de message. Table 5 décrit les propriétés que la liaison initialise lors de l'instanciation du contexte.

Table 5: Instanciation du contexte d'échange de messages pour un message de requête entrant

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

Table 7: Transitions d'état du noeud SOAP répondant

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], sectionModè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

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

Il peut y avoir d'autres propriétés relatives à l'opération d'instanciation du contexte d'échange de messages. Elles sont initialisées selon leur propre spécification de caractéristique.

Une fois que le contexte d'échange de message est initialisé, le contrôle est passé à une instance locale (conforme) de liaison.

Le diagramme ci-dessous montre les transitions logiques d'état aux noeuds demandeur et répondant durant la vie de l'échange de messages. A chaque noeud SOAP, l'instance locale de la liaison met à jour (logiquement) la valeur de la propriété http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State de manière à refléter l'état courant de l'échange de message. Les noms d'états sont des URIs relatives dont l'URI de base est transportée dans la propriété http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role du contexte d'échange de message local.

Figure 3: Diagramme de transition de la MEP Réponse SOAP

Lorsque l'instance locale de liaison du noeud SOAP répondant commence à recevoir un message de requête entrant, elle instancie (logiquement) un contexte d'échange de message. Table 10 décrit les propriétés que la liaison initialise lors de l'instanciation du contexte.

Table 10: Instanciation de contexte d'échange de message pour un message de requête entrant

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

Table 12: Transitions d'états pour le noeud SOAP répondant

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

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

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 dans6. 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 ou6.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 :

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

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

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

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 ou6.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

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

Table 20: Correspondance entre faute SOAP et état HTTP

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

A. Le type de media "application/soap+xml"

Cette annexe définit le type de media "application/soap+xml" qui peut être utilisé pour décrire des messages SOAP 1.2 sérialisé en XML.

Note:

Au moment de la publication de ce document, le processus d'enregistrement de ce type de media auprès de l'IANA suit son cours, avec le brouillon [SOAP MediaType]. Une version future de la spécification SOAP pourrait faire référence au type de media dans les enregistrements de l'IANA.

A.1 Enregistrement

Nom de type de media MIME :

application

Nom de sous-type MIME :

soap+xml

Paramètres requis :

aucun

paramètres optionnels :

charset

Ce paramètre a la même sémantique que le paramètre charset du type de media "application/xml" tel que spécifié dans la RFC 3023[RFC 3023].

action

Voir section A.3 Le paramètre action.

Considérations d'encodage :

Identiques à celle de "application/xml", telles que décrites dans la RFC 3023 [RFC 3023], section 3.2, comme appliquées à l'infoset d'enveloppe SOAP.

Considérations de sécurité :

Voir section A.2 Considérations de sécurité.

Considérations d'interopérabilité :

Il n'y a pas de problèmes d'interopérabilité connus.

Spécification publiée :

Ce document (Partie 2) et dans la partie 1 de SOAP 1.2 [SOAP Partie 1].

Applications utilisant ce type de media :

Aucune application connue n'utilise actuellement ce type de media.

Informations complémentaires :

Extension de fichier :

Les messages SOAP ne sont pas obligés ni supposés être stockésen tant que fichiers.

Identifiant de fragment :

Identique à celui de "application/xml" tel que décrit dans la RFC 3023 [RFC 3023], section 5.

URI de base :

Tel que spécifié dans la RFC 3023 [RFC 3023], section 6. Voir aussi [SOAP Partie 1], section Utilisation d'URIs dans SOAP.

Code de type de fichier Macintosh :

TEXT

Personne et adresse électronique à contacter pour plus d'informations :

Mark Baker mbaker@idokorro.com

Utilisation envisagée :

COMMON (commune)

Auteur/Contrôle de changements :

L'ensemble de spécifications SOAP 1.2 est un travail produit au Groupe de travail XML Protocoldu World Wide Web Consortium. Le W3C a le contrôle des changements sur ces spécifications.

A.2 Considérations de sécurité

Puisque SOAP peut transporter des données définies par une application, dont la sémantique est indépendante de celle de tout enrobage MIME (ou contexte dans lequel l'enrobage MIME est utilisé), on ne pourrait pas s'attendre à être capable de comprendre la sémantique du message SOAP en se basant sur la sémantique de l'enrobage MIME seul. Par conséquent, dès que l'on utilise le type de media "application/soap+xml" il est FORTEMENT RECOMMANDÉ de comprendre complètement les implications sur la sécurité du contexte dans lequel le message SOAP est utilisé. Les implications sur la sécurité sont susceptibles de mettre en jeu aussi bien la liaison spécifique de SOAP sur un protocole sous-jacent que la sémantique définie par l'application des données transportées dans le message SOAP (bien qu'on doive être très vigilant en utilisant ceci, comme l'indique la discussion dans la partie 1 de SOAP 1.2 [SOAP Partie 1], section Liaison sur des protocoles spécifiques à l'application.

Voir aussi dans la partie 1 de SOAP 1.2 [SOAP Partie 1], la section entière Considérations de sécurité.

De plus, comme ce type de media utilise la convention "+xml", il partage les mêmes considérations de sécurité que celles décrites dans la RFC 3023 [RFC 3023], section 10.

A.3 Le paramètre action

Ce paramètre optionnel peut être utilisé pour spécifier l'URI qui identifie le but du message. Dans SOAP 1.2, il sert à la même chose que le champ d'en-tête HTTP SOAPAction dans SOAP 1.1 : sa valeur identifie le but du message.

La valeur du paramètre action est une URI-référence absolue, comme définie dans la RFC 2396 [RFC 2396]. SOAP ne pose aucune restriction sur la spécificité de l'URI ou sur le fait qu'elle puisse être résolue.

Bien que l'intérêt du paramètre action soit d'indiquer le but du message SOAP, il n'y a pas de mécanisme pour calculer automatiquement sa valeur d'après l'enveloppe SOAP. En d'autres termes, sa valeur doit être déterminée hors-ligne.

Il est recommandé d'utiliser la même valeur pour identifier des ensembles de types de messages logiquement liés d'une certaine manière, par exemple faisant partie d'un même "service". Il est FORTEMENT RECOMMANDÉ que l'URI reste globalement unique et stable dans le temps.

La présence et le contenu du paramètre action POURRAIENT être utilisés par des serveurs comme des pare-feu pour filtrer convenablement les messages SOAP et ils pourraient être utilisés par les serveurs pour faciliter la répartition de messages SOAP à des gestionnaires internes de messages, etc. Ils NE DEVRAIENT PAS être utilisés comme une forme non sécurisée d'autorisation d'accès.

L'utilisation du paramètre action est OPTIONNELLE. Les récepteurs SOAP POURRAIENT l'utiliser comme indice pour optimiser le traitement, mais NE DEVRAIENT PAS requérir sa présence pour fonctionner.

B. Correspondance de noms définis par une application avec des noms XML

Cette annexe détaille un algorithme pour, à un nom défini par une application, comme le nom d'une variable ou d'un champ dans un langage de programmation, fait correspondre les caractères Unicode légaux dans les noms des éléments et attributs XML définis dans[Namespaces in XML]

Hex Digits

B.1 Règles de correspondance entre noms définis par une application et noms XML

1. Un nom XML a deux parties : Prefix (préfixe) etLocalPart (PartieLocale). PrenonsPrefix déterminé par les règles et contraintes spécifiées dans Espaces de nommage en XML (Namespaces in XML) [Namespaces in XML].
2. Soit T un nom dans une application, représenté comme une séquence de caractères encodés dans un encodage de caractères donné.
3. Soit M la fonction définie par l'implémentation pour transcoder les caractères utilisés dans le nom défini par l'application en une chaîne équivalente de caractères Unicode.
   Note:
   Idéalement, si ce transcodage part d'un encodage non-Unicode il devrait à la fois être réversible et normalisant en Unicode Forme C (c'est-à-dire les combinaisons de séquences seront dans l'ordre canonique prescrit). Il est à noter que certains transcodages ne peuvent être parfaitement réversibles et que la normalisation NFC pourrait altérer la séquence originale dans quelques cas. Voir http://www.w3.org/TR/charmod/#sec-Transcoding. Pour s'assurer que des noms concordants continuent à concorder après la correspondance, les séquences Unicode devraient être normalisées avec la Normalisation Unicode Forme C (Normalization Form C).
   Note:
   Ce transcodage est explicitement vers les valeurs scalaires Unicode ("code points") et non vers un schéma d'encodage de caractères particulier d'Unicode, comme UTF-8 ou UTF-16.
   Note:
   Note : les séquences de paires substituts correctement formées doivent être converties en leurs valeurs scalaires respectives ("code points") [c-a-d, la séquence U+D800 U+DC00 devrait être transcodée en caractère U+10000]. Si le transcodage commence avec un encodage Unicode, les séquences UTF-8 et UTF-16 non conformes (formes n'étant pas les plus courtes) doivent être converties en leurs valeurs scalaires respectives.
   Note:
   Le nombre de caractère dans T n'est pas nécessairement le même que le nombre de caractères dans M, car le transcodage peut être de un-vers-plusieurs ou plusieurs-vers-un. Les détails du transcodage peuvent être définis par l'implémentation. Il peut y avoir des cas (très rares) où il n'y a pas de représentation Unicode équivalente pour T ; ces cas ne sont pas couverts ici.
4. Soit C la séquence de valeurs scalaires Unicode (caractères) représentée par M(T)
5. Soit N le nombre de caractères dans C. Soient C1,C2, ..., CN les caractères de C, dans l'ordre du plus au moins significatif (ordre logique).
6. Pour chaque i entre 1 (un) etN, notons Xi la chaîne de caractères Unicode définie par les règles suivantes :
   Cas :
   1. Si Ci n'est pas défini (c-a-d un caractère ou une séquence de caractères défini(e) par la séquence de caractère T de l'application n'a pas de correspondance dans Unicode), alors Xi est défini par l'implémentation
   2. Si i<=N-1 et Ci est "_" (U+005F LOW LINE) et Ci+1 est "x" (U+0078 LATIN SMALL LETTER X), alors Xi sera "_x005F_"
   3. Si i=1, et N>=3, etC1 est "x" (U+0078 LATIN SMALL LETTER X) ou "X" (U+0058 LATIN CAPITAL LETTER X), et C2 est "m" (U+006D LATIN SMALL LETTER M) ou "M" (U+004D LATIN CAPITAL LETTER M), et C3 est "l" (U+006C LATIN SMALL LETTER L) ou "L" (U+004C LATIN CAPITAL LETTER L) (en d'autres termes, une chaîne de 3 lettres ou plus commençant par le texte "xml" ou toute recapitalisation de celui-ci), alors si C1 est "x" (U+0078 LATIN SMALL LETTER X) alors X1 sera "_x0078_"; sinon, si C1 est "X" (U+0058 LATIN CAPITAL LETTER X) alors X1 sera "_x0058_".
   4. Si Ci n'est pas un caractère NCName XML valide (voir Espaces de nommage en XML [Namespaces in XML]) ou sii=1 (un) et C1 n'est pas un premier caractère valide d'un NCName XML (voir [Namespaces in XML]) alors :
      Notons U1, U2, ... , U6 les 6 chiffres hexadécimaux[PROD: 5] tels que Ci soit "U+"U1 U2 ... U6 dans la valeur scalaire Unicode.
      Cas :
      1. Si U1=0,U2=0, U3=0, etU4=0, alors Xi="_x"U5 U6 "_".
         Ce cas implique que Ci est un caractère dans le plan multilingue basique (Basic Multilingual Plane, Plane 0) d'Unicode et peut être complètement représenté par une simple séquence UTF-16 code point U+U5U6.
      2. Sinon, Xi sera "_x" U1 U2 U3 U4 U5 U6 "_".
   5. Sinon, Xi seraMi. C'est-à-dire que tout caractère dans X qui est un caractère valide dans un NCName XML est simplement copié.
7. LocalPart est la chaîne de caractères concaténation de X1, X2, ... , XN dans l'ordre du plus au moins significatif.
8. Le nom XML est le QName d'après Espaces de nommages XML (Namespaces in XML) [Namespaces in XML]

B.2 Exemples

Hello world -> Hello_x0020_world Hello_xorld -> Hello_x005F_xorld Helloworld_ -> Helloworld_

      x -> x
    xml -> _x0078_xml
   -xml -> _x002D_xml
   x-ml -> x-ml

 Ælfred -> Ælfred

άγνωστος -> άγνωστος ᜉᜅᜎᜈ -> x1709__x1705__x170E__x1708 ᏙᏚᎥ -> x13D9__x13DA__x13A5

C. Utilisation de W3C XML Schema avec l'encodage SOAP (non normatif)

Comme noté dans 3.1.4 Calcul de la propriété nom du type (Type Name) les noeuds de graphes SOAP sont étiquetés par des noms de type mais les processeurs conformes ne sont pas obligés d'effectuer la validation des messages SOAP encodés.

Ces sections décrivent des techniques pouvant être utilisées lorsque l'on souhaite utiliser la validation avec les Schémas XML du W3C dans les applications SOAP. Toute erreur ou faute résultant d'une telle validation sont au-delà de ce que couvre la recommandation normative ; du point de vue de SOAP, ces fautes sont considérées comme des échecs au niveau applicatif.

C.1 Validation utilisant le schéma minimal

Bien que les Schémas XML soient conventionnellement échangés sous forme de documents de schéma (voir [XML Schema Partie 1]), la recommandation Schémas est construite sur une définition abstraite de schémas auxquels tous les processeurs doivent se conformer. La recommendation Schémas prévoit que tous ces schémas incluent des définitions d'un ensemble de base de types intégrés d'origine, comme les entiers (integers), les dates, etc. (voir [XML Schema Partie 1], Définition d'origine de type simple (Built-in Simple Type Definition)). Ainsi, il est possible de discuter de la validation d'un message SOAP selon ce schéma miminal, qui est celui que l'on obtiendrait sans fournir de définitions ni déclarations supplémentaires (c-a-d pas de document de schéma) à un processeur de schéma.

Le schéma minimal prévoit que tout document XML bien formé sera valide, sauf que lorsqu'un xsi:type est présent, le type désigné doit être prédéfini d'origine, et l'élément correspondant doit être valide par rapport à ce type. Ainsi, la validation d'un message SOAP 1.2 utilisant un schéma minimal se rapproche des types définis d'origine dans SOAP 1.1.

C.2 Validation utilisant le schéma de l'encodage SOAP

La validation selon le schéma minimal (voir C.1 Validation utilisant le schéma minimal) ne réussira pas là où les noeuds de graphe encodés ont des arcs entrants multiple. Ceci parce que les éléments représentant ces noeuds de graphe vont transporter des_items d'information attributs_ id illégaux sur des éléments de type "xs:string", "xs:integer" etc.

L'encodage SOAP de tels graphes POURRAIT être validé selon leschéma d'encodage SOAP. Pour que cet encodage soit valide, les étiquettes d'arcs et donc les propriétés [local name] et [namespace name] de l'item d'information élément

, doivent nécessairement correspondre à celles définies dans le schéma de l'encodage SOAP. La validation du graphe encodé selon le schéma d'encodage SOAP résulterait en l'assignation du nom de type adéquat à la propriété nom de type du noeud de graphe.

C.3 Validation utilisant des schémas plus spécifiques

Il se pourrait que des schémas soient construits pour décrire l'encodage de certains graphes. La validation du graphe encodé selon ce schéma résulterait en l'assignation du nom de type adéquat à la propriété nom de type du noeud de graphe. Un tel schéma peut aussi fournir des valeurs par défaut ou fixées pour un ou plus des items d'information attributs itemType , arraySize ou nodeType ; de telles valeurs d'attributs par défaut affectent le graphe désérialisé de la même manière que si les attributs étaient explicitement fournis dans le message. Les erreurs ou incohérences introduites par suite (par ex. si la valeur d'un attribut est fausse ou inappropriée) devraient être rapportées comme erreurs du niveau application ; les fautes provenant de l'espace de nommage "http://www.w3.org/2003/05/soap-encoding" ne devraient être rapportées que si les parties normatives de cette spécification sont violées.

D. Remerciements (non normatif)

Cette spécification est le travail du groupe de travail XML Protocol du W3C.

Participent au groupe de travail (à ce jour et par ordre alphabétique) : Carine Bournez (W3C), Michael Champion (Software AG), Glen Daniels (Macromedia, formerly of Allaire), David Fallside (IBM), Dietmar Gaertner (Software AG), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric), Kazunori Iwasa (Fujitsu Limited), Mario Jeckle (DaimlerChrysler R. & Tech), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jacek Kopecky (Systinet/Idoox), Yves Lafon (W3C), Michah Lerner (AT&T), Noah Mendelsohn (IBM, formerly of Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Limited), Eric Newcomer (IONA Technologies), Mark Nottingham (BEA Systems, formerly of Akamai Technologies), David Orchard (BEA Systems, formerly of Jamcracker), Andreas Riegg (DaimlerChrysler R. & Tech), Hervé Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Miroslav Simek (Systinet/Idoox), Pete Wenzel (SeeBeyond), Volker Wiechers (SAP AG).

Ont été membres : Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur Apparao (Netscape), Camilo Arbelaez (WebMethods), Mark Baker (Idokorro Mobile (Planetfred), formerly of Sun Microsystems), Philippe Bedu (EDF (Electricité de France)), Olivier Boudeville (EDF (Electricité de France)), Don Box (Microsoft Corporation, formerly of DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Conleth O'Connell (Vignette), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (eXcelon), Ron Daniel (Interwoven), Dug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE), Frank DeRose (Tibco), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), Colleen Evans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett-Packard), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Erin Hoffman (Tradia), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Software Corporation), Yin-Leng Husband (Hewlett-Packard, formerly of Compaq), Scott Isaacson (Novell), Murali Janakiraman (Rogue Wave), Eric Jenkins (Engenia Software), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Amy Lewis (TIBCO), Bob Lojek (Intalio), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Highland Mary Mountain (Intel), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Don Mullen (Tibco), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco), Mark Needleman (Data Research Associates), Art Nevarez (Novell), Henrik Nielsen (Microsoft Corporation), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera), Krishna Sankar (Cisco), George Scott (Tradia), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Simeon Simeonov (Allaire), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (WebMethods), Randy Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Ray Whitmer (Netscape), Stuart Williams (Hewlett-Packard), Yan Xu (DataChannel), Amr Yassin (Philips Research), Susan Yee (Active Data Exchange), Jin Yu (Martsoft).

Aux personnes ayant contribué aux discussions surxml-dist-app@w3.org nous adressons notre reconnaissance et nos remerciements.