Les services web permettent la communication entre applications via Internet, utilisant le protocole HTTP et une syntaxe basée sur XML, comme WSDL et SOAP, pour structurer les échanges. Ce système repose sur un modèle en couches incluant l'invocation, la découverte et la description des services, facilitant ainsi leur utilisation indépendante de la plateforme ou du langage. Malgré ses avantages, tels que l'indépendance et la facilité de communication, SOAP peut alourdir les échanges en raison de la quantité d'informations requises par le format XML.

1. Web Services« Services Web en français »
Représentent un mécanisme de communication entre applications distantes à travers
le réseau internet indépendant de tout langage de programmation et de toute plate-
forme d'exécution :
A. utilisant le protocole HTTP comme moyen de transport. Ainsi, les
communications
s'effectuent sur un support universel, maîtrisé et généralement non filtré par les
pare-feux ;
B. employant une syntaxe basée sur la notation XML « WSDL et SOAP ou XML-
RPC » pour décrire les appels de fonctions distantes et les données échangées
;
C. organisant les mécanismes d'appel et de réponse.
Grâce aux services web, les applications peuvent être vues comme un ensemble de
services métiers,structurés et correctement décrits, dialoguant selon un standard
international plutôt qu'un ensemble d'objets et de méthodes entremêlés.
Couches du Web Services
Le fonctionnement des services web repose sur un modèle en couches, dont les trois
couches fondamentales sont les suivantes :
Invocation : visant à décrire la structure des messages échangés par les applications,
« SOAP ou XML-RPC »
Découverte : pour permettre de rechercher et de localiser un service web particulier
dans un annuaire de services décrivant
1- le nom de la société,
2- l'objectif de chaque service, etc.
Le protocole standard le plus utilisé pour la découverte de services est UDDI.
Description : dont l'objectif est la description des interfaces (paramètres des
fonctions, types de données) des services web.
Le protocole standard le plus utilisé pour la description de services est WSDL.
Le standard pour les WebServices et
WSDL + SOAP + UDDI
Quel que soit le standard utilisé, le principe de programmation est le même :
***** l'appel de méthode distante est réalisé grâce à une bibliothèque cliente qui
transmet la demande au fournisseur de service en la formattant en XML de manière
transparente;
***** au niveau du serveur une bibliothèque serveur décode la requête, le serveur
fait ses traitement, puis répond grâce à cette même bibliothèque;
***** la bibliothèque client décode enfin la réponse afin qu'elle puisse être utilisée
par l'application client.

2. SOAP
SOAP (Simple Object Access Protocol) est un protocole définit à l'origine par
Microsoft, puis standardisé par le W3C, utilisant la notation XML permettant de
définir les mécanismes d'échanges d'information entre des clients et des fournisseurs
de services web.
Le mécanisme de transport des messages SOAP peut être le protocole HTTP,SMTP,
FTP, etc.
Il existe des bibliothèques SOAP pour de très nombreux langages, dont Perl, C, C++,
C#,Python, Java, Visual Basic/.NET, PHP, Ruby, etc.
Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il
autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre
serveur
Le protocole SOAP est composé de deux parties :
 une enveloppe, contenant des informations sur le message
lui-même afin de permettre son acheminement et son
traitement,
 un modèle de données, définissant le format du message,
c'est-à-dire les informations à transmettre.

3. SOAP Building Blocks
A SOAP message is an ordinary XML document containing the following elements:
 An Envelope element that identifies the XML document as a SOAP message
 A Header element that contains header information
 A Body element that contains call and response information
 A Fault element containing errors and status information
All the elements above are declared in the default namespace for the SOAP envelope:
Syntax Rules
Here are some important syntax rules:
 A SOAP message MUST be encoded using XML
 A SOAP message MUST use the SOAP Envelope namespace
 A SOAP message MUST use the SOAP Encoding namespace
 A SOAP message must NOT contain a DTD reference
 A SOAP message must NOT contain XML Processing Instructions
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
Consumers of a Web Service do not need to know anything about the platform,
object model, or programming language used to implement the service;
they only need to understand how to send and receive SOAP
messages (HTTP and XML)

4. Fonctionement des WebServices
Côté Client :d'abord. Comme nous l'avons vu, tous nos dialogues avec le serveur
exécutant le service web sont faits via SOAP. Rappelez-vous, SOAP ne spécifie pas le
transport mais HTTP est commun. Cet exemple présume l'utilisation d'HTTP (mais
vous pourriez tout aussi bien utiliser SMP). En tant que tels, nos messages au serveur
seront des requêtes SOAP-XML enveloppées dans des requêtes HTTP. De même, les
réponses du serveur seront des réponses HTTP qui renferment des réponses SOAP-
XML. Maintenant, nous, développeurs côté client, nous ne voulons pas nous occuper
de tous les détails de sérialisation SOAP et de l'encodage de HTTP. Nous employons
alors un package SOAP qui le fera pour nous. Il s'agit typiquement d'une librairie que
nous linkons dans notre propre code client. Nous invoquons ensuite le service,
simplement en invoquant la méthode appropriée du package SOAP (typiquement en
spécifiant l'URL du service, le nom du service et tous les paramètres requis).
Le premier travail d'un package est de sérialiser l' invocation de ce service en
requête SOAP. Il doit ensuite encoder ce message dans une requête HTTP et l'envoyer
à l'URL spécifiée.
Ce que fait le serveur avec cette requête est détaillée plus bas dans cette page. Mais
pour le moment, tenons pour acquis le renvoi par le serveur d'un message encodé
HTTP contenant la réponse SOAP. Nous nous reposons sur le même package SOAP
pour exécuter l'inverse de ce qui fut fait au stade de la requête, c'est-à-dire que le
package décode le message HTTP et extrait le message SOAP, ensuite désérialise le
message SOAP et obtient la valeur de retour de l'appel de la méthode. Cette valeur
de retour trouvée est ensuite passée comme valeur de retour à l'invocation originale
de la méthode par le code client.
Que se passe t-il dans ce diagramme: le code client crée un appel de service en invoquant la
méthode appropriée du package SOAP (1). Le serialiseur SOAP du package SOAP convertit cette
invocation en requête SOAP et l'envoie à l'encodeur HTTP (2). L'encodeur HTTP enveloppe le message
SOAP dans une requête HTTP et l'envoie au serveur SOAP (3). La réponse est reçue par le module
d'encodage/décodage HTTP du serveur SOAP(4); ce module décode et extrait la réponse SOAP qui la
remet au deserialiseur SOAP (5). Le eserialiseur SOAP deserialise le message et passe le résultat au
code client (6) comme valeur de retour de l'invocation originale (1).

5. Côté Serveur : C'est légèrement plus complexe car nous avons besoin d'un process
"listener" (Le Listener est le process serveur qui est en attente de connexion client). Nous
avons également besoin d'une implémentation du service lui-même. A part cela, nous nous
reposons sur un package SOAP de la même façon que du côté client.
Le listener est souvent implémenté au travers d'un servlet qui s'exécute comme une
application web sur un appserver (serveur d'application web) (comme c'est le cas lorsque
nous utilisons Apache SOAP du côté serveur). L'appserver sera configuré
pour passer toutes les requêtes destinées à une certaine
URL (l'URL du service SOAP) à un servlet particulier
(appelons-le servlet SOAP).
Le travail du servlet SOAP est d'extraire le message XML-SOAP de la requête HTTP, de le
désérialiser (de ce fait, séparer le nom de la méthode et les paramètres fournis), et
d'invoquer la méthode du service en conséquence. Le résultat de la méthode est alors
sérialisé, encodé HTTP et renvoyé au demandeur.
Que se passe t-il dans ce diagramme: l'appserver (le serveur d'application web) reçoit une
requête HTTP du Client SOAP destinée à l'URL de service SOAP(1) et, en conséquence de quoi,
le passe au servlet SOAP (2). Le servlet SOAP utilise les fonctionnalités de décodage SOAP et
HTTP incluses dans le package pour extraire les détails de l'appel des services (3 et 4), c'est-à-
dire le nom et les paramètres de la méthode. Une fois muni de ceux-ci, le servlet SOAP peut
invoquer la méthode (5 et 6), encoder la réponse (7 et 8) et fournir la réponse HTTP au
handler de requêtes HTTP (9), qui à son tour, répond au client SOAP (10). Notez que la boite
Servlet Thread indique simplement ce qui s'exécute dans la machine virtuelle du servlet.

6. Avantages
 UtiliserSOAPviaHTTPfacilite lacommunicationetévitelesproblèmesde proxyset pare-feu
par rapport à destechnologiesplusanciennes
 SOAPest
o assezouvertpours'adapterà différentsprotocolesde transport.
o indépendantde laplate-forme.
o indépendantdulangage.
o extensible.
Inconvénients
 En raisondu nombre d'informationsqu'impose le formatXML,SOAPpeutalourdir
considérablementleséchangesparrapportà des middlewares comme CORBA ouICE,ce qui
n'estpas forcémentunhandicapquandlesvolumesde donnéestransitésparSOAPsont
faiblesparrapportau volume total de donnéeséchangées.
 SOAPdécritla manière dontlesapplicationsdoiventcommuniquerentre elles,certains
considèrentque le couplagereste fortentre le serveuretsesclients.Une modificationde
l'API impliqueainsi une évolutioncôté client,contrairementàune architecture orientée
ressourcestelle que REST.