Dans cette section, nous verrons ce que sont les éléments principaux du système, ce qu'ils font et comment ils interagissent.

Voyons le 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.

Voici une description graphique du processus:
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 deserialiseur SOAP deserialise le message et passe le résultat au code client (6) comme valeur de retour de l'invocation originale (1).

Vous noterez que la plupart du travail est fait par le package SOAP. Il y a beaucoup de packages SOAP disponibles gratuitement pour de nombreuses plates-formes. Vous pouvez ainsi écrire votre code client en n'importe quel langage et sur n'importe quelle plate-forme pour lesquels vous pouvez trouver un package SOAP. Parmi les packages possibles:

• Visual Basic et le Toolkit Microsoft SOAP
• Java (Stand-alone ou Servlet/JSPs etc) et Apache SOAP pour Java
• Perl (Stand-alone ou CGI-Perl scripts etc) et SOAP::Lite pour Perl

Il est important de se rappeler que votre choix de langage, de plate-forme et de package SOAP pour consommer des services web du côté client est entièrement indépendant du langage, de la plate-forme et du package SOAP utilisés par le côté serveur pour fournir des services web. De cette façon, le même service web basé sur SOAP (déploié par exemple sur UNIX, écrit en Java et exploitant Apache SOAP pour Java) peut être consommé par tout type de client écrit pour n'importe quelle plate-forme, dans n'importe quel langage, exploitant n'importe quel package SOAP applicable à cette combinaison langage/plate-forme. C'est l'un des grands avantages de la technologie SOAP.

Bien. Voyons maintenant ce qui se passe du 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.

Voici une description graphique du processus:
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.

A nouveau, le gros du travail est effectué par le package SOAP. Dans le cas d'Apache SOAP pour Java, ce package ne contient pas seulement les fonctionnalités d'encodage HTTP et SOAP (qui, comme vu, peut être utilisé du côté client) mais aussi le servlet SOAP lui-même. Et comme nous l'expliquons dans la section SOAP Côté Serveur , il se marie bien avec le Serveur d'Application TOMCAT. La seule chose que vous devez écrire est la logique de la méthode du service.