Formats de transmission de service Web XML
Cette rubrique est spécifique à une technologie existante. Les services Web XML et les clients du service Web XML doivent à présent être créés à l'aide de Windows Communication Foundation.
Les protocoles binaires tels que DCOM se composent d'une couche de demande de méthode reposant sur un protocole de communication propriétaire. Ces protocoles ne sont pas propices à la création de services Web XML universellement disponibles. Cela ne vous empêche pas d'utiliser de tels protocoles dans un scénario de service Web XML, mais l'inconvénient est que ces protocoles dépendent des architectures spécifiques de leurs systèmes sous-jacents et par conséquent limitent le spectre de clients potentiels.
Vous pouvez également concevoir des services Web XML de façon qu'il puissent utiliser un ou plusieurs protocoles ouverts, par exemple une combinaison d'HTTP et SOAP. L'infrastructure requise pour prendre en charge des protocoles différents varie.
Les services Web XML ne servent pas uniquement à fournir l'accès à l'appel de procédure distante (RPC). Ils peuvent également être conçus pour échanger des informations structurées, telles que les commandes fournisseur et les factures, et ils peuvent être utilisés pour automatiser et connecter des processus d'entreprise internes et externes.
HTTP-GET et HTTP-POST
HTTP-GET et HTTP-POST sont des protocoles standard qui utilisent des verbes HTTP (Hypertext Transfer Protocol) pour le codage et le passage de paramètres sous forme de paires nom/valeur, avec la sémantique de demande associée. Chacun se compose d'une série d'en-têtes de demande HTTP qui définissent notamment ce que le client demande du serveur, qui répond avec une série d'en-têtes de réponse HTTP et les données demandées, si la demande réussit.
HTTP-GET passe ses paramètres sous forme de texte codé en URL à l'aide du type MIME application/x-www-form-urlencoded, qui est ajouté à l'URL du serveur qui gère la demande. Le codage URL est une forme de codage de caractères qui garantit que les paramètres passés se composent de texte conforme, par exemple qu'un espace est codé par %20. Les paramètres ajoutés sont également connu sous le nom de chaîne de requête.
Comme pour HTTP-GET, les paramètres HTTP-POST sont également codés en URL. Toutefois, les paires nom/valeur sont passées à l'intérieur du message de demande HTTP réel au lieu d'être passées comme partie d'URL.
SOAP
SOAP est un protocole simple et léger basé sur XML permettant d'échanger des informations structurées et de type sur le Web. L'objectif global de la conception SOAP est qu'il reste le plus simple possible tout en fournissant un minimum de fonctionnalités. Le protocole définit une infrastructure de messagerie qui ne contient aucune sémantique d'application ou de transport. En conséquence, le protocole est modulaire et très extensible.
En voyageant sur des protocoles de transport standard, SOAP peut utiliser l'architecture ouverte existante de l'Internet et se faire facilement accepter par tout système arbitraire capable de prendre en charge les normes les plus basiques d'Internet. On peut décrire l'infrastructure requise pour prendre en charge un service Web XML conforme à SOAP comme assez simple mais puissante, puisqu'elle ajoute relativement peu de choses à l'infrastructure d'Internet et facilite pourtant l'accès universel aux services conçus avec SOAP.
La spécification de protocole SOAP se compose de quatre parties principales. La première partie définit une enveloppe extensible obligatoire pour encapsuler les données. L'enveloppe SOAP définit un message SOAP ; c'est l'unité d'échange de base entre les processeurs de message SOAP. C'est la seule partie obligatoire de la spécification.
La deuxième partie de la spécification de protocole SOAP définit des règles de codage de données facultatives pour représenter les types de données définis par l'application et des graphiques dirigés, ainsi qu'un modèle uniforme pour sérialiser des modèles de données non syntaxiques.
La troisième partie définit un modèle d'échange de messages de style RPC (demande/réponse). Chaque message SOAP est une transmission unidirectionnelle. Même si SOAP puise ses racines dans le RPC, il ne se limite pas à un mécanisme de demande/réponse. Les services Web XML combinent souvent des messages SOAP pour implémenter de tels modèles, mais SOAP ne mandate pas un modèle d'échange de messages et cette partie de la spécification est également facultative.
La quatrième partie de la spécification définit une liaison entre SOAP et HTTP. Toutefois, cette partie est également facultative. Vous pouvez utiliser SOAP en association avec tout mécanisme ou protocole de transport capable de transporter l'enveloppe SOAP, y compris SMTP, FTP ou même une disquette.
Pour plus d'informations sur la spécification SOAP, consultez le site Web W3C (http://www.w3.org/TR/soap).