Ce document est une traduction susceptible d'évoluer. Toute amélioration est la bienvenue : e-mail.
La version française de cette traduction est : http://www.w3.org/2002/07/soap-translation/soap12-part1.html
Traductrice : Carine Bournez - <[email protected]> La version française peut contenir des erreurs. La version anglaise de cette spécification est l'unique version normative.
Copyright©2003W3C® (MIT, ERCIM, Keio), Tous droits réservés. W3C liability, trademark, document use, and software licensing rules apply.
SOAP Version 1.2 est un protocole léger destiné à l'échange d'information structurée dans un environnement décentralisé, distribué. La "Partie 1: Structure pour l'échange de messages" définit, grâce à des technologies XML, une structure extensible d'échange de messages incluant une construction de message pouvant être échangés sur divers protocoles sous-jacents.
Cette section décrit le statut de ce document à la date de sa publication. D'autres documents pourront remplacer celui-ci. Le dernier statut de cette série de documents est maintenu par le W3C.
1. Introduction
2. Modèle de traitement SOAP
3. Modèle d'extensibilité de SOAP
4. Structure pour une liaison SOAP sur un protocole
5. Construction de message SOAP
6. Utilisation d'URIs dans SOAP
7. Considérations de sécurité
8. Références
A. Transition de version de SOAP/1.1 à SOAP Version 1.2
B. Remerciements (non normatif)
1. Introduction
1.1 Conventions de notation
1.2 Règles de conformité
1.3 Relations avec d'autres spécifications
1.3.1 Obligations de traitement
1.4 Exemple de message SOAP
1.5 Terminologie SOAP
1.5.1 Concepts de protocole
1.5.2 Concepts d'encapsulation de données
1.5.3 Concepts d'émetteur et récepteur de messages
2. Modèle de traitement SOAP
2.1 Noeuds SOAP
2.2 Rôles SOAP et noeuds SOAP
2.3 Ciblage des blocs d'en-tête SOAP
2.4 Comprendre les en-têtes SOAP
2.5 Structure et interprétation de corps SOAP
2.6 Traitement de messages SOAP
2.7 Relais de messages SOAP
2.7.1 Relais de blocs d'en-tête SOAP
2.7.2 Intermédiaires de Réacheminement SOAP
2.7.3 Intermédiaires Actifs SOAP
2.8 Modèle de gestion de version SOAP
3. Modèle d'extensibilité de SOAP
3.1 Caractéristiques SOAP
3.1.1 Obligations pour les caractéristiques
3.2 Séquences d'échange de messages SOAP (Message Exchange Patterns, MEPs)
3.3 Modules SOAP
4. Structure pour une liaison SOAP sur un protocole
4.1 Objectifs de la structure pour les liaisons
4.2 Structure pour une liaison
5. Construction de message SOAP
5.1 Enveloppe SOAP
5.1.1 Attribut SOAP encodingStyle (style d'encodage)
5.2 En-tête SOAP
5.2.1 Bloc d'en-tête SOAP
5.2.2 Attribut SOAP role
5.2.3 Attribut SOAP mustUnderstand (doitComprendre)
5.2.4 Attribut SOAP relay (relaie)
5.3 Corps SOAP
5.3.1 Élément fils d'un corps SOAP
5.4 Faute SOAP
5.4.1 Élément SOAP Code
5.4.1.1 Élément SOAP Value (avec un parent Code)
5.4.1.2 Élément SOAP Subcode (sous-code)
5.4.1.3 Élément SOAP Value (avec un parent Subcode)
5.4.2 Élément SOAP Reason (raison)
5.4.2.1 Élément SOAP Text (texte)
5.4.3 Élément SOAP Node (noeud)
5.4.4 Élément SOAP Role
5.4.5 Élement SOAP Detail
5.4.5.1 Entrée de détail SOAP
5.4.6 Codes de faute SOAP
5.4.7 Fautes VersionMismatch (Décalage de Version)
5.4.7.1 Bloc d'en-tête SOAP Upgrade (MiseÀNiveau)
5.4.7.2 Élément SOAP SupportedEnvelope (EnveloppeSupportée)
5.4.7.3 Attribut SOAP qname
5.4.7.4 Exemple de décalage de version (VersionMismatch)
5.4.8 Fautes SOAP mustUnderstand (doitComprendre)
5.4.8.1 Élément SOAP NotUnderstood (NonCompris)
5.4.8.2 Attribut SOAP qname
5.4.8.3 Exemple non compris (NotUnderstood)
6. Utilisation d'URIs dans SOAP
7. Considérations de sécurité
7.1 Noeuds SOAP
7.2 Intermédiaires SOAP
7.3 Liaisons sur protocoles sous-jacents
7.3.1 Liaison sur des protocoles applicatifs spécifiques
8. Références
8.1 Références normatives
8.2 Références informatives
A. Transition de version de SOAP/1.1 à SOAP Version 1.2
B. Remerciements (non normatif)
SOAP Version 1.2 (SOAP) est un protocole léger destiné à l'échange d'informations structurées dans un environnement décentralisé, distribué. Il utilise des technologies XML pour définir une structure d'échange de messages fournissant une construction de messages pouvant être échangés sur divers protocoles sous-jacents. La structure a été conçue pour être indépendante de tout modèle de programmation et autres sémantiques spécifiques d'implémentation.
Simplicité et extensibilité sont deux objectifs primordiaux de la conception de SOAP (voir XMLP Requirements [XMLP Requirements]). SOAP tente d'atteindre ces objectifs en évitant dans la structure pour l'échange de messages des caractéristiques fréquemment rencontrées dans les systèmes distribués. Ces caractéristiques incluent entre autres la "fiabilité", la "sécurité", la "corrélation", le "routage" et le concept de séquences d'échange de messages (message exchange patterns - MEPs). Si la définition future de telles fonctionnalités est prévisible, cela ne relève pas de cette spécification.
La spécification SOAP Version 1.2 est constituée de trois parties. La partie 1 de la spécification SOAP Version 1.2 (ce document) définit la séquence d'échange de messages, constituée :
du modèle de traitement SOAP définissant les règles pour traiter un message SOAP (voir 2. Modèle de traitement SOAP).
du modèle d'extensibilité SOAP définissant les concepts de caractéristique SOAP et module SOAP (voir 3. Modèle d'extensibilité de SOAP).
de la structure pour les liaisons SOAP sur un protocole sous-jacent, décrivant les règles de définition d'une liaison sur un protocole, utilisable pour échanger des messages entre noeuds SOAP (voir 4. Structure pour une liaison SOAP sur un protocole).
de la construction d'un message SOAP, définissant l'aspect d'un message SOAP (voir 5. Construction de message SOAP).
La partie 0 de SOAP 1.2 [SOAP Partie 0] est un document non normatif destiné à fournir un tutoriel facile à comprendre à propos des caractéristiques de la spécification de la version 1.2 de SOAP.
La partie 2 SOAP 1.2 [SOAP Partie 2] décrit un ensemble d'ajouts utilisables en conjonction avec la structure pour les échanges 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.
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 InfoSet XML [XML InfoSet]).
Préfixe | Espace de nommage | Notes |
---|---|---|
env | "http://www.w3.org/2003/05/soap-envelope" | Un Schéma XML normatif [XML Schema Partie 1], [XML Schema Partie 2] pour l'espace de nommage "http://www.w3.org/2003/05/soap-envelope" se trouve à http://www.w3.org/2003/05/soap-envelope. |
xs | "http://www.w3.org/2001/XMLSchema" | L'espace de nommage de la spécification Schéma XML [XML Schema Partie 1], [XML Schema Partie 2] |
Les noms d'espaces de nommage de la forme générale "http://example.org/..." et "http://example.com/..." représentent des URIs dépendantes d'une application ou d'un contexte (voir la RFC 2396 [RFC 2396]).
Toute partie de cette spécification est normative, à l'exception des exemples et des sections explicitement marquées comme "non normatifs".
Cette spécification décrit des formats de données ainsi que des règles pour générer, échanger et traiter des messages en utilisant ces formats. Cette spécification n'impose aucune portée d'une implémentation en particulier, bien qu'elle requiert des implémentations de ne violer aucune des clauses obligatoires.
Pour qu'une implémentation déclare sa conformité avec la spécification SOAP Version 1.2, elle DOIT correctement implémenter toutes les clauses obligatoires ("DOIT") exprimées dans la partie 1 de la spécification SOAP Version 1.2 (ce document) appartenant à l'activité effectuée. Notez qu'une implémentation n'est pas obligée d'implémenter toutes les clauses obligatoires. Par exemple, une implémentation dédiée qui n'envoie jamais un bloc d'en-tête SOAP peut se déclarer conforme pourvu qu'elle implémente correctement les clauses obligatoires appartenant aux messages qu'elle envoie.
Une implémentation POURRAIT implémenter un nombre quelconque des Ajouts spécifiés dans la partie 2 de SOAP 1.2 [SOAP Partie 2]. Notez qu'aucune règle de conformité n'est associée à la convention de description de caractéristiques et de liaisons (voir 3. Modèle d'extensibilité de SOAP et 4. Structure pour une liaison SOAP sur un protocole). L'implémentation d'un Ajout DOIT implémenter toutes les clauses obligatoires applicables exprimées dans la spécification des Ajouts pour se déclarer conforme avec cet Ajout.
SOAP Version 1.2 peut être utilisé comme base pour d'autres technologies fournissant des services plus riches ou plus spécialisés. Pour se déclarer conforme à la spécification SOAP Version 1.2, les spécifications et implémentations de telles technologies doivent être cohérentes avec les clauses obligatoires applicables exprimées dans la partie 1 de la spécification SOAP Version 1.2 (ce document). Les règles de conformité de ces nouvelles spécifications sont au-delà de la portée de la spécification SOAP Version 1.2 ; il est recommandé que les spécifications de telles technologies fournissent les règles de conformité appropriées.
SOAP Version 1.2 est conçu pour permettre au moins les scénarios d'utilisation décrits dans les Scenarios d'Utilisation SOAP 1.2 (Usage Scenarios) [SOAP Usage Scenarios] et éventuellement d'autres. Des descriptions informelles de représentations en XML de messages SOAP concrets utilisés dans des scénarios courants sont fournis dans la partie 0 de SOAP 1.2 [SOAP Partie 0].
Un message SOAP est spécifié comme un Ensemble d'Information XML (Infoset XML) [XML InfoSet]. Si tous les exemples de messages SOAP de ce document sont donnés dans la syntaxe XML 1.0 [XML 1.0], d'autres représentations POURRAIENT être utilisées pour transmettre des messages SOAP entre noeuds (voir 4. Structure pour une liaison SOAP sur un protocole).
Certains des items d'information définis par ce document (voir 5. Construction de message SOAP) sont identifiés grâce à un des [Namespaces in XML] noms qualifiés dans un espace de nommage XML. Voir Table 1 pour une liste des noms d'espaces de nommage définis dans ce document.
Note:
Cette spécification utilise le terme Nom XML Étendu (XML Expanded Name) pour désigner la paire d'espaces de valeur {uri absolue de référence,nom-local} pour une valeur de type xsd:QName. L'inclusion d'une terminologie similaire est en cours d'étude pour les versions futures de Espaces de nommage en XML (Namespaces in XML) [Namespaces in XML]. Si des versions futures de [Namespaces in XML] venaient à adopter une terminologie différente, il est prévu d'appliquer à cette recommandation les changements correspondants sous forme d'un erratum ou lors d'une autre révision future.
SOAP ne requiert pas de traitement (évaluation ou validation) du Schéma XML pour établir l'exactitude ou les valeurs 'déduites du Schéma' d'items d'information éléments ou attributs définis par les parties 1 et 2 de cette spécification. Les valeurs associées à des items d'information éléments et attributs définis dans cette spécification DOIVENT être explicitement transportées dans le message SOAP transmis sauf indication contraire (voir 5. Construction de message SOAP).
Les items d'information attributs SOAP ont des types
décrits par XML Schema [XML Schema Partie 2]. Sauf indication contraire, toutes les formes
lexicales représentant la même valeur dans l'espace de valeurs du Schéma
XML sont considérées équivalentes pour le traitement SOAP, par exemple les
formes booléennes "1" et "true" (vrai)
sont interchangeables. Pour abréger, le texte de cette spécification
ne fait référence qu'à une forme lexicale pour chaque valeur, par exemple
"si la valeur de l'item d'information attribut
mustUnderstand
est 'true' (vrai)".
Les spécifications pour le traitement de données applicatives transportées dans un message SOAP mais non définies dans cette spécification POURRAIENT amener à une validation supplémentaire du message SOAP, en conjonction avec le traitement du niveau applicatif. Dans ce cas, le choix du langage de schéma et/ou de la technologie de validation est à l'appréciation de l'application.
SOAP utilise XML Base [XML Base] pour déterminer une URI de base pour les références à des URIs relatives utilisées comme valeurs dans des items d'information définis dans cette spécification (voir 6. Utilisation d'URIs dans SOAP).
Le type de média "application/soap+xml" [soap-media-type] DEVRAIT être utilisé pour les sérialisations XML 1.0 d'infoset de message SOAP (voir dans la partie 2 de SOAP 1.2 [SOAP Partie 2], Le Type de Media "application/soap+xml").
La possibilité d 'utiliser SOAP dans un environnement donné varie en fonction des contraintes réelles, choix d'outils, modèle de traitement ou nature des messages échangés. SOAP a été conçu avec un nombre relativement faible de dépendances d'autres spécifications XML, dont aucune ne semble impliquer des obligations rédhibitoires sur le traitement. De plus, limiter l'utilisation de SOAP à des messages brefs au lieu de messages de taille arbitraire, et ne supporter que quelques messages spécifiques au lieu d'implémenter un traitement généralisé peut réduire de manière significative les obligations de traitement.
L'exemple suivant montre un message de notification exprimé en SOAP.
Le message contient deux données définies par l'application et non par
cette spécification :
Un bloc d'en-tête SOAP avec un nom local alertcontrol
et un
élément corps avec un nom local alert
. En général, les blocs
d'en-tête SOAP contiennent des informations pouvant être utiles à des
intermédiaires SOAP aussi bien qu'au destinataire final du message. Dans cet
exemple, un intermédiaire peut réordonner la livraison du message en
fonction de la priorité et de la date d'expiration du bloc d'en-tête SOAP.
Le corps contient la vraie charge du message, dans le cas présent le
message d'alerte.
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> <n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>Pick up Mary at school at 2pm</m:msg> </m:alert> </env:Body> </env:Envelope>
Cette section décrit les termes et concepts introduits dans la partie 1 de la spécification SOAP Version 1.2 (ce document).
L'ensemble formel de conventions régissant le format et les règles de traitement d'un message SOAP. Ces conventions incluent les interactions entre noeuds SOAP générant et acceptant des messages SOAP dans le but d'échanger des informations sur un chemin de message SOAP.
L'incarnation de la logique de traitement nécessaire à la transmission, à la réception, au traitement et/ou au relais d'un message SOAP, selon l'ensemble de conventions défini par cette recommandation. Un noeud SOAP est responsable du suivi des règles régissant l'échange de messages SOAP (voir 2. Modèle de traitement SOAP). Il accède aux services fournis par les protocoles sous-jacents au travers d'une ou plusieurs liaisons SOAP.
Une fonction attendue d'un récepteur SOAP dans le traitement d'un message. Un noeud SOAP peut jouer de multiples rôles.
L'ensemble formel de règles pour transporter un message SOAP à l'intérieur ou au-dessus d'un autre protocole (protocole sous-jacent) dans un but d'échange (voir 4. Structure pour une liaison SOAP sur un protocole). Des exemples de liaisons SOAP incluent le transport de message SOAP dans un corps-entité HTTP ou sur un flot TCP.
Une extension de la structure d'échange de messages SOAP (voir 3. Modèle d'extensibilité de SOAP). Parmi les exemples de caractéristiques figurent "fiabilité", "sécurité", "corrélation", "routage" et le concept de séquences d'échange de messages.
Un module SOAP est une spécification contenant la syntaxe et la sémantique combinées de blocs d'en-tête SOAP spécifiés selon les règles de 3.3 Modules SOAP. Un module SOAP réalise zéro ou plus caractéristiques SOAP.
Une forme de référence pour l'échange de messages SOAP entre noeuds SOAP grâce à une ou plusieurs liaisons SOAP sur protocole sous-jacent (voir 4. Structure pour une liaison SOAP sur un protocole). Une MEP SOAP est un exemple de caractéristique SOAP (voir 3.2 Séquences d'échange de messages SOAP (Message Exchange Patterns, MEPs)).
Une entité, typiquement un logiciel, qui produit, consomme ou agit de quelque manière sur des messages SOAP en conformité avec le modèle de traitement SOAP (voir 2. Modèle de traitement SOAP).
L'unité de base de communication entre noeuds SOAP.
L'item d'information élément le plus englobant d'un message SOAP.
Une collection de zéro blocs d'en-tête SOAP ou plus, dont chacun peut être destiné à un récepteur SOAP quelconque du chemin du message SOAP.
Un item d'information élément utilisé pour délimiter des données constituant logiquement une unité de calcul simple dans l'en-tête SOAP. Le type de bloc d'en-tête SOAP est identifié par le nom qualifié en XML de l'item d' information élément du bloc d'en-tête.
Une collection de zéro items d'information éléments ou plus, destinés à un récepteur SOAP final sur le chemin du message SOAP (voir 5.3 Corps SOAP).
Un item d'information élément SOAP qui contient des informations sur une faute générée par un noeud SOAP.
Un noeud SOAP qui transmet un message SOAP.
Un noeud SOAP qui accepte un message SOAP.
L'ensemble de noeuds SOAP au travers desquels passe un simple message SOAP. Ceci inclut l'émetteur SOAP initial, zéro ou plus intermédiaires SOAP et un récepteur SOAP final.
L'émetteur SOAP qui crée un message SOAP au point de départ du chemin du message SOAP.
Un intermédiaire SOAP est à la fois un récepteur SOAP et un émetteur SOAP et peut être ciblé par une partie d'un message SOAP. Il traite les blocs d'en-tête SOAP qui lui sont destinés et agit pour faire suivre un message SOAP vers son récepteur SOAP final.
Le récepteur SOAP qui est la destination finale d'un message SOAP. Il est responsable du traitement du contenu du corps SOAP et de tout bloc d'en-tête qui lui est destiné. Dans certains cas, un message SOAP peut ne pas atteindre son récepteur SOAP final, par exemple en raison d'un problème sur un intermédiaire SOAP. Un récepteur SOAP final ne peut pas être en même temps un intermédiaire SOAP pour le même message (voir 2. Modèle de traitement SOAP).
SOAP fournit un modèle de traitement distribué qui suppose qu'un message SOAP naît dans un émetteur SOAP initial et est envoyé à un récepteur SOAP final via zéro ou plusieurs intermédiaires SOAP. Notez que le modèle de traitement distribué de SOAP peut supporter de nombreuses séquences d'échange de messages dont entre autres les messages unidirectionnels, les interactions requête/réponse et les conversations d'égal à égal (voir 3.2 Séquences d'échange de messages SOAP (Message Exchange Patterns, MEPs) pour une description de la relation entre séquences d'échange de messages SOAP et le modèle d'extensibilité de SOAP).
Cette section définit le modèle de traitement distribué de SOAP. Le modèle de traitement SOAP spécifie comment un récepteur SOAP traite un message SOAP. Il s'applique à un message unique, pris isolément de tout autre message. Le modèle de traitement SOAP en lui-même ne maintient pas d'état ni ne réalise la corrélation ou la coordination entre messages, même par exemple en combinaison avec une caractéristique SOAP impliquant l'envoi de messages multiples en séquence, chaque message suivant dépendant de la réponse au précédent message. Il va de la responsabilité de chaque caractéristique de de genre de définir tout traitement combiné.
La section 3. Modèle d'extensibilité de SOAP décrit comment SOAP peut être étendu et comment les extensions de SOAP peuvent interagir avec le modèle de traitement de SOAP et la structure pour les liaisons sur protocoles. La section 4. Structure pour une liaison SOAP sur un protocole définit une structure pour décrire les règles selon lesquelles les messages SOAP peuvent être échangés sur divers protocoles sous-jacents.
Un noeud SOAP peut être émetteur SOAP initial, récepteur SOAP final ou intermédiaire SOAP. Un noeud SOAP recevant un message SOAP DOIT réaliser un traitement selon le modèle de traitement SOAP tel que décrit dans cette section et le reste de cette spécification. Un noeud SOAP est identifié par une URI, voir 5.4.3 Élément SOAP Node (noeud).
Lorsqu'il traite un message SOAP, on dit d'un noeud SOAP qu'il remplit un ou plusieurs rôles, chacun étant identifié par une URI connue comme le nom du rôle SOAP. Les rôles joués par un noeud DOIVENT être invariants durant le traitement d'un message SOAP individuel. Cette spécification s'occupe uniquement du traitement d'un message SOAP individuellement. Aucune assertion n'est faite concernant la possibilité qu'un noeud SOAP donné puisse ou ne puisse pas remplir divers rôles en traitant plusieurs messages SOAP.
Table 2 définit trois noms de rôles ayant une signification spéciale dans un message SOAP (voir 2.6 Traitement de messages SOAP).
Nom abrégé | Nom | Description |
---|---|---|
next |
"http://www.w3.org/2003/05/soap-envelope/role/next". | Chaque intermédiaire SOAP et le récepteur SOAP final DOIVENT remplir ce rôle. |
none |
"http://www.w3.org/2003/05/soap-envelope/role/none" | Les noeuds SOAP NE DOIVENT PAS remplir ce rôle. |
ultimateReceiver |
"http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver" | Le récepteur SOAP final SOAP DOIT remplir ce rôle. |
En plus de ceux décrits dans Table 2, d'autres rôles POURRAIENT être utilisés si nécessaire en fonction des besoins des applications SOAP.
Si le but d'un nom de rôle SOAP est d'identifier un ou des noeuds SOAP, il n'y a pas de sémantique de routage ou de séquence d'échange de messages associée au nom de rôle SOAP. Par exemple, les rôles SOAP POURRAIENT être dénommés avec une URI utilisable pour router des messages vers un noeud SOAP approprié. Inversement, il est également approprié d'utiliser des rôles SOAP ayant des noms moins directement en rapport avec le routage de message (par ex. "http://example.org/banking/anyAccountMgr") ou sans rapport avec le routage (par ex. une URI destinée à identifier "tous les logiciels de gestion de cache". Par exemple, un bloc d'en-tête SOAP pourrait être utilisé pour transporter une indication pour tout logiciel concerné signalant que le contenu du message SOAP est idempotent et peut sans risque être caché et repris).
À l'exception des trois rôles SOAP définis dans Table 2, cette spécification n'impose pas le critère selon lequel un noeud donné détermine l'ensemble de rôles qu'il remplit pour un message donné. Par exemple, les implémentations peuvent baser cette détermination sur des fonctions incluant (liste non exhaustive) : choix codés en dur dans l'implémentation, information fournie par le protocole sous-jacent (par ex. l'URI à laquelle le message a été physiquement délivré) ou information de configuration fournie par les utilisateurs lors de l'installation du système.
Un bloc d'en-tête SOAP POURRAIT transporter un
item d'information attribut role
(voir 5.2.2 Attribut SOAP role ) utilisé pour cibler le bloc d'en-tête sur des noeuds SOAP
jouant le rôle spécifié. Cette spécification se base sur la
valeur de l'item d'information attribut role
comme rôle SOAP pour le bloc d'en-tête
SOAP correspondant.
Un bloc d'en-tête SOAP est dit ciblé sur un noeud SOAP si le rôle SOAP pour le bloc d'en-tête est le nom d'un rôle que le noeud SOAP peut jouer. Les blocs d'en-tête SOAP ciblés sur le rôle spécial "http://www.w3.org/2003/05/soap-envelope/role/none" ne sont jamais formellement traités. De tels blocs d'en-tête POURRAIENT transporter des données nécessaires au traitement d'autres blocs d'en-tête. Sauf s'ils sont retirés par action d'un intermédiaire (voir 2.7 Relais de messages SOAP), ces blocs sont relayés avec le message jusqu'au récepteur final (voir aussi 3.3 Modules SOAP).
Il est probable que des spécifications d'une large variété de fonctions d'en-tête (c-a-d des modules SOAP) seront développées avec le temps (voir 3.3 Modules SOAP) et que des noeuds SOAP pourront inclure le logiciel nécessaire pour implémenter une ou plusieurs de ces extensions. On dit d'un bloc d'en-tête SOAP qu'il est compris par un noeud SOAP si le logiciel de ce noeud SOAP a été écrit pour implémenter complètement et en s'y conformant la sémantique spécifiée pour le nom XML étendu de l'item d'information élément le plus englobant de ce bloc d'en-tête.
Les blocs d'en-tête SOAP POURRAIENT transporter un
item d'information attribut mustUnderstand
(voir 5.2.3 Attribut SOAP mustUnderstand (doitComprendre)). Lorsque la valeur d'un tel
item d'information attribut est "true"
(vrai), le bloc SOAP est dit obligatoire.
Les blocs d'en-tête SOAP obligatoires sont supposés modifier d'une manière ou d'une autre la sémantique d'autres en-têtes ou éléments du corps. Par conséquent, chaque fois qu'un bloc d'en-tête SOAP obligatoire est ciblé sur un noeud, ce noeud DOIT soit traiter le bloc d'en-tête, soit ne pas traiter le message SOAP du tout et à la place générer une faute (voir 2.6 Traitement de messages SOAP et 5.4 Faute SOAP). Marquer des blocs d'en-tête SOAP comme obligatoires assure donc que de telles modifications ne seront pas ignorées silencieusement (et vraisemblablement à tort) par un noeud SOAP auquel le bloc d'en-tête est destiné.
L'item d'information attribut
mustUnderstand
n'a pas pour vocation d'être un mécanisme
de détection d'erreurs dans le routage, de mauvaises identifications de
noeuds, d'échecs de la part d'un noeud dans son service pour un rôle
prévu, etc. N'importe laquelle de ces conditions peut résulter en un
échec en essayant même de traiter un bloc d'en-tête SOAP donné dans une
enveloppe SOAP. Cette spécification ne requiert donc pas de générer une
faute en l'absence ou sur une valeur de l'item d'information attribut
mustUnderstand
dans un bloc d'en-tête SOAP non ciblé
sur le noeud de traitement courant. En particulier, il n'y a pas d'erreur
si un récepteur SOAP final reçoit un message contenant un bloc d'en-tête
obligatoire ciblé sur un autre rôle que ceux qu'il assure. Ce cas se
présente, par exemple, lorsqu'un bloc d'en-tête a survécu en raison d'une
erreur de routage ou de ciblage à l'intermédiaire précédent.
Un récepteur SOAP final DOIT traiter correctement les fils directs du corps SOAP (voir 5.3 Corps SOAP). Cependant, à l'exception des fautes SOAP (voir 5.4 Faute SOAP), la partie 1 de cette spécification (ce document) n'impose aucune structure ou interprétation de ces éléments et ne fournit aucune technique standard pour spécifier le traitement à effectuer.
Cette section définit les règles selon lesquelles les messages SOAP sont traités. Rien dans cette spécification n'interdit d'utiliser l'accès simultané optimiste (collatéralité), le retour en arrière ou d'autres techniques pouvant augmenter la flexibilité dans l'ordre du traitement, Sauf mention contraire, le traitement de tous les messages SOAP générés, les fautes SOAP et les effets de bords au niveau applicatif DOIT être sémantiquement équivalent à l'exécution des étapes suivantes séparément et dans l'ordre indiqué.
Déterminer l'ensemble de rôles remplis par le noeud. Le contenu de l'enveloppe SOAP, tout bloc d'en-tête et corps inclus, DEVRAIT être inspecté pour cette détermination.
Identifier parmi les blocs d'en-tête destinés à ce noeud tous ceux qui sont obligatoires.
Si l'un ou plusieurs des blocs d'en-tête identifiés par l'étape
précédente ne sont pas compris par le noeud, générer alors une
simple faute SOAP avec la valeur Value
de Code
fixée à "env:MustUnderstand" (doitComprendre) (voir
5.4.8 Fautes SOAP mustUnderstand (doitComprendre)). Si une telle faute est générée, aucun
traitement ultérieur NE DOIT être effectué. Les fautes liées au
contenu du corps NE DOIVENT PAS être générées à cette étape.
Note:
Tout au long de ce document, le terme "Value
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 5.4.1 Élément SOAP Code).
Traiter tous les blocs d'en-tête ciblés sur le noeud et, dans le cas d'un récepteur SOAP final, le corps SOAP. Un noeud SOAP POURRAIT également choisir de traiter blocs d'en-tête non-obligatoires qui lui sont destinés.
Dans le cas d'un intermédiaire SOAP et quand la séquence d'échange de messages et le résultat du traitement (par ex. pas de faute générée) requiert d'envoyer le message plus loin sur son chemin SOAP, relayer le message comme décrit dans la section 2.7 Relais de messages SOAP.
Dans tous les cas où un bloc d'en-tête SOAP est traité, le noeud SOAP DOIT comprendre le bloc d'en-tête SOAP et DOIT effectuer un tel traitement en conformité totale avec la spécification de ce bloc d'en-tête. Le traitement réussi d'un bloc d'en-tête ne garantit pas le traitement réussi d'un autre bloc avec le même nom XML étendu dans le même message : la spécification d'un bloc d'en-tête détermine les circonstances dans lesquelles tel traitement résulterait en une faute. Un récepteur SOAP final DOIT traiter le corps SOAP, de manière cohérente avec 2.5 Structure et interprétation de corps SOAP.
L'échec est indiqué par la génération d'une faute (voir 5.4 Faute SOAP). Le traitement d'un message SOAP POURRAIT aboutir à la génération d'au plus une faute.
Un message peut contenir ou résulter en plusieurs erreurs lors du traitement. Excepté le cas où l'ordre de détection est spécifiquement indiqué (comme dans 2.4 Comprendre les en-têtes SOAP), un noeud SOAP a la liberté de refléter n'importe laquelle des fautes de l'ensemble de fautes possibles prévues pour les erreurs rencontrées. La sélection d'une faute n'a pas besoin d'être basée sur l'application des mots-clés "DOIT", "DEVRAIT" ou "POURRAIT" pour la génération de la faute, sauf si une ou plusieurs des fautes prévues sont qualifiées par "DOIT", alors une faute de l'ensemble de ces fautes possibles DOIT être générée.
Les noeuds SOAP POURRAIENT faire référence à toute information dans l'enveloppe SOAP lors du traitement d'un bloc de corps SOAP ou d'en-tête SOAP. Par exemple, une fonction de cache peut cacher un message SOAP entier si nécessaire.
Le traitement d'un ou plusieurs blocs d'en-tête SOAP POURRAIT contrôler ou déterminer l'ordre de traitement pour d'autres blocs d'en-tête SOAP et/ou le corps SOAP. Par exemple, on pourrait créer un bloc d'en-tête SOAP pour forcer à traiter d'autres blocs d'en-têtes SOAP dans l'ordre alphabétique. En l'absence d'un tel bloc d'en-tête SOAP de contrôle, l'ordre du traitement de l'en-tête et du corps est à la discrétion du noeud SOAP. Les blocs d'en-tête POURRAIENT être traités dans un ordre arbitraire. Le traitement des blocs d'en-tête POURRAIT précéder, POURRAIT s'intercaler dans ou POURRAIT suivre le traitement du corps. Par exemple, le traitement d'un bloc d'en-tête "commencer transaction" précéderait en principe le traitement du corps, une fonction "journaliser" pourrait s'exécuter simultanément avec le traitement du corps et un en-tête "valider transaction" serait honoré après la terminaison de tous les autres travaux.
Note:
Les règles ci-dessus s'appliquent au traitement par un
noeud pris isolément. Des extensions de SOAP peuvent être conçues
pour s'assurer que les en-têtes sont traités dans un ordre approprié,
lors de l'avancement du message sur son chemin vers le récepteur SOAP
final.
De manière plus précise, de telles extensions peuvent spécifier qu'une
faute avec une valeur Value
de Code
fixée à
"env:Sender" est générée si un bloc d'en-tête SOAP
a survécu par inadvertance après un certain point du chemin du message.
De telles extensions peuvent se baser sur la présence ou la valeur
de l'item d'information attribut mustUnderstand
dans les en-têtes restants pour déterminer si une erreur est survenue.
Comme mentionné précédemment dans cette section, on suppose qu'un message SOAP naît dans un émetteur SOAP initial et est envoyé à un récepteur SOAP final via zéro ou plus intermédiaires SOAP. Si SOAP en lui-même ne définit pas de sémantique de routage ou de réacheminement, on peut prévoir de décrire d'une telle fonctionnalité par une ou plusieurs caractéristiques (voir 3. Modèle d'extensibilité de SOAP). Le but de cette section est de décrire comment le réacheminement de message interagit avec le modèle de traitement distribué de SOAP.
SOAP définit deux types d'intermédiaires différents : les intermédiaires de réacheminement (forwarding intermediaries) et les intermédiaires actifs (active intermediaries). Ces deux types d'intermédiaires sont décrits dans cette section.
Le fait de relayer des blocs d'en-tête SOAP ciblés sur un noeud intermédiaire SOAP est conditionné par le traitement ou non des blocs d'en-têtes SOAP par ce noeud. Un bloc d'en-tête SOAP est dit à réinsérer si son traitement détermine qu'il doit être réinséré dans le message réacheminé. La spécification d'un bloc d'en-tête SOAP peut demander à réinsérer le bloc dans le message réacheminé si le bloc est ciblé sur un rôle joué par l'intermédiaire SOAP, mais pas s'il est traité autrement par l'intermédiaire. De tels blocs d'en-tête sont dit relayables.
Un bloc d'en-tête SOAP POURRAIT porter un item d'information attribut
relay
(voir 5.2.4 Attribut SOAP relay (relaie)). Lorsque la valeur d'un tel
item d'information attribut est "true", le bloc d'en-tête
est dit relayable. Le réacheminement de blocs d'en-têtes relayables est décrit dans
la section 2.7.2 Intermédiaires de Réacheminement SOAP.
L'item d'information attribut relay
n'a pas d'effet sur les
blocs d'en-têtes ciblés sur un rôle autre que ceux assurés par un intermédiaire SOAP.
L'item d'information attribut relay
n'a pas d'effet sur le
modèle de traitement SOAP lorsque le bloc d'en-tête porte également un
item d'information attribut mustUnderstand
avec la valeur
"true".
L'item d'information attribut relay
n'a pas d'effet sur le
traitement de messages SOAP par le récepteut SOAP final.
Table 3 résume le comportement de réacheminement d'un noeud SOAP.
Rôle | Bloc d'en-tête | ||
---|---|---|---|
Nom abrégé | Assuré | Compris (Understood) & traité | Réacheminé |
next |
Oui | Oui | Non, sauf si réinséré |
Non | Non, sauf si relay ="true" |
||
défini par l'utilisateur | Oui | Oui | Non, sauf si réinséré |
Non | Non, sauf si relay ="true" |
||
Non | n/a | Oui | |
ultimateReceiver |
Oui | Oui | n/a |
Non | n/a | ||
none |
Non | n/a | Oui |
La sémantique d'un ou plusieurs blocs d'en-tête SOAP dans un message SOAP, ou la séquence d'échange de messages SOAP utilisée POURRAIT requérir le réacheminement du message SOAP vers un autre noeud de la part de l'initiateur du message SOAP entrant. Dans ce cas, le noeud SOAP qui le traite remplit le rôle d'un intermédiaire SOAP de réacheminement.
Les intermédiaires de réacheminement DOIVENT traiter le message selon le modèle de traitement défini dans 2.6 Traitement de messages SOAP. De plus, lors de la génération d'un message SOAP à réacheminer , ils DOIVENT :
retirer tous les blocs d'en-tête SOAP traités.
retirer tous les blocs d'en-tête SOAP non-relayables ciblés sur le noeud réacheminant le message mais ignorés lors du traitement.
conserver tous les blocs d'en-tête SOAP relayables ciblés sur le noeud réacheminant le message mais ignorés lors du traitement.
Les intermédiaires de réacheminement DOIVENT aussi obéir à la spécification des caractéristiques SOAP en cours d'utilisation. La spécification de chacune de ces caractéristiques DOIT décrire la sémantique imposée, en incluant les règles décrivant la construction du message réacheminé. Ces règles POURRAIENT décrire où placer des blocs d'en-tête SOAP insérés ou réinsérés. Les blocs d'en-tête SOAP insérés peuvent être indistincts d'un ou plusieurs blocs d'en-tête retirés ci-dessus. La réinsertion de blocs d'en-tête SOAP traités les laisse en place de cette manière, mais insiste sur la nécessité de les traiter à chaque noeud SOAP au long du chemin du message SOAP.
Cette section décrit le comportement des intermédiaires de réacheminement SOAP concernant la conservation de diverses propriétés d'Infoset XML d'un message SOAP relayé.
Sauf indication contraire par le traitement de caractéristiques SOAP sur un intermédiaire (voir 2.7.2 Intermédiaires de Réacheminement SOAP), les règles suivantes s'appliquent :
Toutes les propriétés d'infoset XML d'un message DOIVENT être conservées à l'exception des cas des règles 2 à 22.
L'item d'information élément d'un bloc d'en-tête non ciblé sur un intermédiaire
POURRAIT être retiré, par cet intermédiaire, de la propriété [children] de l'item
d'information élément Header
SOAP, comme précisé dans
2.7.2 Intermédiaires de Réacheminement SOAP.
Les items d'information éléments de blocs d'en-têtes supplémentaires POURRAIENT
être ajoutés à la propriété [children] de l'item d'information élément Header
SOAP,
comme précisé dans 2.7.2 Intermédiaires de Réacheminement SOAP.
Dans ce cas, un item d'information élément Header
POURRAIT être ajouté, comme premier membre de la propriété [children] de
l'item d'information élément Envelope
, s'il n'est pas déjà présent.
Des items d'information caractères d'espace blanc POURRAIENT être retirés de
la propriété [children] de l'item d'information élément Envelope
.
Des items d'information caractères d'espace blanc POURRAIENT être ajoutés à
la propriété [children] de l'item d'information élément Envelope
.
Des items d'information caractères d'espace blanc POURRAIENT être retirés de
la propriété [children] de l'item d'information élément Header
.
Des items d'information caractères d'espace blanc POURRAIENT être ajoutés à
la propriété [children] de l'item d'information élément Header
.
Des items d'information commentaires POURRAIENT être ajoutés à
la propriété [children] de l'item d'information élément Envelope
.
Des items d'information commentaires POURRAIENT être retirés de
la propriété [children] de l'item d'information élément Envelope
.
Des items d'information commentaires POURRAIENT être ajoutés à
la propriété [children] de l'item d'information élément Header
.
Des items d'information commentaires POURRAIENT être retirés de
la propriété [children] de l'item d'information élément Header
.
Des items d'information attributs POURRAIENT être ajoutés à
la propriété [attributes] de l'item d'information élément Envelope
.
Des items d'information attributs POURRAIENT être ajoutés à
la propriété [attributes] de l'item d'information élément Header
.
Des items d'information attributs POURRAIENT être ajoutés à
la propriété [namespace attributes] de l'item d'information élément Envelope
.
Des items d'information attributs POURRAIENT être ajoutés à
la propriété [namespace attributes] de l'item d'information élément Header
.
Les items d'information attributs role
SOAP
présents dans la propriété [attributes] d'items d'information éléments de bloc d'en-tête SOAP
pourraient être transformés comme décrit dans 5.2.2 Attribut SOAP role .
Les items d'information attributs mustUnderstand
SOAP
présents dans la propriété [attributes] d'items d'information éléments de bloc d'en-tête SOAP
pourraient être transformés comme décrit dans 5.2.3 Attribut SOAP mustUnderstand (doitComprendre).
Les items d'information attributs relay
SOAP
présents dans la propriété [attributes] d'items d'information éléments de bloc d'en-tête SOAP
pourraient être transformés comme décrit dans 5.2.4 Attribut SOAP relay (relaie).
La propriété [base URI] d'items d'information éléments POURRAIT être changée ou retirée.
La propriété [character encoding scheme] de l'item d'information document POURRAIT être changée ou retirée.
Tous les items d'information espaces de nommagedans les propriétés [in-scope namespaces] (espaces de nommage à portée) d'items d'information éléments DOIVENT être préservés. Des items d'information espaces de nommage supplémentaires POURRAIENT être ajoutés.
Note:
Les règles ci-dessus premettent de signer les blocs d'en-tête SOAP, le corps SOAP et les combinaisons des blocs d'en-tête SOAP avec le corps SOAP.
En l'absence d'un algorithme de mise sous forme canonique pour normaliser les transformations d'Infoset et si l'algorithme de mise sous forme canonique "http://www.w3.org/TR/2001/REC-xml-c14n-20010315" est utilisé alors les items 1 à 6 et 11 à 14 sont incompatibles avec la signature d'enveloppe SOAP et les items 1,2,5,6,12 et 14 sont incompatibles avec la signature de l'en-tête SOAP.
De même, si l'algorithme de mise sous forme canonique "http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" est utilisé alors les items 7 et 8 sont incompatibles avec la signature de l'enveloppe SOAP et les items 9 et 10 sont incompatibles avec la signature de l'en-tête SOAP.
Note:
Les items d'information caractères d'espace blanc sont ceux dont la propriété [character code] a une valeur de #x20, #x9, #xD ou #xA.
En plus du traitement effectué par des intermédiaires de réacheminement, les intermédiaires actifs entreprennent du traitement supplémentaire pouvant modifier le message sortant selon des manières non décrites dans le message entrant. C'est-à-dire qu'ils peuvent entreprendre un traitement non décrit par un bloc d'en-tête SOAP du message arrivé. L'ensemble potentiel de services fournis par un intermédiaire actif inclut (liste non exhaustive) : des services de sécurité, des services d'annotation et des services de manipulation de contenu.
Il se peut que les résultats de tels traitements actifs aient un impact sur l'interprétation des messages par les noeuds suivants. Par exemple, lors de la génération d'un message sortant, un intermédiaire actif peut avoir retiré et chiffré des ou tous les blocs d'en-tête SOAP trouvés dans le message entrant. Il est fortement recommandé de décrire les caractéristiques fournies par les intermédiaires actifs de manière à permettre la détection de telles modifications par les noeuds SOAP affectés dans le chemin du message.
La version d'un message SOAP est identifiée par le nom XML étendu de
l'item d'information élément fils de l'item
d'information document. Un message SOAP 1.2 possède un
item d'information élément fils de l'item
d'information document avec un nom lacal
Envelope
et un espace de nommage
"http://www.w3.org/2003/05/soap-envelope" (voir
5.1 Enveloppe SOAP).
Un noeud SOAP détermine s'il supporte ou non la version d'un message
SOAP en vérifiant message par message. Dans ce contexte, "supporter"
signifie comprendre la sémantique de cette version d'enveloppe SOAP.
Le modèle de gestion de version s'applique uniquement à l'item
d'information élément Envelope
. Il ne s'occupe pas de
la gestion de version des blocs d'en-tête SOAP, des encodages, des liaisons
sur protocoles, etc.
Un noeud SOAP POURRAIT supporter plusieurs versions d'enveloppe. Cependant, lors du traitement d'un message, un noeud SOAP DOIT utiliser la sémantique définie par la version de ce message.
Si un noeud SOAP reçoit un message dont la version n'est pas
supportée, il DOIT générer une faute (voir 5.4 Faute SOAP)
avec la valeur Value
de Code
fixée à
"env:VersionMismatch" (décalage de version). Toute autre
malformation dans la construction du message DOIT aboutir à la génération
d'une faute avec une valeur Value
de Code
fixée à
"env:Sender" (émetteur).
L'annexe A. Transition de version de SOAP/1.1 à SOAP Version 1.2 définit un mécanisme de
transition de SOAP/1.1 vers SOAP Version 1.2 grâce à l'item
d'information élément Upgrade
(Mise à niveau) (voir
5.4.7 Fautes VersionMismatch (Décalage de Version)).
SOAP donne une structure simple pour les échanges de messages dont la fonctionnalité centrale concerne l'extensibilité. Les mécanismes d'extensibilité décrits ci-après peuvent être utilisés pour ajouter des possibilités d'environnement d'échanges de messages plus riches.
Une caractéristique SOAP est une extension de la structure SOAP pour les messages. Bien que SOAP ne pose aucune contrainte sur la portée de telles caractéristiques, on trouve parmi les exemples "fiabilité", "sécurité", "corrélation", "routage" et des séquences d'échange de messages (Message Exchange Patterns, MEPs) telles que interactions requêtes/réponse, messages unidirectionnels et conversation d'égal à égal.
Le modèle d'extensibilité de SOAP fournit deux mécanismes pour exprimer les caractéristiques : le modèle de traitement SOAP et la structure pour les liaisons sur protocoles (voir 2. Modèle de traitement SOAP et 4. Structure pour une liaison SOAP sur un protocole). Le premier décrit le comportement d'un noeud SOAP pris isolément pour le traitement d'un message SOAP individuel. Le second médiatise l'acte d'émission et de réception de messages SOAP par un noeud SOAP via un protocole sous-jacent.
Le modèle de traitement SOAP permet aux noeuds SOAP qui incluent les mécanismes nécessaire à l'implémentation d'une caractéristique ou plus d'exprimer celles-ci à l'intérieur de l'enveloppe SOAP sous forme de blocs d'en-tête (voir 2.4 Comprendre les en-têtes SOAP). Ces blocs d'en-tête peuvent être destinés à n'importe quel(s) noeud(s) le long du cheminement du message (voir 2.3 Ciblage des blocs d'en-tête SOAP). La combinaison de la syntaxe et de la sémantique de blocs d'en-tête SOAP est appelée module SOAP, et chaque module est spécifié selon les règles de 3.3 Modules SOAP.
En revanche, une liaison SOAP sur un protocole agit entre deux noeuds SOAP adjacents sur un cheminement de message SOAP. Rien n'impose que ce soit le même protocole sous-jacent qui soit utilisé pour tous les bonds sur un chemin SOAP. Dans certains cas, les protocoles sous-jacents sont équipés, soit directement, soit au travers d'extensions, de mécanismes pour des caractéristiques particulières. La structure pour les liaisons SOAP sur protocoles fournit un plan pour décrire ces caractéristiques et comment elles sont reliées aux noeuds SOAP par une spécification de liaison (voir 4. Structure pour une liaison SOAP sur un protocole).
Certaines caractéristiques peuvent nécessiter une sémantique de traitement de "bout en bout" plutôt que de "proche en proche". Si la structure pour liaison sur protocole donne la possibilité d'exprimer des caractéristiques "bout en bout" en dehors de l'enveloppe SOAP, elle ne définit pas de mécanisme spécifique pour le traitement par des intermédiaires des messages résultants. Une spécification de liaison qui exprime ainsi des caractéristiques à l'extérieur de l'enveloppe SOAP nécessite de définir ses propres règles de traitement de ces caractéristiques définies extérieurement. Un noeud SOAP est censé respecter ces règles de traitement (par exemple, décrivant quelle information passe avec le message SOAP sortant de l'intermédiaire). Le traitement d'enveloppes SOAP selon des spécifications de liaisons NE DOIVENT PAS prévaloir sur le modèle de traitement SOAP (voir 2. Modèle de traitement SOAP).
Il est recommandé d'exprimer si possible les caractéristiques de "bout en bout" sous forme de blocs d'en-tête SOAP, de manière à ce que les règles définies dans le modèle de traitement SOAP puissent être employées.
La spécification d'une caractéristique DOIT inclure les choses suivantes :
Une URI utilisée pour désigner la caractéristique. Ceci permet de la référencer sans ambigüité dans des langages de description ou pendant une négociation.
L'information (état) requise à chaque noeud pour implémenter cette caractéristique.
Le traitement requis à chaque noeud pour remplir les obligations de la caractéristique, incluant la gestion de tout échec de communication qui pourrait se produire dans le protocole sous-jacent (voir aussi 4.2 Structure pour une liaison).
L'information à transmettre de noeud en noeud.
Voir 3.2 Séquences d'échange de messages SOAP (Message Exchange Patterns, MEPs) pour les clauses supplémentaires sur les caractéristiques MEP.
Une séquence d'échange de messages (MEP) SOAP est un squelette établissant une forme de base pour échanger des messages entre noeuds SOAP. Les MEPs sont un type de caractéristique et, en l'absence de mention contraire, les références au terme "caractéristique" dans cette spécification s'appliquent également aux MEPs. La séquence d'échange de message de type Requête-Réponse spécifiée dans la partie 2 de SOAP 1.2 [SOAP Partie 2] illustre la spécification d'une caractéristique MEP.
La spécification d'une séquence d'échange de messages DOIT :
comme prescrit par 3.1.1 Obligations pour les caractéristiques, donner une URI pour désigner la MEP.
décrire le cycle de vie d'un échange de message conforme à la séquence.
décrire les relations temporelles/causales, s'il y a lieu, entre messages multiples échangés conformément à la séquence.
décrire la terminaison normale et anormale d'un échange de message conforme à la séquence.
Les spécifications de liaisons sur protocoles sous-jacents peuvent déclarer supporter une ou plusieurs MEPs données.
Les MEPs sont des caractéristiques SOAP, une spécification de MEP DOIT donc se conformer aux obligations des spécifications de caractéristiques SOAP (voir 3.1.1 Obligations pour les caractéristiques). Une spécification de MEP DOIT aussi inclure :
Toute obligation de générer des messages supplémentaires (tels que des réponses aux requêtes dans une MEP requête/réponse).
Des règles pour la livraison ou autre disposition de faute SOAP générée pendant le déroulement de la séquence.
Le terme "module SOAP" se réfère à la spécification de la syntaxe et de la sémantique d'un ou plusieurs blocs d'en-tête SOAP. Un module SOAP réalise zéro ou plus caractéristiques SOAP. Une spécification de module suit les règles ci-après. Elle :
DOIT s'identifier par une URI. Ceci permet de référencer le module sans ambiguïté dans les langages de description ou pendant la négociation.
DOIT déclarer les caractéristiques fournies par un module (voir 3.1 Caractéristiques SOAP).
DOIT clairement et complètement spécifier le contenu et la sémantique des blocs d'en-tête utiliser pour implémenter le comportement en question, en incluant le cas échéant toute modification au modèle de traitement SOAP. Le modèle d'extensibilité de SOAP ne limite pas la portée des extensions de SOAP. Il n'empêche pas non plus les extensions de modifier le modèle de traitement SOAP décrit dans 2. Modèle de traitement SOAP
POURRAIT utiliser les conventions de propriétés définies dans la partie 2 de SOAP 1.2 [SOAP Partie 2], section Une convention pour décrire les caractéristiques et les liaisons , pour décrire les fonctionnalités que le module apporte. Si ces conventions sont suivies, la spécification du module DOIT clairement décrire la relation entre les propriétés abstraites et leur représentation dans l'enveloppe SOAP. Notez qu'il est possible d'écrire une spécification de caractéristique purement en termes de propriétés abstraites, puis d'écrire ensuite une spécification de module séparée pour implémenter cette caractéristique, en établissant une correspondance entre les propriétés définies dans la spécification de la caractéristique et les blocs d'en-tête SOAP du module.
DOIT clairement spécifier toute interaction connue avec le corps SOAP ou tout changement dans son interprétation. De plus, elle DOIT clairement spécifier toute interaction connue avec d'autres caractéristiques ou modules SOAP ou tout changement dans leur interprétation. Par exemple, on peut imaginer un module qui crypte et retire le corps et insère un en-tête contenant une somme de contrôle et une indication du mécanisme de cryptage utilisé. La spécification d'un tel module indiquerait que l'algorithme de décryptage du côté récepteur doit être appliqué avant tout autre module reposant sur le contenu du corps.
SOAP permet l'échange de message SOAP sur une variété de protocoles sous-jacents. L'ensemble formel de règles sur le transport d'un message SOAP à l'intérieur ou au-dessus d'un autre protocole (protocole sous-jacent) pour réaliser un échange est appelé liaison. La structure pour une liaison SOAP sur un protocole donne des règles générales pour spécifier des liaisons sur protocole ; elle décrit également les relations entre liaisons et noeuds SOAP implémentant ces liaisons. La liaison sur HTTP dans la partie 2 de SOAP 1.2 [SOAP Partie 2] est une illustration de spécification d'une liaison. Des liaisons supplémentaires peuvent être créées par des spécifications respectant la structure introduite dans le présent chapitre.
Une spécification de liaison SOAP :
Déclare les caractéristiques supportées par la liaison.
Décrit comment les services du protocole sous-jacent sont utilisés pour transmettre les infosets d'enveloppe SOAP.
Décrit comment les services du protocole sous-jacent sont utilisés pour honorer le contrat représentant les caractéristiques supportées par cette liaison.
Décrit la gestion de tous les échecs potentiels pouvant être anticipée dans la liaison.
Définit les obligations pour construire une implémentation conforme de la liaison spécifiée.
Une liaison ne fournit pas de modèle de traitement séparé et ne constitue pas un noeud SOAP en elle-même. Une liaison SOAP est plutôt une partie intégrante d'un noeud SOAP (voir 2. Modèle de traitement SOAP).
Les objectifs de la structure pour les liaisons sont :
Mettre en place les obligations et concepts communs à toutes les spécifications de liaisons.
Favoriser l'homogénéité des descriptions dans une situation où de multiples liaisons supportent des caractéristiques communes, pour encourager la réutilisation entre les liaisons.
Favoriser la cohérence dans la spécification de caractéristiques optionnelles.
Si on a deux liaisons ou plus, des caractéristiques optionnelles comme la fiabilité de la livraison peuvent être disponibles par des méthodes différentes. Une liaison peut exploiter un protocole sous-jacent qui fournirait directement la caractéristique (par ex. le protocole est fiable) alors qu'une autre peut fournir elle-même la logique nécessaire (par ex. fiabilité assurée par journalisation et retransmission). Dans ce cas, la caractéristique peut être mise à disposition des applications de manière homogène, indépendante de la liaison utilisée.
La création, transmission et le traitement d'un message SOAP, éventuellement au travers d'un ou plusieurs intermédiaires, sont spécifiés en termes de machine à états distribuée. Un état constitue l'information connue d'un noeud SOAP à un instant donné, entre autres le contenu des messages assemblés pour être transmis ou reçus pour être traités. L'état de chaque noeud peut être changé soit suite à un traitement local, soit suite à une information reçue d'un noeud adjacent.
La section 2. Modèle de traitement SOAP de cette spécification décrit le traitement commun à tous les noeuds SOAP à la réception d'un message. Le but d'une spécification de liaison est d'ajouter à ces règles principales de SOAP des traitements supplémentatires spécifiques à la liaison, et de spécifier la manière d'utiliser le protocole sous-jacent pour transmettre des informations entre noeuds successifs du chemin du message.
La machine à états distribuée qui gère la transmission d'un message SOAP donné sur son chemin est la combinaison du traitement SOAP principal (voir 2. Modèle de traitement SOAP) effectué à chaque noeud et des spécifications de liaison reliant chaque paire de noeuds. Une spécification de liaison DOIT permettre une ou plusieurs MEPs.
Dans le cas où plusieurs caractéristiques sont supportées par une spécification de liaison, les spécifications de ces caractéristiques DOIVENT fournir l'information nécessaire pour les utiliser en combinaison avec succès. De même, toute dépendance d'une caractéristique sur une autre (c-a-d si le succès de l'utilisation de l'une dépend de l'utilisation ou non de l'autre) DOIT être spécifiiée. Cette structure pour les liaisons ne donne pas de mécanisme explicite assurant une telle compatibilité entre caractéristiques multiples.
La structure pour les liaisons ne fixe aucune manière de nommer ou typer l'information constituant un état d'un noeud donné. Les spécifications de caractéristiques et de liaisons sont libres d'adopter individuellement leurs propres conventions pour spécifier un état. Notez cependant que la cohérence entre liaisons et caractéristiques est susceptible d'être améliorée dans les cas où plusieurs spécifications de caractéristiques adoptent des conventions cohérentes de représentation d'états. Par exemple, plusieurs caractéristiques peuvent tirer parti d'une spécification cohérente des certificats d'authentification, identifiants de transaction, etc. La liaison sur HTTP dans la partie 2 de SOAP 1.2 [SOAP Partie 2] illustre une telle convention.
Comme décrit dans 5. Construction de message SOAP, chaque message SOAP est spécifié comme un Infoset XML constitué d'un item d'information document avec exactement un fils : l'item d'information élément enveloppe. Par conséquent, la responsabilité minimale d'une liaison dans la transmission d'un message est de spécifier d'une part les manières de transmettre l'Infoset XML du mesage SOAP et de le reconstituer à la réception par un noeud SOAP et d'autre part comment la transmission de l'enveloppe est effectuée grâce aux services du protocole sous-jacent.
La structure pour les liaisons n'oblige pas les liaisons à utiliser la sérialisation XML 1.0 [XML 1.0] comme représentation "sur le fil" de l'Infoset ; des représentations compressées, cryptées, fragmentées, etc. peuvent être utilisées le cas échéant. Une liaison POURRAIT, lorsqu'elle utilise la sérialisation XML 1.0 de l'infoset, obliger à utiliser un encodage ou un ensemble d'encodages de caractères particulier.
Les liaisons POURRAIENT supporter la lecture en flot continu
(streaming) dans le traitement des messages. C'est-à-dire que les noeuds
SOAP POURRAIENT commencer le traitement d'un message SOAP reçu dès que
l'information nécessaire est disponible. Le traitement SOAP est spécifié
en termes d'infosets XML Envelope
XML infosets (voir
5. Construction de message SOAP). Même si les récepteurs SOAP en flot continu
vont obtenir ces infosets XML par incréments, le traitement SOAP DOIT rendre
des résultats identiques à ceux qui seraient produits si l'enveloppe
était disponible en entier avant de commencer le traitement. Par exemple,
comme indiqué en 2.6 Traitement de messages SOAP, l'identification des
blocs d'en-tête ciblés et la vérification de tous les attributs
mustUnderstand
(doitComprendre) doivent être effectuées
pour qu'un traitement réussi puisse commencer.
Selon la représentation utilisée pour l'infoset et l'ordre dans lequel
elle est transmise, cette règle peut limiter le niveau pouvant être
atteint pour le flot continu.
Les liaisons POURRAIENT dépendre de l'état modélisé hors de l'Infoset XML SOAP (par ex. compteurs de tentatives) et POURRAIENT transmettre une telle information aux noeuds adjacents. Par exemple, des liaisons prennent une adresse de livraison de message (typiquement une URI) qui ne se trouve pas dans l'enveloppe.
Un message SOAP est spécifié comme un infoset XML constitué d'un
item d'information document avec exactement un membre
dans sa propriété [children], qui DOIT être l'item d'information
élément Envelope
(voir 5.1 Enveloppe SOAP).
Cet item d'information élément est aussi la valeur de la
propriété [document element]. Les propriétes [notations] et
[unparsed entities] sont toutes deux vides. Les propriétés [base URI],
[character encoding scheme] et [version] peuvent avoir n'importe quelle
valeur légale. La propriété [standalone] a soit une valeur
"yes" (oui), soit pas de valeur.
L'infoset XML d'un message SOAP NE DOIT PAS contenir d'item d'information de déclaration de type de document.
Les messages SOAP envoyés par les émetteurs initiaux SOAP
NE DOIVENT PAS contenir d'item d'information
instruction de traitement (processing instruction information item).
Les intermédiaires SOAP NE DOIVENT PAS insérer d'item d'information
instruction de traitement dans les messages SOAP relayés. Les récepteurs
SOAP recevant un message SOAP contenant un item d'information
instruction de traitement DEVRAIENT générer une faute SOAP avec la
valeur Value
de Code
fixée à "env:Sender".
Cependant, dans le cas où des considérations de performance rendent peu
pratique la détection par un intermédiaire d'item d'information
instruction de traitement dans un messages SOAP à relayer, l'intermédiaire
POURRAIT laisser un tel item d'information instruction de traitement
dans le message relayé.
Les items d'information éléments définis dans cette spécification qui ne peuvent avoir que des items d'information éléments définis comme membres permis de leur propriété [children] peuvent avoir zéro ou plus items d'information caractères fils dont le code de caractère figure parmi les caractères d'espace blanc définis par XML 1.0 [XML 1.0]. Sauf indication contraire, ces items d'information caractères sont considérés non significatifs.
Des items d'information commentaires POURRAIENT apparaître comme fils et/ou descendants de l'item d'information élément [document element] mais pas avant ou après cet item d'information élément. Il existe des restrictions dans le modèle de traitement par rapport au moment où des items d'information commentaires peuvent être ajoutés et/ou retirés (voir 2.7.3 Infoset relayé).
L'item d'information élément Envelope
a :
Pour [local name] Envelope
.
Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".
Zéro ou plus items d'information attributs, qualifiés par un espace de nommage, dans sa propriété [attributes].
Un ou deux items d'information éléments dans sa propriété [children] dans l'ordre suivant :
Un item d'information élément optionnel
Header
(en-tête) (voir 5.2 En-tête SOAP).
Un item d'information élément obligatoire
Body
(corps) (voir 5.3 Corps SOAP).
L'item d'information attribut encodingStyle
indique les règles d'encodage utilisées pour sérialiser des parties
d'un message SOAP.
L'item d'information attribut encodingStyle
a :
Pour [local name] encodingStyle
.
Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".
L'item d'information attribut encodingStyle
est de type xs:anyURI. Sa valeur identifie un ensemble de règles
de sérialisation utilisables pour désérialiser le message SOAP.
L'item d'information attribut encodingStyle
POURRAIT apparaître seulement dans :
Un bloc d'en-tête SOAP (voir 5.2.1 Bloc d'en-tête SOAP).
Un item d'information élément fils de
l'item d'information élément SOAP Body
(corps)
(voir 5.3.1 Élément fils d'un corps SOAP).
Un item d'information élément fils de
l'item d'information élément SOAP Detail
(voir 5.4.5.1 Entrée de détail SOAP).
Tout descendant de 1, 2 et 3 ci-dessus.
L'item d'information attribut encodingStyle
NE DOIT PAS apparaître sur tout élément autre que ceux-ci désignés ci-dessus
dans l'Infoset d'un message SOAP.
La portée de l'item d'information attribut
encodingStyle
est celle de son item d'information
élément propriétaire et des descendants de cet item
d'information élément, à moins qu'un descendant ne porte lui-même
un tel item d'information attribut encodingStyle
.
Si aucun item d'information attribut encodingStyle
n'a de portée sur un item d'information élément particulier
ou si la valeur de cet item d'information attribut est l'URI
de longueur zéro alors aucune déclaration n'existe concernant le style
d'encodage de cet item d'information élément et de ses
descendants.
encodingStyle
."http://www.w3.org/2003/05/soap-encoding" "http://example.org/encoding/" "http://www.w3.org/2003/05/soap-envelope/encoding/none"
L'item d'information élément Header
(en-tête)
fournit un mécanisme d'extension de message SOAP de manière décentralisée
et modulaire (voir 3. Modèle d'extensibilité de SOAP et
2.4 Comprendre les en-têtes SOAP).
L'item d'information élément Header
a :
Pour [local name] Header
.
Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".
Zéro ou plus items d'information attributs, qualifiés par un espace de nommage, dans sa propriété [attributes].
Zéro ou plus items d'information éléments, qualifiés par un espace de nommage, dans sa propriété [children].
Chaque item d'information élément fils de l'en-tête SOAP est appelé bloc d'en-tête SOAP.
Chaque item d'information élément bloc d'en-tête SOAP :
DOIT avoir une propriété [namespace name] avec une valeur, c'est-à-dire DOIT être qualifié par un espace de nommage.
POURRAIT avoir un nombre quelconque d'items d'information caractères fils. Les items d'information caractères fils dont le code de caractère figure parmi les caractères d'espace blanc définis par XML 1.0 [XML 1.0] sont considérés significatifs.
POURRAIT avoir un nombre quelconque d'items d'information éléments fils. Ces items d'information éléments POURRAIENT être qualifiés par un espace de nommage.
POURRAIT avoir zéro ou plus items d'information attributs dans sa propriété [attributes]. POURRAIENT y figurer sans contrainte d'exclusion ceux décrits ci-dessous, qui ont des significations particulières pour le traitement SOAP :
item d'information attribut
encodingStyle
(voir 5.1.1 Attribut SOAP encodingStyle (style d'encodage)).
item d'information attribut
role
(voir 5.2.2 Attribut SOAP role ).
item d'information attribut
mustUnderstand
(voir 5.2.3 Attribut SOAP mustUnderstand (doitComprendre)).
item d'information attribut
relay
(voir 5.2.4 Attribut SOAP relay (relaie)).
<env:Header xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <t:Transaction xmlns:t="http://example.org/2001/06/tx" env:mustUnderstand="true" > 5 </t:Transaction> </env:Header>
Un rôle SOAP sert à indiquer le noeud SOAP auquel un bloc d'en-tête SOAP particulier est destiné (voir 2.2 Rôles SOAP et noeuds SOAP).
L'item d'information attribut role
possède
les propriétés d'infoset XML suivantes :
Le [local name] role
.
Le [namespace name] "http://www.w3.org/2003/05/soap-envelope".
Une propriété [specified] avec la valeur "true".
Le type de l'item d'information attribut
role
est anyURI.
La valeur de l'item d'information attribut role
est une URI qui
dénomme un rôle qu'un noeud SOAP peut remplir.
L'absence d'item d'information attribut
role
équivaut à la présence de cet attribut avec la valeur
"http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver".
Les émetteurs SOAP NE DEVRAIENT PAS le générer, mais les
récepteurs SOAP DOIVENT accepter l'item d'information attribut
role
avec une valeur "http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver" .
S'il relaie un message SOAP, un intermédiaire SOAP POURRAIT se défausser
de l'item d'information attribut role
si la valeur de celui-ci est "http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver" (voir 2.7 Relais de messages SOAP).
Un émetteur d'un message SOAP ne DEVRAIT
utiliser l'item d'information attribut role
que dans des blocs d'en-tête SOAP. Un récepteur
SOAP DOIT ignorer cet item d'information attribut s'il apparaît
dans un descendant d'un bloc d'en-tête SOAP ou dans un item
d'information élément fils du corps SOAP (ou un descendant de ce
fils).
L'item d'information attribut mustUnderstand
(doitComprendre) est utilisé pour indiquer si le traitement d'un bloc
d'en-tête SOAP est obligatoire ou optionnel (voir 2.4 Comprendre les en-têtes SOAP)
L'item d'information attribut mustUnderstand
a les propriétés d'infoset XML suivantes :
Le [local name] mustUnderstand
.
Le [namespace name] "http://www.w3.org/2003/05/soap-envelope".
Une propriété [specified] avec une valeur "true" (vrai).
Le type de l'item d'information attribut
mustUnderstand
est xs:boolean (booléen).
L'absence de cet item d'information attribut est définie comme sémantiquement équivalente à l'inclure avec la valeur "false" ou "0".
Les émetteurs SOAP NE DEVRAIENT PAS le générer, mais les
récepteurs SOAP DOIVENT accepter l'item d'information attribut
mustUnderstand
avec une valeur "false" ou
"0" .
S'il génère un item d'information attribut SOAP
mustUnderstand
, un émetteur SOAP DEVRAIT utiliser la
représentation canonique "true" (vrai) de la valeur de
l'attribut (voir XML Schema [XML Schema Partie 2]). Un récepteur SOAP DOIT
accepter toute représentation lexicale valide de la valeur de l'attribut.
S'il relaie le message, un intermédiaire SOAP POURRAIT substituer
la valeur "true" (vrai) à la valeur "1" ou
"false" (faux) à la valeur "0". L'
item d'information attribut mustUnderstand
POURRAIT être omis si sa valeur était "false"
(voir 2.7 Relais de messages SOAP).
Un émetteur d'un message SOAP ne DEVRAIT
utiliser l'item d'information attribut mustUnderstand
que dans des blocs d'en-tête SOAP. Un récepteur
SOAP DOIT ignorer cet item d'information attribut s'il apparaît
dans un descendant d'un bloc d'en-tête SOAP ou dans un item
d'information élément fils du corps SOAP (ou un descendant de ce
fils).
L'item d'information attribut relay
(relaie) est utilisé pour indiquer si un bloc d'en-tête SOAP ciblé sur un
récepteur SOAP doit être relayé (réacheminé) s'il n'est pas traité (voir 2.7.1 Relais de blocs d'en-tête SOAP)
L'item d'information attribut relay
a les propriétés d'infoset XML suivantes :
Le [local name] relay
.
Le [namespace name] "http://www.w3.org/2003/05/soap-envelope".
Une propriété [specified] avec une valeur "true" (vrai).
Le type de l'item d'information attribut
relay
est xs:boolean (booléen).
L'absence de cet item d'information attribut est définie comme sémantiquement équivalente à l'inclure avec la valeur "false" ou "0".
Les émetteurs SOAP NE DEVRAIENT PAS le générer, mais les
récepteurs SOAP DOIVENT accepter l'item d'information attribut
relay
avec une valeur "false" ou "0".
S'il génère un item d'information attribut SOAP
relay
, un émetteur SOAP DEVRAIT utiliser la
représentation canonique "true" (vrai) de la valeur de
l'attribut (voir XML Schema [XML Schema Partie 2]). Un récepteur SOAP DOIT
accepter toute représentation lexicale valide de la valeur de l'attribut.
S'il relaie le message, un intermédiaire SOAP POURRAIT substituer
la valeur "true" (vrai) à la valeur "1" ou
"false" (faux) à la valeur "0". L'
item d'information attribut relay
POURRAIT être omis si sa valeur était "false"
(voir 2.7 Relais de messages SOAP).
Un émetteur d'un message SOAP ne DEVRAIT
utiliser l'item d'information attribut relay
que dans des blocs d'en-tête SOAP. Un récepteur
SOAP DOIT ignorer cet item d'information attribut s'il apparaît
dans un descendant d'un bloc d'en-tête SOAP ou dans un item
d'information élément fils du corps SOAP (ou un descendant de ce
fils).
Un corps SOAP fournit un mécanisme de transmission d'information vers un récepteur SOAP final (voir 2.5 Structure et interprétation de corps SOAP).
L'item d'information élément Body
a :
Pour [local name] Body
(corps).
Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".
Zéro ou plus items d'information attributs qualifiés par un espace de nommage dans sa propriété [attributes].
Zéro ou plus items d'information éléments qualifiés par un espace de nommage dans sa propriété [children].
Tous les items d'information éléments fils de
l'item d'information élément SOAP Body
:
DEVRAIENT avoir une propriété [namespace name] avec une valeur, c'est-à-dire que le nom de l'élément DEVRAIT être qualifié par un espace de nommage.
Note:
Les éléments qualifiés par un espace de nommage ont tendance à produire des messages dont l'interprétation est moins ambiguë que ceux comportant des éléments non qualifiés. L'utilisation d'éléments non qualifiés est par conséquent déconseillée.
POURRAIENT avoir un nombre quelconque d'items d'information caractères fils. Les items d'information caractères fils dont le code de caractère figure parmi les caractères d'espace blanc définis par XML 1.0 [XML 1.0] sont considérés significatifs.
POURRAIENT avoir un nombre quelconque d'items d'information éléments fils. Ces items d'information éléments POURRAIENT être qualifiés par un espace de nommage.
POURRAIENT avoir zéro ou plus items d'information attributs dans sa propriété [attributes]. Parmi ceux-ci POURRAIT figurer, avec une signification particulière pour le traitement SOAP :
item d'information attribut
encodingStyle
(voir 5.1.1 Attribut SOAP encodingStyle (style d'encodage)).
SOAP définit un fils direct du corps SOAP particulier, la faute SOAP, qui sert à rapporter les erreurs (voir 5.4 Faute SOAP).
Une faute SOAP est utilisée pour transporter de l'information d'erreur dans un message SOAP.
L'item d'information élément Fault
(faute) a :
Pour [local name] Fault
.
Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".
Deux items d'information éléments fils ou plus dans sa propriété [children], dans l'ordre suivant :
Un item d'information élément obligatoire
Code
(voir 5.4.1 Élément SOAP Code).
Un item d'information élément obligatoire
Reason
(raison) (voir 5.4.2 Élément SOAP Reason (raison)).
Un item d'information élément optionnel
Node
(noeud) (voir 5.4.3 Élément SOAP Node (noeud)).
Un item d'information élément optionnel
Role
(voir 5.4.4 Élément SOAP Role).
Un item d'information élément optionnel
Detail
(voir 5.4.5 Élement SOAP Detail).
Pour être reconnu comme transportant une information d'erreur SOAP,
un message SOAP DOIT contenir un seul item d'information élément
Fault
comme seul fils du Body
(corps) SOAP.
Quand ils génèrent une faute, les émetteurs SOAP NE DOIVENT PAS
inclure d'items d'information éléments supplémentaires dans
le Body
(corps) SOAP. Un message dont le Body
contient
une Fault
(faute) plus des items d'information éléments
n'a pas de sémantique définie dans SOAP.
Un item d'information élément Fault
(faute)
POURRAIT apparaître dans un bloc d'en-tête SOAP ou comme descendant d'un
item d'information élément fils du Body
(corps) SOAP
; dans ces cas, l'élément n'a pas de sémantique définie dans SOAP.
L'item d'information élément Code
a :
Pour [local name] Code
.
Pour [namespace name] http://www.w3.org/2003/05/soap-envelope
.
Un ou deux items d'information éléments dans sa propriété [children], dans l'ordre suivant :
Un item d'information élément obligatoire
Value
(valeur) tel que décrit plus loin (voir 5.4.1.1 Élément SOAP Value (avec un parent Code))
Un item d'information élément optionnel
Subcode
(sous-code) tel que décrit plus loin (see 5.4.1.2 Élément SOAP Subcode (sous-code)).
L'item d'information élément Value
(valeur)
a :
Pour [local name] Value
.
Pour [namespace name] http://www.w3.org/2003/05/soap-envelope
.
Le type de l'item d'information élément
Value
est env:faultCodeEnum (énuméré de codes de faute).
SOAP définit un petit ensemble de codes de faute couvrant les fautes SOAP
de haut niveau (voir 5.4.6 Codes de faute SOAP).
L'item d'information élément Subcode
(sous-code) a :
Pour [local name] Subcode
.
Pour [namespace name] http://www.w3.org/2003/05/soap-envelope
.
Un ou deux items d'information éléments fils dans sa propriété [children], dans l'ordre suivant :
Un item d'information élément obligatoire
Value
(valeur) tel que décrit plus loin (voir 5.4.1.3 Élément SOAP Value (avec un parent Subcode)).
Un item d'information élément optionnel
Subcode
(sous-code) (voir 5.4.1.2 Élément SOAP Subcode (sous-code)).
L'item d'information élément Value
(valeur)
a :
Pour [local name] Value
.
Pour [namespace name] http://www.w3.org/2003/05/soap-envelope
.
Le type de l'item d'information élément
Value
est xs:QName.
La valeur de cet élément est une sous-catégorie, définie par l'application,
de la valeur de l'item d'information élément Value
fils de l'item d'information élément parent de l'item
d'information élément Subcode
(voir
5.4.6 Codes de faute SOAP).
L'item d'information élément Reason
(raison)
est destiné à fournir une explication de la faute lisible par un humain.
L'item d'information élément Reason
(raison)
a :
Pour [local name] Reason
.
Pour [namespace name] http://www.w3.org/2003/05/soap-envelope
.
Un item d'information élément Text
(texte)
fils (voir 5.4.2.1 Élément SOAP Text (texte)).
Chaque item d'information élément Text
fils
DEVRAIT avoir une valeur différente pour son item d'information attribut
xml:lang
.
Le type de l'item d'information élément Reason
est env:faultreason (raison de faute).
L'item d'information élément Text
est destiné à véhiculer le texte d'une explication de la faute lisible par un humain.
L'item d'information élément Text
a :
Pour [local name] Text
.
Pour [namespace name] http://www.w3.org/2003/05/soap-envelope
.
Un item d'information attribut optionnel avec
pour [local name] lang
et pour [namespace name]
"http://www.w3.org/XML/1998/namespace".
Notez que la définition de l'item d'information attribut lang
requiert que le [prefix] soit "xml" ou toute capitalisation de celui-ci (voir
[XML 1.0], Language Identification).
Un nombre quelconque d'items d'information caractères fils. Les items d'information caractères dont le code de caractère figure parmi les caractères d'espace blanc définis par XML 1.0 [XML 1.0] sont considérés significatifs.
Le type de l'item d'information élément Text
est env:reasontext.
Cet item d'information élément est similaire à la 'Reason-Phrase' définie par HTTP [RFC 2616] et DEVRAIT fournir des informations expliquant la nature de la faute. Il n'est pas destiné à un traitement algorithmique.
L'item d'information élément Node
est destiné
à fournir des informations sur quel noeud SOAP du cheminement du message
a causé l'apparition de la faute (voir 2. Modèle de traitement SOAP).
L'item d'information élément Node
a :
Pour [local name] Node
.
Pour [namespace name] http://www.w3.org/2003/05/soap-envelope
.
Le type de l'item d'information élément Node
est xs:anyURI (uneURI).
Comme décrit dans la section 2.1 Noeuds SOAP, chaque noeud
SOAP est identifié par une URI. La valeur de l'item d'information
élément Node
est l'URI qui identifie le noeud SOAP qui
a généré la faute. Les noeuds SOAP qui ne jouent pas le rôle de récepteur
SOAP final DOIVENT inclure cet item d'information élément
pour indiquer explicitement qu'il a généré la faute. Un récepteur SOAP
final POURRAIT inclure cet item d'information élément pour
indiquer explcititement qu'il a généré la faute.
L'item d'information élément Role
identifie le rôle joué par le noeud au moment de la faute.
L'item d'information élément Role
a :
Pour [local name] Role
.
Pour [namespace name] http://www.w3.org/2003/05/soap-envelope
.
Le type de l'item d'information élément Role
est xs:anyURI (uneURI).
La valeur de l'item d'information élément Role
DOIT être l'un des rôles assurés par le noeud lors du traitement du message
(voir 2.2 Rôles SOAP et noeuds SOAP).
L'item d'information élément Detail
est
destiné à transporter des informations d'erreur spécifiques à
l'application relatives au Body
(corps) SOAP.
L'item d'information élément Detail
a :
Pour [local name] Detail
.
Pour [namespace name] http://www.w3.org/2003/05/soap-envelope
.
Zéro ou plus items d'information attributs dans sa propriété [attributes].
Zéro ou plus items d'information éléments fils dans sa propriété [children].
L'item d'information élément Detail
POURRAIT
avoir un nombre quelconque d'items d'information caractères
fils. Les items d'information caractères dont le code
de caractère figure parmi les caractères d'espace blanc définis par XML 1.0
[XML 1.0] sont considérés significatifs.
L'item d'information élément Detail
POURRAIT
être présent dans une faute SOAP, auquel cas il transporte des informations
supplémentaires relatives au code de faute SOAP décrivant la faute (voir
5.4.6 Codes de faute SOAP). Par exemple, l'item d'information
élément Detail
peut contenir des informations sur un
message ne contenant pas les références appropriées, un dépassement de
temps, etc. La présence de l'item d'information élément
Detail
n'a pas de signification quant aux parties du message fautif
qui ont été traitées.
Tous les item d'information éléments fils de
l'item d'information élément Detail
sont appelés
entrées de détail (voir 5.4.5.1 Entrée de détail SOAP).
Chaque entrée de détail :
POURRAIT être qualifiée par un espace de nommage.
POURRAIT avoir un nombre quelconque d'items d'information éléments fils.
POURRAIT avoir un nombre quelconque d'items d'information caractères fils. Les items d'information caractères dont le code de caractère figure parmi les caractères d'espace blanc définis par XML 1.0 [XML 1.0] sont considérés significatif.
POURRAIT avoir zéro ou plus item d'information attribut dans sa propriété [attributes]. POURRAIENT y figurer ceux-ci, qui ont une signification particulière pour le traitement SOAP :
item d'information attribut encodingStyle
(voir 5.1.1 Attribut SOAP encodingStyle (style d'encodage)).
S'il est présent, l'item d'information attribut
encodingStyle
indique le style d'encodage utilisé pour
l'entrée de détail (voir 5.1.1 Attribut SOAP encodingStyle (style d'encodage)).
Les codes de faute SOAP sont des noms XML étendus et sont destinés à fournir un mécanisme pour classer les fautes. Une liste hiérarchique de codes SOAP et les informations associées est incluse dans chaque message de faute SOAP, chaque code identifiant la catégorie de la faute à un niveau de détail croissant.
Les valeurs de l'item d'information élément
Value
fils de l'item d'information élément
Code
sont restreintes à celles définies par le type
"env:faultCodeEnum" (voir Table 4).
Des sous-codes supplémentaires POURRAIENT être créés à l'usage
d'applications ou de caractéristiques. De tels sous-codes sont transportés
dans l' item d'information élément Value
fils de
l'item d'information élément Subcode
.
Les codes de faute SOAP sont à interpréter comme modifieurs
du contenu de l'item d'information élément Detail
dans la mesure où ils fournissent le contexte de l'item d'information
élément Detail
. Un noeud SOAP DOIT comprendre tous les
codes de faute SOAP dans un message de faute SOAP pour être capable
d'interpréter l'item d'information élément Detail
d'une faute SOAP.
Detail
est à interpréter dans le contexte des codes
de faute "env:Sender" et "m:MessageTimeout".<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.example.org/timeouts" xmlns:xml="http://www.w3.org/XML/1998/namespace"> <env:Body> <env:Fault> <env:Code> <env:Value>env:Sender</env:Value> <env:Subcode> <env:Value>m:MessageTimeout</env:Value> </env:Subcode> </env:Code> <env:Reason> <env:Text xml:lang="en">Sender Timeout</env:Text> </env:Reason> <env:Detail> <m:MaxTime>P5M</m:MaxTime> </env:Detail> </env:Fault> </env:Body> </env:Envelope>
Cette spécification ne définit pas de limite sur le nombre d'
items d'informations éléments Subcode
qu'une faute SOAP
peut contenir. Cependant, bien que ce ne soit pas requis dans cette
spécification, on peut penser qu'en pratique la plupart des cas seront
supportés avec relativement peu d'items d'informations
éléments Subcode
.
Nom Local | Signification |
---|---|
VersionMismatch (décalage de version) | Le noeud en faute a trouvé un item d'information
élément invalide au lieu de l'item d'information
élément Envelope . L'espace de nommage, le nom local, ou
les deux, ne correspondent pas à l'item d'information
élément Envelope requis par cette spécification (voir
2.8 Modèle de gestion de version SOAP et 5.4.7 Fautes VersionMismatch (Décalage de Version)) |
MustUnderstand (doitComprendre) | Un item d'information élément fils immédiat
de l'item d'information élément SOAP Header qui n'a
pas été compris ou obéi par le noeud en faute contient un item
d'information attribut mustUnderstand avec la valeur
"true" (voir
5.2.3 Attribut SOAP mustUnderstand (doitComprendre) et 5.4.8 Fautes SOAP mustUnderstand (doitComprendre)) |
DataEncodingUnknown (Encodage de données inconnu) | Un en-tête ou corps destiné au noeud SOAP en faute est sous la portée d'un encodage de données (voir 5.1.1 Attribut SOAP encodingStyle (style d'encodage)) que le noeud en faute ne supporte pas. |
Sender (Émetteur) | Le message était malformé ou ne contenait pas les
informations appropriées pour réussir. Par exemple, il pourrait manquer
au message une information d'authentification ou de paiement. C'est
généralement une indication que le message ne doit pas être renvoyé sans
modifications (voir aussi 5.4 Faute SOAP pour une description
du sous-élément de faute SOAP detail ).
|
Receiver (Récepteur) | Le message n'a pas pu être traité pour des raisons
imputables au traitement du message plutôt qu'un contenu du message
lui-même. Par exemple, le traitement a pu inclure une communication
avec un noeud SOAP en amont qui n'a pas répondu. Le traitement pourrait
réussir plus tard si le message était renvoyé (voir aussi
5.4 Faute SOAP pour une description du sous-élément de
faute SOAP detail ).
|
Lorsqu'un noeud SOAP génère une faute avec un Value
du Code
fixée à "env:VersionMismatch", il
DEVRAIT fournir un bloc d'en-tête Upgrade
dans le message de faute
généré. Le bloc d'en-tête Upgrade
, comme décrit plus bas, détaille
les noms qualifiés XML (d'après XML Schema: Datatypes
[XML Schema Partie 2]) des enveloppes SOAP supportées par le noeud
SOAP (voir 2.8 Modèle de gestion de version SOAP).
Le bloc d'en-tête Upgrade
est constitué d'un
item d'information élément Upgrade
contenant une
liste ordonnée de noms qualifiés en XML d'enveloppes SOAP que le noeud supporte,
du plus au moins préférable.
L'item d'information élément Upgrade
a :
Pour [local name] Upgrade
.
Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".
Un ou plusieurs items d'information éléments
envelope
dans sa propriété [children] parmi 5.4.7.2 Élément SOAP SupportedEnvelope (EnveloppeSupportée).
L'item d'information élément Upgrade
NE DOIT PAS
avoir d'item d'information attribut encodingStyle
.
L'item d'information élément SupportedEnvelope
a :
Pour [local name] SupportedEnvelope
.
Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".
Un item d'information attribut qname
dans
sa propriété [attributes] comme décrit dans 5.4.7.3 Attribut SOAP qname.
L'item d'information attribut qname
a les propriétés
d'Infoset XML suivantes :
Le [local name] qname
.
Un [namespace name] qui n'a pas de valeur.
Une propriété [specified] avec la valeur "true" (vrai).
Le type de l'item d'information attribut qname
est
xs:QName. Sa valeur est le nom qualifié en XML d'un
item d'information élément Envelope
que le noeud fautif
peut comprendre.
Note:
Lors de la sérialisation de l'item d'information attribut
qname
il est nécessaire d'avoir une déclaration d'espace de nommage à
portée pour le nom d'espace de nommage (namespace name) de l'
item d'information élément Envelope
que le noeud fautif
peut comprendre. La valeur de l'item d'information attribut utilise le
préfixe de cette déclaration d'espace de nommage.
L'exemple suivant illustre le cas d'un noeud SOAP supportant aussi
bien SOAP en version 1.2 que SOAP/1.1 mais avec une préférence pour la
version 1.2 de SOAP (voir annexe A. Transition de version de SOAP/1.1 à SOAP Version 1.2 pour un mécanisme
de transition de SOAP/1.1 à SOAP Version 1.2). Ceci est indiqué par un
bloc d'en-tête Upgrade
avec deux items d'information
élément envelope
, le premier contenant le nom local et le
nom d'espace de nommage de l'item d'information élément
Envelope
de SOAP Version 1.2, le second le nom local et le
nom d'espace de nommage de l'élément Envelope
de SOAP/1.1.
Upgrade
indiquant que
SOAP Version 1.2 et SOAP/1.1 sont tous deux supportés mais avec une
préférence pour SOAP Version 1.2.<?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> xmlns:xml="http://www.w3.org/XML/1998/namespace"> <env:Header> <env:Upgrade> <SupportedEnvelope qname="ns1:Envelope" xmlns:ns1="http://www.w3.org/2003/05/soap-envelope"/> <SupportedEnvelope qname="ns2:Envelope" xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/> </env:Upgrade> </env:Header> <env:Body> <env:Fault> <env:Code><env:Value>env:VersionMismatch</env:Value></env:Code> <env:Reason> <env:Text xml:lang="en">Version Mismatch</env:Text> </env:Reason> </env:Fault> </env:Body> </env:Envelope>
Lorsqu'un noeud SOAP génère une faute avec une valeur Value
du Code
fixée à "env:MustUnderstand", il
DEVRAIT fournir un bloc d'en-tête NotUnderstood
dans le message
de faute généré. Le bloc d'en-tête NotUnderstood
, comme décrit plus bas,
détaille les noms qualifiés XML (d'après XML Schema: Datatypes
[XML Schema Partie 2]) du ou des bloc(s) d'en-tête particulier(s)
qui n'ont pas été compris.
Un noeud SOAP POURRAIT générer une faute SOAP dès qu'un ou plusieurs bloc(s) d'en-tête SOAP n'a(ont) pas été compris dans un message SOAP. Il n'est PAS une obligatoire que la faute contiennent les noms qualifiés en XML de TOUS ces blocs d'en-tête.
Chaque item d'information élément bloc
d'en-tête NotUnderstood
a :
Pour [local name] NotUnderstood
.
Pour [namespace name] "http://www.w3.org/2003/05/soap-envelope".
Un item d'information attribut
qname
dans sa propriété [attributes], tel que décrit
dans 5.4.8.2 Attribut SOAP qname.
L'item d'information élément NotUnderstood
NE DOIT PAS
avoir d'item d'information attribut encodingStyle
.
L'item d'information attribut qname
a les
propriétés d'infoset XML suivantes :
Pour [local name] qname
.
Un [namespace name] sans valeur.
Une propriété [specified] avec la valeur "true".
Le type de l'item d'information attribut
qname
est xs:qname Sa valeur est le
nom qualifié XML d'un bloc d'en-tête que le noeud en faute n'a pas réussi
à comprendre.
Note:
Lors de la sérialisation de l'item d'information attribut
qname
il est nécessaire d'avoir une déclaration d'espace de nommage à
portée pour le nom d'espace de nommage (namespace name) du bloc d'en-tête SOAP
qui n'a pas été compris et la valeur de l'item d'information attribut utilise le
préfixe de cette déclaration d'espace de nommage. Le préfixe utilise n'est pas nécessairement
le même que celui utilisé dans le message non comris.
Observez le message suivant :
Extension1
ou
Extension2
ne sont pas compris<?xml version="1.0" ?> <env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope'> <env:Header> <abc:Extension1 xmlns:abc='http://example.org/2001/06/ext' env:mustUnderstand='true'/> <def:Extension2 xmlns:def='http://example.com/stuff' env:mustUnderstand='true' /> </env:Header> <env:Body> . . . </env:Body> </env:Envelope>
Le message de l'exemple ci-dessus va aboutir au message de faute
montré dans l'exemple ci-dessous si le récepteur final du message initial ne
comprend pas les deux éléments d'en-tête abc:Extension1
et
def:Extension2
.
Extension1
et Extension2
<?xml version="1.0" ?> <env:Envelope xmlns:env='http://www.w3.org/2003/05/soap-envelope' xmlns:xml='http://www.w3.org/XML/1998/namespace'> <env:Header> <env:NotUnderstood qname='abc:Extension1' xmlns:abc='http://example.org/2001/06/ext' /> <env:NotUnderstood qname='def:Extension2' xmlns:def='http://example.com/stuff' /> </env:Header> <env:Body> <env:Fault> <env:Code><env:Value>env:MustUnderstand</env:Value></env:Code> <env:Reason> <env:Text xml:lang='en'>One or more mandatory SOAP header blocks not understood </env:Text> </env:Reason> </env:Fault> </env:Body> </env:Envelope>
SOAP utilise des URIs pour certains identifiants, entre autres les
valeurs des items d'information attributs
encodingStyle
(voir 5.1.1 Attribut SOAP encodingStyle (style d'encodage))
et role
(voir 5.2.2 Attribut SOAP role ).
Pour SOAP, une URI est simplement une chaîne formatée qui identifie une
ressource web par son nom, lieu, ou toute autre caractéristique.
Bien que cette section s'applique seulement aux URIs directement utilisées par les items d'information définis par cette spécification, il est RECOMMANDÉ que les données définies par une application transportées dans une enveloppe SOAP utilisent les mêmes mécanismes et guides définis ici pour gérer les URIs.
Les URIs utilisées comme valeurs dans les items d'information identifiés par les espaces de nommage XML "http://www.w3.org/2003/05/soap-envelope" et "http://www.w3.org/2003/05/soap-encoding" peuvent être soit relatives soit absolues.
SOAP ne définit pas d'URI de base mais repose sur les mécanismes définis dans XML Base [XML Base] et la RFC 2396 [RFC 2396] pour établir une URI de base sur laquelle les URIs relatives peuvent être rendues absolues.
Le protocole sous-jacent POURRAIT définir une URI de base qui puisse agir comme URI de base pour l'enveloppe SOAP (voir 4. Structure pour une liaison SOAP sur un protocole et dans la partie 2 de SOAP 1.2 [SOAP Partie 2] la section HTTP binding -- liaison HTTP).
SOAP ne définit aucune équivalence pour les URIs en général puisque celles-ci sont définis par les schémas individuels des URI et par la RFC 2396 [RFC 2396]. Cependant, en raison d'incohérences sur les règles d'équivalence d'URI dans beaucoup d'analyseurs d'URIs actuels, il est RECOMMANDÉ que les émetteurs SOAP ne reposent pas sur des règles d'équivalence spéciales dans les récepteurs SOAP pour déterminer une équivalence entre valeurs d'URI utilisées dans un message SOAP.
L'utilisation d'adresses IP dans les URIs DEVRAIT être évitée autant que possible (voir la RFC 1900 [RFC 1900]). Cependant, si c'est le cas, le format littéral pour les adresses IPv6 dans les URIs, tel que décrit par la RFC 2732 [RFC 2732], DEVRAIT être supporté.
SOAP ne place pas a priori de limite sur la longueur d'une URI. Tout noeud SOAP DOIT être capable de gérer la longueur de toute URI qu'il publie et les émetteurs aussi bien que les récepteurs SOAP DEVRAIENT être capables de manipuler des URIs d'au moins 2048 caractères de long.
La structure pour l'échange de messages SOAP ne fournit pas directement de mécanismes pour traiter du contrôle d'accès, de la confidentialité, de l'intégrité et de la non répudiation. De tels mécanismes peuvent être fournis sous forme d'extensions SOAP grâce au modèle d'extensibilité (voir 3. Modèle d'extensibilité de SOAP). Cette section décrit les considérations de sécurité que les concepteurs et implémenteurs ont besoin de prendre en compte pour concevoir et utiliser ces mécanismes.
Les implémenteurs SOAP se doivent d'imaginer des applications malintentionnées envoyant des données infectées à un noeud SOAP (voir 2. Modèle de traitement SOAP). Il est fortement recommandé qu'un noeud SOAP recevant un message SOAP soit capable d'évaluer le niveau de confiance dans l'émetteur de ce message SOAP et son contenu.
SOAP peut transporter des données définies par l'application comme blocs d'en-tête SOAP ou contenu de corps SOAP. Le traitement d'un bloc d'en-tête SOAP peut éventuellement inclure de traiter des effets de bord comme les changements d'état, la journalisation des informations ou la génération de messages supplémentaires. Il est fortement recommandé, pour tout scénario de déploiement, que seuls des blocs d'en-tête soigneusement spécifiés, avec des implications de sécurité de tout effet de bord bien comprises, soient traités par un noeud SOAP.
De la même manière, traiter un corps SOAP peut impliquer des effets de bord qui peuvent, s'ils ne sont pas correctement appréhendés, avoir de graves conséquences pour le noeud récepteur. Il est fortement recommandé que seuls les contenus de corps bien définis avec des implications au niveau sécurité connues soient traités.
Les considérations de sécurité ne sont pourtant pas limitées à la reconnaissance des éléments fils immédiats de l'en-tête et du corps SOAP. Les implémenteurs ont besoin de faire particulièrement attention aux implications au niveau sécurité de toutes les données transportées dans un message SOAP qui peut causer une exécution distante d'actions dans l'environnement du récepteur. Ceci inclut non seulement les données exprimées dans l'infoset XML mais aussi des données pouvant être encodées en binaire ou passées comme paramètres, par exemple des chaînes de requêtes sous forme d'URI. Avant d'accepter des données de n'importe quel type, une application devrait probablement être consciente des implications de sécurité particulières associées à ces données dans leur contexte d'utilisation présent.
Les implémenteurs SOAP doivent s'assurer que, si le traitement des diverses parties d'un message SOAP est fourni au travers d'une architecture logicielle modulaire, chaque module est conscient du contexte global au niveau sécurité. Par exemple, un corps SOAP ne devrait probablement pas être traité sans connaître dans quel contexte il a été reçu.
SOAP fournit intrinsèquement un modèle de traitement qui peut impliquer un passage de message SOAP par de multiples noeuds SOAP (voir 2. Modèle de traitement SOAP). Les intermédiaires SOAP sont par définition des tiers et représentent une opportunité pour des attaques de tiers. Des failles de sécurité sur des systèmes exécutant des intermédiaires SOAP peuvent aboutir à de sérieux problèmes de sécurité et de confidentialité. Un intermédiaire SOAP atteint ou un intermédiaire implémenté ou configuré sans attention aux considérations de sécurité et de confidentialité pourrait être utilisé pour une large étendue d'attaques potentielles.
Dans l'analyse des implications des problèmes de sécurité potentiels liés à SOAP, il est important de réaliser que la portée des mécanismes de sécurité fournis par le protocole sous-jacent n'est peut-être pas la même que pour le cheminement entier du message. Il n'est pas obligatoire dans SOAP que tous les bonds entre noeuds participants utilisent le même protocole sous-jacent et, même si c'était le cas, l'utilisation-même d'intermédiaires SOAP est susceptible de dépasser la portée de la sécurité du niveau transport.
Les effets sur la sécurité de ne pas implémenter un DOIT ou DEVRAIT, ou de faire quelque chose dont la spécification dit qu'elle NE DOIT PAS ou NE DEVRAIT PAS être faite peuvent être très subtils. Les auteurs de spécification de liaison doivent décrire en détails les implications de sécurité du cas où des recommandations ou obligations ne seraient pas suivies, car la plupart des implémenteurs n'auront pas le bénéfice de l'expérience et des discussions qui auront produit la spécification (voir 4. Structure pour une liaison SOAP sur un protocole).
De plus, une spécification de liaison peut ne pas se préoccuper de ou fournir de contre-mesures pour tous les aspects des risques de sécurité inhérents. Les auteurs de spécification de liaison doivent identifier tout risque qui pourrait subsister et indiquer où des contre-mesures supplémentaires seraient nécessaires au-delà de celles fournies dans la spécification de la liaison.
Les auteurs de spécifications de liaisons doivent être conscients que les modules d'extension de SOAP exprimés sous forme de blocs d'en-tête SOAP pourraient affecter le protocole sous-jacent de manière imprévue. Un message SOAP transporté sur une liaison sur un protocole particulière pourrait aboutir à des caractéristiques en apparence contradictoires. Un exemple de ceci serait un message SOAP transporté sur HTTP, utilisant le mécanisme d'authentification basique de HTTP en combinaison avec un mécanisme d'authentification basique de SOAP. Il est fortement recommandé qu'une liaison de spécification décrive toute interaction de ce genre entre des extensions et les protocoles sous-jacents.
Des protocoles sous-jacents pourraient être conçus pour un but particulier ou un profil d'application. Les liaisons de SOAP sur de tels protocoles POURRAIENT utiliser la même identification de points d'entrée (par exemple numéro de port TCP) que le protocole sous-jacent, de manière à réutiliser l'infrastructure existante associée à ce protocole.
Cependant, l'utilisation de ports connus par SOAP peut engager des manipulations supplémentaires non intentionnelles par des intermédiaires et implémentations sous-jacentes. Par exemple, HTTP est communément compris comme un protocole de "navigation sur le Web" et les administrateurs réseau pourrait y mettre certaines restrictions ou interposer des services comme du filtrage, de la modification de contenu, du routage, etc. Souvent, ces services sont interposés en utilisant le numéro de port comme heuristique.
Par conséquent, les définitions de liaison sur des protocoles sous-jacents avec un port par défaut bien connu ou des profils d'application DEVRAIENT documenter les interactions potentielles avec des infrastructures couramment déployées sur ces ports ou en conformité avec des profils d'application par défaut. Les définitions de liaison DEVRAIENT également illustrer l'utilisation de liaison sur un autre port que celui par défaut comme moyen d'éviter des interactions non voulues avec de tels services.
Cette annexe décrit les règles de gestion de version pour un noeud SOAP. Si un noeud SOAP supporte le passage de version de SOAP 1.1 à SOAP 1.2, alors le noeud SOAP DOIT implémenter les règles décrites dans cette annexe.
Les règles pour traiter les possibles interactions entre SOAP/1.1 et la version 1.2 de SOAP sont :
Un noeud SOAP/1.1 recevant un message SOAP Version 1.2 va générer
selon SOAP/1.1 une faute SOAP de décalage de version basée sur la
construction de message de SOAP/1.1. C'est-à-dire que l'enveloppe aura
un nom local de Envelope
et un nom d'espace de nommage de
"http://schemas.xmlsoap.org/soap/envelope/".
Un noeud SOAP Version 1.2 recevant un message SOAP/1.1 :
soit POURRAIT traiter le message comme un message SOAP/1.1 (s'il le supporte),
soit DOIT générer une faute SOAP de décalage de version basée sur
la construction de message de SOAP/1.1 selon la sémantique de SOAP/1.1 et utilisant
une liaison de SOAP 1.1 au protocole sous-jacent (voir [SOAP 1.1]).
La faute SOAP DEVRAIT inclure un bloc d'en-tête Upgrade
tel que
défini dans cette spécification (voir 5.4.7 Fautes VersionMismatch (Décalage de Version)), indiquant
le support de SOAP en version 1.2. Ceci permet à un noeud SOAP/1.1
d'interpréter correctement la faute SOAP générée par le noeud SOAP
Version 1.2.
L'exemple ci-dessous montre une faute SOAP générée par un noeud
SOAP Version 1.2 suite à la réception d'un message SOAP/1.1. Le message de
faute est un message SOAP/1.1 avec un bloc d'en-tête
Upgrade
indiquant le support de la version 1.2 de SOAP.
Upgrade
pour
indiquer le support de la version 1.2 de SOAP.<?xml version="1.0" ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header> <env:Upgrade> <env:SupportedEnvelope qname="ns1:Envelope" xmlns:ns1="http://www.w3.org/2003/05/soap-envelope"/> </env:Upgrade> </env:Header> <env:Body> <env:Fault> <faultcode>env:VersionMismatch</faultcode> <faultstring>Version Mismatch</faultstring> </env:Fault> </env:Body> </env:Envelope>
Note:
Notez que les noeuds SOAP/1.1 existants n'indiquent vraisemblablement
pas quelles verions d'enveloppe ils supportent en utilisant l'item
d'information élément Upgrade
. Si rien n'est indiqué alors
cela signifie probablement que SOAP/1.1 est la seule enveloppe supportée.
Note:
Un noeud SOAP/1.1 existant générant une faute SOAP de décalage de version
ne peut probablement pas indiquer quelles versions il supporte grâce à l'item
d'information élément Upgrade
(voir 5.4.7 Fautes VersionMismatch (Décalage de Version)). Si
rien n'est indiqué alors cela signifie que SOAP/1.1 est la seule version supportée.
Notez cependant que des incompatibilités entre liaisons sur des protocoles sous-jacents
pourraient empêcher un noeud SOAP/1.1 de générer une faute SOAP de décalage de
version s'il reçoit un message SOAP Version 1.2. Par exemple, un noeud SOAP/1.1
supportant la liaison de SOAP/1.1 sur HTTP (voir SOAP 1.1 [SOAP 1.1]) qui reçoit
un message SOAP Version 1.2 utilisant la liaison de SOAP 1.2 sur HTTP (voir dans la partie 2
de SOAP 1.2 [SOAP Partie 2],
SOAP HTTP Binding)
pourrait ne pas comprendre la différence entre les deux liaisons et générer une réponse
specifique à HTTP en réponse.
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 sur [email protected] nous adressons notre reconnaissance et nos remerciements.