Cela ne saute pas aux yeux dans la définition du W3C, mais c’est le protocole SOAP qui est vraiment au cœur du fonctionnement des web services. Ce protocole XML (Simple Object Access Protocol) a été développé spécifiquement pour couvrir les divers scénarios de l’informatique distribuée.
Il définit principalement les points suivants :
- Un mécanisme permettant de définir l’unité de communication. Toute l’information est encapsulée dans un message SOAP. Plus précisément, une enveloppe SOAP contient toute l’information transmise via le réseau. Un message peut contenir un body dans lequel un contenu XML arbitraire peut-être inclus et un nombre quelconque de header pouvant encapsuler de l’information ne faisant pas partie du body du message.
- Un modèle de traitement définissant un jeu bien défini de règles permettant à toute application logicielle de traiter adéquatement les messages SOAP.
- Un mécanisme permettant la gestion des erreurs. Les faults SOAP permettent d’identifier les sources et causes des erreurs pouvant survenir lors d’une interaction.
- Un modèle d’extension du protocole pour lui permettre de transmettre en sus du contenu des messages, des informations ad hoc selon les besoins spécifiques de l’application développée.
- Un mécanisme flexible de représentation de données, autorisant l’échange de données déjà sérialisées sous un format donné (texte, xml…), ainsi qu’une convention permettant de représenter en format XML les types primitifs des langages de programmation usuels.
- Une convention pour la représentation des RPC (Remote Procedure Calls) et les réponses correspondantes en tant que messages SOAP
- Une infrastructure permettant de «lier » les messages SOAP à un protocole de transport, habituellement le http.
Les vingt prochaines pages pourraient décrire en détail les arcanes de ce protocole. Il n’en sera rien.
Dans l’immédiat, bornons nous à noter que les informations effectivement échangés entre fournisseur et consommateur de services le sont effectivement au format SOAP, habituellement via HTTP, ce qu’illustre l’exemple ci-dessous de message « capté » par un moniteur TCP/IP lors d’essais préliminaires du présent projet :
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<getMMAResponse xmlns="urn:atws">
<getMMAReturn xsi:nil="true"/>
<getMMAReturn xsi:nil="true"/>
<getMMAReturn>46.95</getMMAReturn>
<getMMAReturn>45.9475</getMMAReturn>
<getMMAReturn>45.1375</getMMAReturn>
<getMMAReturn>44.545</getMMAReturn>
<getMMAReturn>44.9075</getMMAReturn>
<getMMAReturn>45.4475</getMMAReturn>
<getMMAReturn>45.91</getMMAReturn>
<getMMAReturn>46.86750000000001</getMMAReturn>
<getMMAReturn>47.615</getMMAReturn>
<getMMAReturn>48.24</getMMAReturn>
<getMMAReturn>48.800000000000004</getMMAReturn>
</getMMAResponse>
</soapenv:Body>
</soapenv:Envelope>
D’une façon ou d’une autre, il faudra donc coté fournisseur, formater au standard SOAP l’information que l’on souhaite transmettre et symétriquement coté consommateur, décoder ce même message SOAP pour en tirer l’information utile.
C’est à ce niveau qu’intervient le serveur d’application WS (web service engine) et ses utilitaires. Nous y reviendrons sous peu.
