Présentation
EnglishAuteur(s)
-
Michel RIVEILL : Professeur à l’université de Nice‐Sophia‐Antipolis
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleINTRODUCTION
Pour faire communiquer deux morceaux d’une même application ou deux applications distinctes, les programmeurs pouvaient jusqu'à présent utiliser trois propositions difficilement compatibles : COM+, la version distribuée du modèle objet de Microsoft limitée dans les faits au monde Windows ; CORBA, spécification normative d'un bus objet multi-plate-forme et multilangage et le modèle des Enterprise Java Beans (EJB), spécification d'architecture pour la construction et l'exécution de composants Java proposée par Sun. Indépendamment des apports des uns et des autres, qui sont en dehors de cette étude, peu de passerelles logicielles permettent de convertir aisément les requêtes issues d’un environnement afin qu'elles soient acceptées dans un autre environnement. Il est donc illusoire de vouloir faire cohabiter simplement au sein d’une même application plusieurs bus logiciels (« middleware ») d’interconnexion. Le besoin étant essentiel, plusieurs types de passerelles existent.
Microsoft, IBM et d’autres par la suite, observant que les incompatibilités et la lourdeur de ces propositions conduisaient au développement de solutions fondées sur des requêtes HTTP, ont introduit SOAP (Simple Object Access Protocol), un protocole de communication entre objets, très simple, reposant sur les acquis de l’Internet. En particulier, cette proposition utilise XML pour la description des requêtes et HTTP pour leur transport, ce qui permet d’éviter les problèmes liés au filtrage par des pare-feu (« firewall »). Ces deux standards, largement diffusés, sont utilisés en lieu et place de tout autre schéma propriétaire. Pour être plus précis, SOAP consolide et rend normative une proposition existante « XML-RPC ». SOAP, soumis à l’IETF et adopté par le W3C, comble une lacune du Web.
L’objectif de ce document est de présenter les principes de fonctionnement de SOAP ainsi que de donner quelques exemples d’utilisation.
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
5. Exemple complet
Il existe plusieurs plates-formes permettant de faire facilement du SOAP. Nous présentons ici un court exemple basé sur l’utilisation du toolkit SOAP for Java produit par IBM et intégré au serveur HTTP Tomcat. Elle utilise le serveur XML Xerces [13]. L’architecture du service est représentée figure 10 :
Dans cette configuration d’étude, le service SOAP accessible à distance comme la partie cliente seront écrits en Java. Le client doit construire un message SOAP correspondant à l’un des services offerts par le serveur qui doit être contacté, puis le lui envoyer à l’aide d’une requête HTTP. Le serveur est essentiellement constitué de trois parties : un serveur HTTP qui reçoit les requêtes de la part des clients, une servlet (RPCRouter) activée chaque fois que le serveur HTTP reçoit une requête SOAP, la partie applicative (application server) qui traite la requête émise par le client.
Nous détaillons dans la suite la partie cliente et la partie serveur écrites en Java. La présence du langage Java est simplement liée au fait que la bibliothèque SOAP d’Apache et la servlet RPCRouter chargée de rediriger les messages SOAP ont été définies pour le langage Java.
-
Serveur
Le rôle de ce service Web est de recevoir une chaîne de caractères contenant comme valeur la taille de cette chaîne, puis de renvoyer au client un autre tableau d’octets de la même taille.
package mesures;
import java.util.*;
import org.w3c.dom.*;
import org.apache.soap.util.xml.*;
public class Serveur {
public byte[] getTab(String taille) {
int t=Integer.parseInt(taille);
if (t==0)
return new byte[0];
else {
byte[] tab=new byte[t];
tab[t-1]=(byte)9;
return tab;
}
}
}
Le seul point spécifique est le rôle de la ligne t=Integer. parseInt(taille) qui permet de transformer en entier la valeur contenue dans une chaîne de caractères. Le reste du code Java ne doit pas poser de problème aux programmeurs familiers de C ou C++.
Le...
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Exemple complet
BIBLIOGRAPHIE
-
(1) - GUDGIN (M.), HADLEY (M.), MOREAU (J.J.), NIELSEN (H.-F.) - * - SOAP Version 1.2. W3C Working Draft, 9 juill. 2001 http://www.w3.org/TR/soap12/
-
(2) - SCRIBNER (K.), STIVER (M.C.), SCRIBNER (K.) - Understanding SOAP : The Authoritative Solution. - 1re éd., Ed. Sams, janv. 2000.
-
(3) - XML Cover Pages - http://www.oasis-open.org/cover/
-
(4) - McLAUGHLIN (Br.) - Java and XML. - 1re Éd., O’Reilly & associates, juin 2000.
-
(5) - BIRREL (A.D.), NELSON (B.J.) - Implementing Remote Procedure Call. - ACM Transactions on Computer Systems, 2 (1), 39-59 (1984).
-
(6) - FIELDING (R.), GETTYS (J.), MOGUL (J.C.), FRYSTYK (H.), BERNERS-LEE (T.) - Hypertext Transfer Protocol - HTTP/1.1. - RFC 2616, U.C. Irvine, W3C/MIT, janv. 1997.
-
...
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(240 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive