Adolphe Francois Julien Marmel Dominique Perlat Olivier Printemps SOAP. Simple Object Access Protocol. Encadrant : Chantal Taconet

Transcription

1 Adolphe Francois Julien Marmel Dominique Perlat Olivier Printemps SOAP Simple Object Access Protocol Encadrant : Chantal Taconet

2 Sommaire Sommaire... 2 Première Partie : Présentation Générale de SOAP Présentation et fonctionnement SOAP Présentation et fonctionnement des Webservices Le protocole WSDL Le protocole UDDI Différence entre IIOP et SOAP Protocoles utilisés par SOAP Problèmes posés par SOAP :... 8 a) Problèmes HTTP... 8 b) Problèmes XML... 8 c) Problèmes liés à SOAP Les fichiers WSDL... 9 a) Services b) Port c) Message d) Port Type et Opérations e) Bindings Deuxième Partie : Installation et mise en œuvre Apache SOAP a) Installation b) Exemple d utilisation NuSoap a) Installation b) Exemples d utilisation SOAP::Lite a) Installation b) Exemple d utilisation : Tests d interoperabilité Troisième Partie : Exemples d utilisation Exemple de Web Service : Google Web Service Exemple du gestionnaire d imprimante a) Exemple 1 : l imprimante HP b) Exemple 2 : le gestionnaire d impression c) Exemple 3 : le gestionnaire d impression et WSDL d) Exécution des exemples Bibliographie SOAP Simple Access Protocol 2

3 Première Partie : Présentation Générale de SOAP 1. Présentation et fonctionnement SOAP SOAP (Simple Object Access Protocol) est un protocole d invocation de méthodes sur des services distants. Basé sur XML, SOAP est un format de communication pour assurer communication de machine à machine. Le protocole permet d appeler une méthode RPC (Remote Procedure Call) et d envoyer des messages aux machines distantes via HTTP. Ce protocole est très bien adapté à l utilisation des services web car il permet de fournir au client une grande quantité d informations récupérées sur un réseau de serveurs tiers. La version actuelle de SOAP est la 1.1. Cette version a été proposée au W3C en 2000 par UserLand, Ariba, Commerce One, Compaq, Developmentor, HP, IBM, IONA, Lotus, Microsoft, SAP. Le W3C travaille actuellement sur la version 1.2 de SOAP, elle devrait sortir fin 2002 et à pour but de supprimer l utilisation des RPC au profit des messages. SOAP permet donc l échange d information dans un environnement décentralisé et distribué, comme Internet par exemple. Il permet l invocation de méthodes, de services, de composants et d objets sur des serveurs distants et peut fonctionner sur de nombreux protocoles (des systèmes de messagerie à l utilisation de RPC). Cependant, il fonctionne particulièrement bien avec le protocole HTTP, protocole très souvent utilisé avec SOAP. SOAP utilise les protocoles HTTP et XML. HTTP comme mécanisme d invocation de méthodes en utilisant un des balises spécifiques pour indiquer la présence de SOAP comme «<SOAP-ENV>». Cela permet de franchir aisément les firewalls et proxy et facilite le traitement en cas de filtrage. XML pour structurer les requêtes et les réponses, indiquer les paramètres des méthodes, les valeurs de retours, et les éventuelles erreurs de traitements. XML joue un rôle prépondérant dans SOAP, on peut distinguer plusieurs éléments : une enveloppe, expliquant comment la requête doit être traitée et présentant les éléments contenus dans le message. un ensemble de règles de codage, permettant de différencier les types de données transmises. une convention de représentation, permettant de représenter les appels aux procédures de traitement et les réponses. Même si SOAP ressemble beaucoup en termes de fonctionnalités à des protocoles comme IIOP pour CORBA, ORPC pour DCOM, ou JRMP (Java Remote Method Protocol) pour JAVA, il possède un avantage indéniable. En effets, SOAP utilise un mode texte alors que les autres fonctionnent en mode binaire, cela facilite le passage des équipements de sécurité. SOAP Simple Access Protocol 3

4 2. Présentation et fonctionnement des Webservices Présentation : Les Webservices permettent de faire communiquer deux sous-systèmes ensembles et cela indépendamment des architectures utilisées. Ces systèmes vont pouvoir s échanger des services ou des traitements applicatifs. Les Webservices constituent un moyen de distribuer un service de manière standard grâce à XML tout en respectant un modèle de développement ayant déjà fait ses preuves comme CORBA ou DCOM (Microsoft). Un des avantages des Webservices est de regrouper tous les acteurs derrière un seul et même standard. Fonctionnement : Pour expliquer le fonctionnement des webservices, il convient de distinguer plusieurs étapes :! Recherche dans un annuaire UDDI : le client cherche un service particulier, il s adresse à un annuaire qui va lui fournir la liste des prestataires habilités à satisfaire sa demande. L annuaire UDDI peut être comparé à un moteur de recherche sauf que les documents sont remplacés par des services.! Recherche de l interface du composant à contacter : une fois la réponse reçue (en XML) de l annuaire, le client va chercher à communiquer via une interface. Cette interface décrite en langage WSDL fournit l ensemble des services disponibles. Elle offre la possibilité de vérifier que le contrat correspond bien aux besoins demandés.! Invocation du service : le client doit maintenant passer les paramètres attendus par le service et assurer la communication avec le serveur. L outil utilisé pour cela est le Proxy, c est l objet qui permet la communication entre le client et le serveur. Il est généré par le client en utilisant l interface WSDL. 3. Le protocole WSDL WSDL (Web Service Definition Langage) est un format de représentation des interfaces de services Web en XML. Une analogie avec CORBA peut être faite, en effet WSDL est la représentation XML du langage IDL (description d interfaces). WSDL a deux rôles prépondérants:! Il sert de référence à la génération de Proxies.! Il assure le couplage entre le client et le serveur par le biais des interfaces. 4. Le protocole UDDI UDDI (Universal Description Discovery and Integration) est un protocole basé sur XML qui sert à la publication et à l'exploration d'annuaires de Web Services. Il permet de situer un service Web, de le décrire, et de l intégrer. Ce protocole a été réalisé par IBM, Microsoft et Ariba. Cependant UDDI est assez complexe et a été qualifié par certains «d usine à gaz». C est la raison pour laquelle IBM et Microsoft travaille actuellement sur un autre protocole d annuaire de services : Web Services Inspection (WS-Inspection). L objectif de WS-Inspection est de permettre à une entreprise de décrire facilement les services Web dont elle dispose. SOAP Simple Access Protocol 4

5 5. Différence entre IIOP et SOAP IIOP (Internet Inter-ORB Protocol) est un protocole de transfert de méthode utilisé par CORBA. Il définit le format des messages échangés entre la machine cliente et la machine serveur. IIOP va permettre d envoyer et de recevoir des types complexes de données. Les clients et serveurs peuvent employer n importe quel mélange de langages et de plateformes. IIOP est un protocole très complet qui est capable d effectuer tous les transferts exigés par SOAP. Cependant l utilisation de SOAP peut être parfois préférable pour plusieurs raisons. Tout d abord, l utilisation de IIOP nécessite de compiler et distribuer des souches clients pour chaque type de clients avec qui l on communique. Ce n est évidemment pas très pratique, en particulier quand le nombre de plateformes différentes ou de langages différents est important. Dans le cas des services web, IIOP va poser des problèmes pour le franchissement des équipements de filtrage (firewall, proxy). Cela va demander un travail en plus de la part de chaque personne administrant l équipement. Au contraire, l utilisation de SOAP ne pose absolument pas de problèmes au niveau des firewalls. SOAP étant un protocole utilisant HTTP, il y a peu de chance qu il soit bloqué lors d un filtrage. Evidemment CORBA, au travers de IIOP, est plus performant : il y a moins de données transitant sur le réseau, et les opérations de conversion / déconversion sont traitées plus rapidement. Cependant avec SOAP les données circulent en format texte et en clair sur le réseau. Leur lecture en est donc facilitée et le déboguage est beaucoup plus simple. SOAP est donc un très bon protocole si l on cherche à dialoguer avec des plateformes hétérogènes, ce qui est particulièrement le cas dans toutes les applications de type «Web Services». En fait, l utilisation de CORBA ou de SOAP va surtout dépendre de ce que l on doit faire : dans le cas des webservices SOAP semble être une bonne solution, par contre si l on souhaite faire des applications distribuées classiques comme du calcul distribué, on choisira plutôt CORBA. 6. Protocoles utilisés par SOAP SOAP se sert le plus souvent de deux protocoles : HTTP et XML. Un message SOAP est écrit en XML. HTTP est utilisé comme protocole de transport. Les messages SOAP vont donc être encapsulés dans HTTP, ce qui permet une utilisation et une compatibilité très importante avec les réseaux et équipements existants. HTTP est le protocole de transport le plus utilisé mais il n est pas impossible de trouver des implémentations de SOAP sur d autres protocoles (avec SMTP par exemple). Un message SOAP est un document XML qui possède une enveloppe SOAP et éventuellement une déclaration XML. L enveloppe SOAP est composée d un corps SOAP et éventuellement d un en-tête. Les règles de syntaxe sont les suivantes : Un message SOAP MUST être codé en XML Un message SOAP MUST avoir une enveloppe SOAP Un message SOAP CAN avoir un entête SOAP (header) Un message SOAP MUST avoir un corps SOAP (body) SOAP Simple Access Protocol 5

6 Un message SOAP MUST utiliser l espace de désignation de l enveloppe SOAP Un message SOAP MUST utiliser l espace de désignation d encodage SOAP Un message SOAP MUST NOT contenir une référence à une DTD Un message SOAP MUST NOT contenir des instructions de type XML Processing Un message SOAP va être constitué d une enveloppe et d un corps. C est à l intérieur du corps (body) que l on trouve le contenu : //enveloppe du message <soap:envelope //espace de nommage pour l enveloppe SOAP xmlns:soap=" //on définit le type d encodage du message SOAP:encodingStyle=" //espace de nommage pour les types de variables xmlns:xsi=" xmlns:xsd=" //espace de nommage pour l appel de méthodes xmlns:tns=" //corps <soap:body> //espace de nommage pour la fonction getstatename <m:getstatename xmlns:m=" //on spécifie un argument à passer à getstatname <statenum xsi:type="xsd:int">41</statenum> </m:getstatename> //gestion d erreurs <soap:fault> </soap:fault> </soap:body> </soap:envelope> <envelope> est la racine ; <header>, <body>,et <fault> sont les enfants. SOAP Simple Access Protocol 6

7 Structure d un message SOAP Exemple: Message SOAP encapsulé dans une requête HTTP Voici une requête SOAP typique (avec les en-têtes HTTP) pour un appel à une méthode RPC nommée EchoString, qui prend une chaîne comme paramètre : POST /test/simple.asmx HTTP/1.1 Host: Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: " <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soapenc=" xmlns:tns=" xmlns:soap=" <soap:body soap:encodingstyle=" <tns:echostring> <inputstring>string</inputstring> </tns:echostring> </soap:body> </soap:envelope> Le nom de la méthode est appelé par la balise <tns:echostring> et le paramètre de type chaîne est défini par <inputstring>. La méthode qui est invoqué est donc de cette forme : SOAP Simple Access Protocol 7

8 public String echostring(string inputstring); Le serveur réponds alors: HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soapenc=" xmlns:tns=" xmlns:soap=" <soap:body soap:encodingstyle=" <tns:echostringresponse> <Return>string</Return> </tns:echostringresponse> </soap:body> </soap:envelope> Les règles de sérialisation du type de données de chaîne, ainsi que la forme de l'appel à une méthode, sont définies dans SOAP 1.1, sections 5 et 7 ( 7. Problèmes posés par SOAP : Ces problèmes concernent principalement l interopérabilité des messages SOAP de type RPC. La plupart des problèmes posés par SOAP ne concernent pas directement le protocole lui-même mais plutôt les protocoles utilisés, comme XML ou HTTP. Ils peuvent être divisés en trois catégories : - problèmes http - problèmes XML - problèmes liés au protocole SOAP a) Problèmes HTTP HTTP est utilisé pour le transport des messages SOAP en XML. Or certaines balises spécifiques à SOAP ne vont pas être bien interprétées par tous les clients HTTP. Cela va dépendre du client et ne pas fonctionner dans certains cas. On peut prendre l exemple de la fonction SOAPAction : la valeur de SOAPAction doit être en guillemets sauf s il s agit d une valeur nulle. Exemple : «SOAPAction: ou «SOAPAction:» Cependant certains clients ne sont pas capables de fournir une valeur d entête HTTP nulle, si le serveur en attends une, l appel ne fonctionnera pas. b) Problèmes XML Les problèmes d interopérabilité XML concernent l analyse du langage XML. SOAP repose sur l utilisation de ce langage, donc si XML pose des problèmes d implémentations, ceux-ci vont poser des problèmes sur SOAP. SOAP Simple Access Protocol 8

9 c) Problèmes liés à SOAP En lui-même, SOAP est relativement simple ; il requiert que les messages soient placés dans une enveloppe avec le texte du message inclus dans un élément du corps. Cependant il existe un certain nombre de problèmes d interopérabilité comme par exemple le problème lié à l implémentation de l attribut «mustunderstand». Les spécifications de SOAP indiquent que si cet attribut est défini sur la valeur «1», il devra être traité. Pourtant certaines implémentations de SOAP ne le font pas (principalement les premières à avoir été développées). De nombreux autres problèmes d interopérabilité ont été découverts, ils sont consultables sur le forum Cette liste contribue grandement à l amélioration du protocole. 8. Les fichiers WSDL Afin des décrire les services disponibles sur un serveur, un langage de description de service a été mis en place : le WSDL (Web Service Description Langage). Ce langage est basé sur XML. Les fichiers WSDL contiennent donc la description de l accès à des Web services ainsi que des messages qui seront échangés avec les services en question. (Arguments, types de donnée ). Une fois muni de cette description, appelée aussi parfois «contrat», le client va pouvoir dialoguer avec les services de manière adéquate. On peut par exemple générer automatiquement à partir du fichier WSDL un client ou un proxy pour ce service. Pour comprendre les différentes zones d un descripteur WSDL, le schéma suivant où se situent les différents éléments décrits dans un fichier WSDL. Différents éléments d un fichier WSDL (source : LearnXmlws, SOAP Simple Access Protocol 9

10 Un fichier WSDL commence par <definition> et finit par </definition>. C est à l intérieur de cette espace que l on va déclarer tous les éléments constituant la description. Nous allons prendre l exemple du Web Service de Google pour montrer comment se construit un fichier WSDL. Début de la description des services avec déclaration des différents schémas utilisés Nom unique identifiant cet ensemble de service au niveau du serveur <definitions name="urn:googlesearch" targetnamespace="urn:googlesearch" xmlns:typens="urn:googlesearch"... </definition> xmlns:xsd=" xmlns:soap=" xmlns:soapenc=" xmlns:wsdl=" xmlns=" a) Services Un service est la mise à disposition d une ou plusieurs méthodes. On peut imaginer par exemple une classe avec plusieurs méthodes invocables à distance. La classe sera le service, et chaque méthode sera une opération sur ce service. La définition d un service se fait par l utilisation de <service></service>. b) Port Pour chaque service on va définir des ports par lesquels ce service sera disponible. En effet, il est possible de rendre disponible un service sur plusieurs supports différents : HTTP GET, SOAP, SMTP Définition d un service Définition d un port avec l adresse du service (ici une URL) <service name="googlesearchservice"> <port name="googlesearchport" binding="typens:googlesearchbinding"> <soap:address location=" </port> </service> SOAP Simple Access Protocol 10

11 c) Message Les messages sont les éléments échangés entre le client et le serveur lors d une opération sur le port d un service. Ces messages sont constitués de plusieurs parties (part) qui représentent chacune une donnée avec un type associé. <message name="dogooglesearch"> <part name="key" <part name="q" <part name="start" <part name="maxresults" <part name="filter" <part name="restrict" <part name="safesearch" <part name="lr" <part name="ie" <part name="oe" </message> type="xsd:string"/> type="xsd:string"/> type="xsd:int"/> type="xsd:int"/> type="xsd:boolean"/> type="xsd:string"/> type="xsd:boolean"/> type="xsd:string"/> type="xsd:string"/> type="xsd:string"/> Définition d un message Chaque «part» du message a un nom et un type. Ici un type simple Utilisation d un type complexe <message name="dogooglesearchresponse"> <part name="return" type="typens:googlesearchresult"/> </message> Ainsi, il est possible définir ses propres types en se basant sur les types de base. En lisant cette définition dans le fichier WSDL, le client pourra générer éventuellement automatiquement une structure ou une classe reflétant cette description. Voici un exemple de type complexe qui représente le résultat d une recherche sur le Web service de Google : Définition d un type complexe Lien vers un autre type complexe <type> <xsd:complextype name="resultelement"> <xsd:all> <xsd:element name="summary" type="xsd:string"/> <xsd:element name="url" type="xsd:string"/> <xsd:element name="snippet" type="xsd:string"/> <xsd:element name="title" type="xsd:string"/> <xsd:element name="cachedsize" type="xsd:string"/> <xsd:element name="relatedinformationpresent" type="xsd:boolean"/> <xsd:element name="hostname" type="xsd:string"/> <xsd:element name="directorycategory" type="typens:directorycategory"/> <xsd:element name="directorytitle" type="xsd:string"/> </xsd:all> </xsd:complextype> </type> SOAP Simple Access Protocol 11

12 d) Port Type et Opérations Une méthode peut être représentée par une opération qui prend un message en entrée et renvoie un message en sortie. Ainsi chaque opération représentée par <operation></operation> indique les flux de messages en entrée et en sortie correspondants en définissant les élément <input/> et <output/>. Enfin, la collection de toutes les opérations d un service est rassemblée dans un port type. Définition d une opération (méthode) <porttype name="googlesearchport"> <operation name="dogetcachedpage"> <input message="typens:dogetcachedpage"/> <output message="typens:dogetcachedpageresponse"/> </operation> <operation name="dospellingsuggestion"> <input message="typens:dospellingsuggestion"/> <output message="typens:dospellingsuggestionresponse"/> </operation> On indique le nom des messages en entrée et en sortie <operation name="dogooglesearch"> <input message="typens:dogooglesearch"/> <output message="typens:dogooglesearchresponse"/> </operation> </porttype> SOAP Simple Access Protocol 12

13 e) Bindings Enfin, pour compléter la description, il faut relier certains éléments entre eux. C est le rôle des bindings représentés par les balises <binding></binding>. On va spécifier notamment tout ce qui concerne l encodage des données dans les messages en indiquant les règles que l on utilise. Définition de la couche transport utilisée Pour chaque opération, on défini les règles d encodage des données <binding name="googlesearchbinding" type="typens:googlesearchport"> <soap:binding style="rpc" transport=" <operation name="dogooglesearch"> <soap:operation soapaction="urn:googlesearchaction"/> <input> <soap:body use="encoded" namespace="urn:googlesearch" encodingstyle=" </input> <output> <soap:body use="encoded" namespace="urn:googlesearch" encodingstyle=" </output> </operation> </binding> SOAP Simple Access Protocol 13

14 Deuxième Partie : Installation et mise en œuvre Un des avantages de SOAP est sa capacité à faire communiquer des plateformes hétérogènes. C est pourquoi plusieurs implémentations de SOAP on été développées (ou sont encore en développement). Nous en avons testé quelques unes, utilisant chacune un langage différent : Apache SOAP pour une implémentation Java, NuPHP pour le PHP, et SOAP::Lite pour le langage Perl. Pour chacune, nous allons présenter brièvement les procédures d installation, et quelques exemples de mise en œuvre. 1. Apache SOAP La distribution Apache SOAP ( fournit les librairies nécessaires pour invoquer des services SOAP distants, et des outils côté serveur pour implémenter des services SOAP. En tant que librairie cliente, il offre une API pour invoquer des services SOAP RPC et une API pour envoyer et recevoir des messages SOAP. Pour mettre en œuvre un service accessible par RPC ou par messages, Apache SOAP doit être hébergé par un conteneur de servlets comme Apache Tomcat. Le transport principal est le http, même si le support d autres protocoles peut être ajouté (SMTP par exemple). a) Installation Prérequis côté serveur : jdk (1.2 ou ulterieur), un conteneur de servlets (tomcat par exemple), un parseur XML (xerces par exemple), les classes soap (le fichier soap.war inclus dans la distribution de soap suffit pour tomcat), classes annexes dans certains cas. Prérequis côté client : classes soap, mail.jar, activation.jar, classpath correct pour compiler le code java. Tomcat est un conteneur de servlets JSP qui intègre son propre serveur web. Il ne necessite donc pas l installation d un serveur web séparé. L installation de tomcat ne pose pas de problème particulier. Il suffit d extraire l archive fournie et de démarrer le serveur pour vérifier que les exemples de servlets fonctionnent. Le serveur se lance par défaut sur le port 8080, qui peut être modifié dans les fichiers de configuration de tomcat. L installation de soap sous tomcat se fait simplement en copiant l archive web soap.war dans le repertoire d applications web de tomcat (jakarta-tomcat-4.0.3/webapps). On peut également créer un nouveau <Context> pour le serveur tomcat, qui indiquera où trouver les classes SOAP. Cela implique d ajouter les chemins d accès vers tous les services à deployer dans le classpath. Dans les deux cas, il faut systématiquement redémarrer le serveur pour prendre en compte les modifications. Nous avons choisi de mettre en œuvre Apache SOAP de la première façon, qui utilise la configuration par défaut du serveur tomcat. Lancement et arret du serveur : /mci/projet/proj01/soap/jakarta-tomcat-4.0.3/bin/startup.sh /mci/projet/proj01/soap/jakarta-tomcat-4.0.3/bin/shutdown.sh SOAP Simple Access Protocol 14

15 Pour tester le bon fonctionnement du serveur, il suffit d ouvrir les pages suivantes : Le serveur doit répondre «SOAP (RPC Message) Router Sorry, I don't speak via HTTP GET- you have to use HTTP POST to talk to me.» Si le client est correctement configuré, la commande suivante affichera la liste des services déployés sur le serveur : java org.apache.soap.server.servicemanagerclient list b) Exemple d utilisation Notre exemple conmprend 3 fichiers : - EchoService.java Le code du serveur d echo - GetEcho.java le code du client chargé d appeler le service d echo - DeploymentDescriptor.xml contient la description du service. Ce fichier facilite le déploiement d un service sur le serveur. Compiler les sources java (javac *.java) apres avoir verifie le classpath. Placer les classes dans "/mci/projet/proj01/soap/jakarta-tomcat /webapps/soap/WEB-INF/classes/samples/echo"! serveur : EchoService.java package samples.echo; public class EchoService public String getecho(string s) return "*echo* " + s; Renvoi de la chaine reçue SOAP Simple Access Protocol 15

16 ! client : GetEcho.java package samples.echo; import java.net.*; import java.util.*; import org.apache.soap.*; import org.apache.soap.rpc.*; Importation des classes nécessaires public class GetEcho public static void main (String[] args) throws Exception if (args.length!= 2 && (args.length!= 3!args[0].startsWith ("-"))) System.err.println ("Usage: java " + GetEcho.class.getName () + " [-encodingstyleuri] SOAP-router-URL chaine"); System.exit (1); // Traitement des arguments. int offset = 3 - args.length; String encodingstyleuri = args.length == 3? args[0].substring(1) : Constants.NS_URI_SOAP_ENC; URL url = new URL (args[1 - offset]); String chaine = args[2 - offset]; Traitement des arguments // Construction de l appel. Call call = new Call (); Construction de l appel call.settargetobjecturi ("urn:test-myecho"); call.setmethodname ("getecho"); call.setencodingstyleuri(encodingstyleuri); Vector params = new Vector (); params.addelement (new Parameter("chaine", String.class, chaine, null)); call.setparams (params); // appel: l URI action est vide (non utilisée par XML-SOAP) Response resp = call.invoke (/* router URL */ url, /* actionuri */ "" ); // Check the response. if (resp.generatedfault ()) Fault fault = resp.getfault (); System.err.println("Generated fault: " + fault); else Parameter result = resp.getreturnvalue (); System.out.println (result.getvalue ()); Affichage du résultat Appel Verification de la réponse SOAP Simple Access Protocol 16

17 ! DeploymentDescriptor.xml <isd:service xmlns:isd=" id="urn:test-myecho"> <isd:provider type="java" scope="application" methods="getecho"> <isd:java class="samples.echo.echoservice"/> </isd:provider> <isd:faultlistener>org.apache.soap.server.domfaultlistener</isd:faultlistener> </isd:service>! Utilisation : Les services peuvent être déployés à l aide de l interface web de la distibution Apache SOAP ( ou plus simplement en utilisant la classe ServiceManagerClient fournie : java org.apache.soap.server.servicemanagerclient deploy DeploymentDescriptor.xml java org.apache.soap.server.servicemanagerclient undeploy urn:test-myecho java org.apache.soap.server.servicemanagerclient list Le client prend en paramètres l adresse du routeur RPC et le texte à envoyer : java samples.echo.getecho montexte Apache SOAP n offre pas de support du wsdl côté client. Un utilitaire séparé fourni par IBM permet toutefois de créer un code client à partir d un fichier wsdl, mais son utilisation n est pas pratique. SOAP Simple Access Protocol 17

18 2. NuSoap NuSOAP est une implémentation en PHP de SOAP disponible gratuitement sur Internet (licence LGPL) : Il a été développé par Dietrich Ayala pour Nusphere (IDE pour PHP : Ce kit est constitué de plusieurs classes permettant la mise en place de clients et de serveurs SOAP en utilisant le langage PHP. Ce langage est très utilisé pour construire des sites Web dynamiques, l accès aux Web Services est donc la bienvenue. a) Installation Cette implémentation de SOAP est assez simple à installer et à utiliser puisqu aucun serveur spécifique (autre qu un simple serveur Web) n est requis. Il suffit de mettre sur le serveur un simple script PHP pour avoir acces à des services. La partie serveur est démarrée à chaque appel de l URL du script implémentant la partie serveur pour SOAP. C est entre autre cela qui fait la simplicité de mise en place de cette implémentation : il suffit de faire un «include» du fichier contenant les classe de NuSOAP pour pouvoir déployer ou invoquer des services. b) Exemples d utilisation! Script serveur : déploiement du service myecho <?php require_once('../nusoap/nusoap.php'); $s = new soap_server; $s->register('myecho',false,false,"urn:myecho"); function myecho($chaine) // optionally catch an error and return a fault if($chaine == '') return new soap_fault('client','','la chaine est vide.'); $res="vous avez envoyé:".$chaine; return $res; $s->service($http_raw_post_data);?> Inclusion des classes NuSoap Création d un objet «serveur» Enregistrement du service myecho auprès du serveur Fonction effectuant le service (Fonction qui sera appelée par RPC) Envoie des réponses du serveur au client : Ici, NuSoap va générer le message réponse du serveur en XML et l envoyer dans la réponse http au client. SOAP Simple Access Protocol 18

19 ! Script Client : appel direct au service myecho (sans utiliser le fichier WSDL) Appel aux classes de NuSOAP Préparation du tableau contenants les paramètres à passer au service $lachaine : variable contenant la chaine à passer lors de l appel Création de l objet client avec l URL du service SOAP à appeler. Ici c est l URL du script serveur écrit en PHP <?php require_once('../nusoap/nusoap.php'); if($lachaine!=null) $parameters = array('chaine1'=>$lachaine); $soapclient = new soapclient(' echo $soapclient->call('myecho',$parameters); else echo "<- Remplir le formulaire";?> Appel de la méthode distante myecho avec passage du tableau des paramètres! Script Client : appel direct service myecho avec le fichier WSDL et le proxy NuSOAP permet, si l on utilise les descripteurs de services écrits en WSDL, de générer un proxy pour service. Ce proxy permet d accéder à la méthode distante comme si elle était une méthode d un objet local. Cela permet d avoir un code beaucoup plus clair et moins lourd. SOAP Simple Access Protocol 19

20 Exemple d utilisation : <?php require_once('../nusoap/nusoap.php'); $soapclient= new soapclient(' ); $proxy=$soapclient->getproxy(); $res=$proxy->myecho($lachaine); echo $res; Appel à la procédure distante via le proxy Création du proxy Création du client à partir d un fichier WSDL 3. SOAP::Lite SOAP::Lite ( est un ensemble de modules Perl qui fournissent une interface simple et légère vers SOAP, côté client et côté serveur. Il est préférable d installer la distribution en tant que root bien qu il soit possible d installer les modules dans son propre repertoire de travail. a) Installation De nombreux modules sont nécessaires à SOAP::Lite MIME-Base IO-1.20 URI-1.19 MIME-Lite HTML-Parser-3.26 HTML-Tagset-3.03 libnet-1.12 MIME-tools IO-stringy MailTools-1.46 XML-Parser-2.31 libwww-perl-5.65 Les commandes pour installer les modules dans ~/perl (pour un utilisateur normal) sont : perl Makefile.PL LIB=~/perl make make test make install SOAP Simple Access Protocol 20

21 Il faut parfois éditer le fichier Makefile.PL pour indiquer le chemin d accès des modules déjà ajoutés (ce qui revient à modifier la Ajouter en tête du fichier (par exemple) : use lib '/mci/projet/proj01/perl'; use lib '/mci/projet/proj01/perl/i386-linux'; Une fois que tous les modules sont présents, extraire la distribution SOAP::Lite et modifier le fichier Makefile.PL (ajouter use lib '/mci/projet/proj01/perl/i386-linux'; use lib '/mci/projet/proj01/perl'; en tête du fichier). Comme pour les autres modules, lancer les commandes : perl Makefile.PL LIB=~/perl make make test make install b) Exemple d utilisation :! clientecho.pl (acces par descripteur wsdl) #!perl -w use lib '/mci/projet/proj01/perl'; use SOAP::Lite; Emplacement des modules Perl nécessaires my $lachaine = shift die "usage: clientecho <string>\n"; # on appelle le service Java par sa description wsdl my $soapclient = SOAP::Lite->service(" my $result = $soapclient->getecho($lachaine); print "resultat (Java avec wsdl): $result\n"; Récuperation du paramètre en entrée Appel du service Apache par sa description wsdl # on appelle le service Java par le serveur rpc my $soapclient2 = SOAP::Lite->uri('urn:test-myEcho') ->proxy(' my $result2 = $soapclient2->getecho($lachaine)->result; print "resultat (Java par RPC) : $result2\n"; # on appelle le service PHP par sa description wsdl my $soapclient3 = SOAP::Lite ->service(" my $result3 = $soapclient3->myecho($lachaine); print "resultat (PHP avec wsdl): $result3\n"; # on appelle le service PHP par le serveur rpc my $soapclient4 = SOAP::Lite->uri('urn:myEcho') ->proxy(' my $result4 = $soapclient4->myecho($lachaine)->result; print "resultat (PHP par RPC) : $result4\n"; Appel du service Apache par le serveur RPC Appel du service NuSOAP par sa description wsdl Appel du service NuSOAP par le serveur RPC SOAP Simple Access Protocol 21

22 ! Utilisation La commande pour lancer le client echo est perl clientecho.pl montexte L implémentation côté serveur peut se faire par cgi ou à l aide d un serveur web possédant un module perl. Nous ne sommes pas parvenus à mettre en œuvre la solution cgi, ceci étant rendu difficile par l absence de processus de débuggage lors d une erreur sur le serveur («Erreur 500»). 4. Tests d interoperabilité L objectif principal de SOAP est de permettre à des applications de faire appel à des méthodes distantes quelles que soient les plates-formes utilisées de part et d autre. Nous avons naturellement voulu vérifier cela sur la mise en œuvre simple du service Echo. Les services Echo ont été déployés en Java (avec Apache SOAP) en PHP (avec NuSOAP). Nous avons tesé des clients Java, PHP, et Perl. Le client en Java accède sans difficulté au service sous Java. L appel au routeur RPC en PHP par le client Java nous a tout d abord posé problème : celui-ci nous renvoyait une erreur dont nous ne comprenions pas le sens. Nous nous sommes finalement rendus compte que le problème venait de la présence d un accent dans la chaîne retournée. Après suppression de l accent, l appel fonctionnait parfaitement. Le client PHP et le client Perl fonctionnent sur les deux serveurs sans problème. Ces tests ne sont qu un aperçu des possibilités offertes par SOAP et des problèmes d interopérabilité qu il peut poser. Les modes d encodage et l utilisation de types complexes notamment semblent poser des difficultés lors de la mise en place de plates-formes hétérogènes. SOAP Simple Access Protocol 22

23 Troisième Partie : Exemples d utilisation 1. Exemple de Web Service : Google Web Service Afin, de mieux comprendre les rôles que peuvent remplir les Web Services ainsi que leur fonctionnement, nous en avons testé un existant et développé des clients permettant de l exploiter. Google est un moteur de recherche sur le Web très connu offrant des options de recherches assez avancées. Google met à disposition un Web service permettant d interroger le moteur de recherche via SOAP. Un fichier WSDL est donné pour ce fait et donne l accès à trois méthodes : dogetcachedpage : cette méthode permet de récupérer les page Web en cache dans le moteur de recherche. dogooglesearch : Cette méthode permet de lancer une recherche sur le moteur et d en récupérer 10 résultats (maximum). dospellingsuggestion : permet de traduire du texte Le client a été développé en PHP. Il permet de lancer une recherche en spécifiant le nombre de résultat, puis, pour chaque résultat, il permet de récupérer la page correspondante en cache dans le moteur. Appel du Web Service de recherche sur Google Utilisation des résultats. La structure complexe du résultat a été placée dans des tableaux imbriqués <?php require_once('../nusoap/nusoap.php'); if(isset($query)) $soapclient = new soapclient(' $proxy=$soapclient->getproxy(); $res=$proxy- >dogooglesearch("x4yahthwrxruii7sifp0fxxfz9xgojrt",$query,$start_index,$numres,tru e,"",false,"","","");?> Nombre de réponses trouvées: <?php echo $res['estimatedtotalresultscount'];?><br> Temps de recherche: <?php echo $res['searchtime'];?><br> <?php for($i=0;$i< count($res['resultelements']) && $res['estimatedtotalresultscount']>0;$i++)?> </td></tr> <tr> <td><?php $index=$i+$start_index;echo $index;?></td> <td> <b><?php echo $res['resultelements'][$i]['title'];?></b><br> <a href='<?php echo $res['resultelements'][$i]['url'];?>'><?php echo $res['resultelements'][$i]['url'];?></a><br> <a href="clientcachegoogle.php?cached_url=<?php echo htmlspecialchars($res['resultelements'][$i]['url']);?>">cached page</a> <?php?> SOAP Simple Access Protocol 23

24 2. Exemple du gestionnaire d imprimante Nous avons essayé dans cette partie d implémenter l exemple du gestionnaire d imprimante en java avec SOAP et de voir ainsi les différences avec CORBA. Pour faciliter la compréhension nous avons effectué trois versions du gestionnaire d imprimante. a) Exemple 1 : l imprimante HP Dans cet exemple le service représente une imprimante seule et sur laquelle on peut demander une impression et obtenir des informations sur les taches en cours. GetInfos Imprime SOAP (http) ImprimanteHP.class Clients Service Figure 1 Nous allons donc voir dans un premier comment créer le service puis nous verrons comment écrire les clients. i) Création du service SOAP L écriture d un service SOAP basé sur les RPC est très simple et se fait en trois étapes :! Créer la classe Java contenant le service SOAP à publier! Créer un «deployment descriptor» décrivant le service! Publier le service! Création du service Un service SOAP peut être juste n importe quelle classe Java habituelle qui expose des méthodes publiques. L écriture de cette classe n est en rien spécifique à SOAP. La seule restriction est que les paramètres des méthodes doivent être serialisables. Les types par défaut supportés par SOAP sont les suivants : Notre service a donc la forme suivante : o Tous les types primitifs et les wrapper correspondants o Java arrays o java.lang.string o java.util.date o java.util.gregoriancalendar o java.util.vector SOAP Simple Access Protocol 24

25 o java.util.hashtable o java.util.map o java.math.bigdecimal o javax.mail.internet.mimebodypart o java.io.inputstream o javax.activation.datasource o javax.activation.datahandler o org.apache.soap.util.xml.qname o org.apache.soap.rpc.parameter o java.lang.object (en tant que JavaBean) SOAP Simple Access Protocol 25

26 package GIsoap.exemple1; import java.net.*; import java.io.*; public class ImprimanteHP private short tachecourante; private String nom; ImpInfos inf; public ImprimanteHP() nom=new String("hp"); System.out.println("Instantiation de l'imprimante : "+ nom); public ImpInfos getinfo() InetAddress mamachine; String machine; try mamachine = InetAddress.getLocalHost(); machine = mamachine.gethostname(); catch (UnknownHostException u) machine = new String("machine inconnue"); inf = new ImpInfos(nom,"", machine, tachecourante) ; return inf; public TacheInfos envoidocument (String n) throws TacheRefusee int t; // ouverture du fichier // recupere taille du fichier File f=new File(n); if (! f.isfile() ) throw new TacheRefusee(nom,n+" : n'est pas un fichier"); t = (int)f.length(); if (tachecourante > 2) System.out.println("Je suis définitivement surchargée, il faut me redémarre r!"); throw new TacheRefusee(nom,"surcharge"); System.out.println("Impression du document : "+ n + " sur " + nom + " taille " + t); tachecourante++; return (new TacheInfos(tacheCourante, t)); SOAP Simple Access Protocol 26

27 On remarque que les méthodes getinfos et envoidocument renvoie chacun un objet que nous avons défini. Ces objets seront transmis aux clients en réponse aux appels des méthodes. Comme nous l avons vu plus précédemment les objets doivent être sérialisables. Nous avons donc deux possibilités soit nous écrivons nos propres sérialiseurs soit nous utilisons la classe BeanSerializer de JavaBean fourni avec Apache SOAP. La deuxième possibilité est en fait la plus simple. Pour cela nous devons chaque classe un constructeur par défaut et rajouter les méthodes setxxx et getxxx pour chaque donnée de la classe. package GIsoap.exemple1; public class TacheInfos private short tachecourante; private int taillefichier; public TacheInfos() public TacheInfos( short tachecourante, int taillefichier) this.tachecourante = tachecourante; this.taillefichier = taillefichier; public void settachecourante(short tachecourante) this.tachecourante = tachecourante; public short gettachecourante() return tachecourante; public void settaillefichier(int taillefichier) this.taillefichier = taillefichier; public int gettaillefichier() return taillefichier; TacheInfos.java SOAP Simple Access Protocol 27

28 public class ImpInfos private String imprimante; private String serveur; private String machine; private short tacheencours; public ImpInfos() tacheencours= 2; public ImpInfos( String imprimante, String serveur, String machine, short tacheencou rs) this.imprimante = new String(imprimante); this.serveur = new String(serveur); this.machine = new String(machine); this.tacheencours = tacheencours; public void setimprimante(string imprimante) this.imprimante = imprimante; public String getimprimante() return imprimante; public void setserveur(string serveur) this.serveur = serveur; public String getserveur() return serveur; public void setmachine(string machine) this.machine = machine; public String getmachine() return machine; public void settacheencours(short tacheencours) this.tacheencours = tacheencours; public short gettacheencours() return tacheencours; public String tostring() return imprimante + " "+ serveur + " "+ machine + tacheencours; ImpInfos.java SOAP Simple Access Protocol 28

29 Voilà c est fini en ce qui concerne la création du service.! Création du «deployment descriptor» Pour déployer un service on peut soit utiliser l interface de déploiement fourni le serveur Apache en utilisant le navigateur soit utiliser les commandes de gestion de services pour lequel il faut un fichier XML décrivant le service. Voici ce fichier pour notre exemple : <isd:service xmlns:isd=" id="urn:imprimantehp"> <isd:provider type="java" scope="application" methods="getinfo envoidocument"> <isd:java class="gisoap.exemple1.imprimantehp" static="false"/> </isd:provider> <isd:faultlistener>org.apache.soap.server.domfaultlistener</isd:faultlistener> <isd:mappings> <isd:map encodingstyle=" xmlns:x="urn:imprimantehp-demo" qname="x:impinfos" javatype="gisoap.exemple1.impinfos" java2xmlclassname="org.apache.soap.encoding.soapenc.beanserializer" xml2javaclassname="org.apache.soap.encoding.soapenc.beanserializer"/> <isd:map encodingstyle=" xmlns:x="urn:imprimantehp-demo" qname="x:tacheinfos" javatype="gisoap.exemple1.tacheinfos" java2xmlclassname="org.apache.soap.encoding.soapenc.beanserializer" xml2javaclassname="org.apache.soap.encoding.soapenc.beanserializer"/> </isd:mappings> </isd:service> Le descripteur de déploiement pour notre service d imprimante contient cinq éléments qui nous devons regarder. Le premier élément est l'élément service, qui définit deux attributs, le namespace de XML et l'identification unique du service à déployer. L'identification définie dans l'élément de service doit être unique, puisque cet attribut est employé pour identifier un service publié avec SOAP. Le prochain élément que nous devons examiner est l'élément provider. Il définit l implémentation réelle du service de SOAP, grâce à trois attributs, dont chacun est défini comme suit: type Définit le type d'exécution du service de SOAP. Nous avons défini notre service comme service Java. scope Définit le cycle de vie du service de SOAP. Les valeurs possibles sont page, scope, session, et application. Ces valeurs correspondent directement avec celles définies par les spécifications de JSP. methods Définit les noms des méthodes qui peuvent être appelées sur cet objet de service. Cette liste doit être une liste de noms de méthode séparés par un espace java SOAP Simple Access Protocol 29

30 Cet élément contient un attribut simple, la classe, qui appelle la classe entièrement qualifiée du service appelé. mappings Cet élément annonce tous les objets que nous avons serialisés. Les attributs java2xmlclassname et xml2javaclassname indiquent respectivement une classe pour convertir de Java en XML et de XML en Java.! Publication du service Pour publier le service il suffit d exécuter la commande suivante : javaorg.apache.soap.server.servicemanagerclient deploy DeploymentDescriptor.xml ii) Création d un client soap Maintenant que nous avons définit le service et qu on l a déployé, écrivons un client qui exécutera une des méthodes du service. Le projet de SOAP d'apache fournit une API côté client qui permet de créer des clients de manière simple. Voici par exemple le client qui imprime un fichier sur l imprimante HP. SOAP Simple Access Protocol 30

31 package GIsoap.exemple1; import java.io.*; import java.util.*; import java.net.*; import org.w3c.dom.*; import org.apache.soap.util.xml.*; import org.apache.soap.*; import org.apache.soap.encoding.*; import org.apache.soap.encoding.soapenc.*; import org.apache.soap.rpc.*; public class Imprime public static void main(string[] args) throws Exception if (args.length!= 2) System.err.println("Usage:"); System.err.println(" java " + Imprime.class.getName() + "SOAP-router-URL" + "fichier"); System.exit (1); URL url = new URL(args[0]); String nomfic = args[1]; SOAPMappingRegistry smr = new SOAPMappingRegistry(); BeanSerializer beanser = new BeanSerializer(); // Map the types. smr.maptypes(constants.ns_uri_soap_enc, new QName("urn:imprimanteHP-demo", "TacheInfos"), TacheInfos.class, beanser, beanser); // Build the call. Call call = new Call(); call.setsoapmappingregistry(smr); call.settargetobjecturi("urn:imprimantehp"); call.setmethodname("envoidocument"); call.setencodingstyleuri(constants.ns_uri_soap_enc); Vector params = new Vector(); params.addelement(new Parameter("n", String.class, nomfic, null)); call.setparams(params); // Invoke the call. Response resp; try resp = call.invoke(url, ""); catch (SOAPException e) System.err.println("Caught SOAPException (" + e.getfaultcode() + "): " + e.getmessage()); return; if (!resp.generatedfault()) Parameter ret = resp.getreturnvalue(); Object value = ret.getvalue(); TacheInfos tache = (TacheInfos) value; if (tache!=null) System.out.println("\nImpression envoyée sur HP" + ", tâche " + tache.gettachecourante() + ", taille "+ tache.gettaillefichier() + " : "+ nomfic); else System.out.println("I don't know."); else Fault fault = resp.getfault(); System.err.println("Generated fault: " + fault); SOAP Simple Access Protocol 31

32 Ce client suit un processus simple qui est commun à la plupart des clients RPC SOAP. Il crée d'abord une URL mettant en référence le rpcrouter (que nous avons passé en argument) sur le localhost de serveur de HTTP. URL url = new URL(args[0]); ( Ensuite nous avons besoin que le client sache quels serializer et deserializer employer. C est que la classe SOAPMappingRegistry permet. La méthode maptypes() prend en entré une chaîne d encodage, et des informations sur le type de paramètre que devra utiliser une sérialisation particulière. D'abord, un QName est fourni. Vous devez indiquer la même URN ici, ainsi que le nom local de l'élément (dans ce cas-ci "TacheInfos"), puis de classe Java à sérialiser (TacheInfos.class), et finalement l instance de la classe nécessaire à la serialisation et à la desérialisation. Dans le cas du BeanSerializer, la même instance fonctionne pour tous les deux. Une fois que tout ceci est indiqué dans l'enregistrement, il ne reste plus qu a en informer l objet call par la méthode setsoapmapping-registry(). SOAPMappingRegistry smr = new SOAPMappingRegistry(); BeanSerializer beanser = new BeanSerializer(); // Map the types. smr.maptypes(constants.ns_uri_soap_enc, new QName("urn:imprimanteHP-demo", "TacheInfos"), TacheInfos.class, beanser, beanser); // Build the call. Call call = new Call(); call.setsoapmappingregistry(smr); La prochaine étape exécutée par le client est de créer une instance de org.apache.soap.rpc.rpcmessage.call. L'objet call est l'interface principale utilisée lors de l exécution d une invocation RPC SOAP. Pour employer l'objet call, il faut lui indiquer quel service nous voulons utiliser. Nous faisons ceci en appelant settargetobjecturi, et en lui passant le nom du service que nous voulons exécuter. Nous avons alors placé le nom de la méthode de service que nous voulons exécuter en utilisant la méthode setmethodname(). La prochaine étape est d indiquer le modèle d encodage utilisé dans l appel RPC. L'étape finale est d'ajouter les paramètres attendus en exécutant la méthode demandée. Ceci est fait en créant un vecteur d objets parameter et en les ajoutant à l'objet call en utilisant la méthode setparams(). call.settargetobjecturi("urn:imprimantehp"); call.setmethodname("envoidocument"); call.setencodingstyleuri(constants.ns_uri_soap_enc); Vector params = new Vector(); params.addelement(new Parameter("n", String.class, nomfic, null)); call.setparams(params); La prochaine étape exécutée par le client est d'appeler la méthode de service qui nous intéresse. Ceci est fait en utilisant invoke() avec l URL que nous avons créé plus tôt. SOAP Simple Access Protocol 32

33 resp = call.invoke(url, ""); La valeur de retour de la méthode invoke() est un objet response. L'objet response renvoie un code d'erreur et la valeur retournée de la méthode exécutée du service. On peut vérifier si erreur s est produite en appelant la méthode generatedfault(). Cette méthode renverra vrai s'il une erreur est retournée; on obtient l erreur par la méthode getfault(). Si le generatedfault() renvoie faux, on peut alors obtenir la valeur retournée dans l'objet response, en utilisant la méthode Response.getReturnValue(). Dans notre exemple on voit que la méthode imprime peut générer une exception TacheRefusee. Cependant nous n avons pas trouvé comment rattrapé cette exception du côté client d un manière correcte c est à dire sans analyser la chaîne de caractères qui nous est fournit par getfaultstring(). b) Exemple 2 : le gestionnaire d impression Dans cet exemple nous voulons imprimer sur des imprimantes : HP ou CANON. Dans la version CORBA, le gestionnaire d impression crée un objet CORBA pour chaque imprimante. Ensuite le client imprime sur l imprimante désiré en obtenant la référence de l objet par un fichier ou un service de nommage. Avec SOAP une telle approche n est pas possible. Du moins pas par les références. On pourrait faire un service distinct pour chaque imprimante, mais ceci reviendrait à récréer l exemple 1 pour l imprimante CANON et indiquer le bon URN au client en fonction de l imprimante choisi. Mais une meilleure solution consiste à créer un service que l on appellera «GestionnaireImpression» qui va jouer le rôle de proxy. Les imprimantes seront adressé par un nom et le proxy appellera la méthode demandée de l imprimante choisie. HP Imprime SOAP (http) GestionnaireImpression.class Imprimante.class GetInfos (Proxy) Imprimante.class Clients Service CANON Figure 2 Voici donc la forme du gestionnaire d impression : SOAP Simple Access Protocol 33

34 package GIsoap.exemple2; import java.util.*; public class GestionnaireImpression private Hashtable imprtable = new Hashtable(); public GestionnaireImpression() imprtable.put("canon", new Imprimante("canon")); imprtable.put("hp", new Imprimante("hp")); public ImpInfos getinfo(string nomimp) Imprimante imp=(imprimante) imprtable.get(nomimp); return imp.getinfo(); public TacheInfos envoidocument( String nomimp, String nomfic) throws TacheRefusee Imprimante imp=(imprimante) imprtable.get(nomimp); return imp.envoidocument(nomfic); Et voilà un client : SOAP Simple Access Protocol 34

35 package GIsoap.exemple2; import java.io.*; import java.util.*; import java.net.*; import org.w3c.dom.*; import org.apache.soap.util.xml.*; import org.apache.soap.*; import org.apache.soap.encoding.*; import org.apache.soap.encoding.soapenc.*; import org.apache.soap.rpc.*; public class Imprime public static void main(string[] args) throws Exception if (args.length!= 3) System.err.println("Usage:"); System.err.println(" java " + Imprime.class.getName() + "SOAP-router-URL" + "imprimante" + "fichier"); System.exit (1); URL url = new URL(args[0]); String nomimp = args[1]; String nomfic = args[2]; SOAPMappingRegistry smr = new SOAPMappingRegistry(); BeanSerializer beanser = new BeanSerializer(); // Map the types. smr.maptypes(constants.ns_uri_soap_enc, new QName("urn:gestionimprimante-demo", "TacheInfos"), TacheInfos.class, beanser, beanser); // Build the call. Call call = new Call(); call.setsoapmappingregistry(smr); call.settargetobjecturi("urn:gestionimprimante"); call.setmethodname("envoidocument"); call.setencodingstyleuri(constants.ns_uri_soap_enc); Vector params = new Vector(); params.addelement(new Parameter("nomimp", String.class, nomimp, null)); params.addelement(new Parameter("nomfic", String.class, nomfic, null)); call.setparams(params); // Invoke the call. Response resp; try resp = call.invoke(url, ""); catch (SOAPException e) System.err.println("Caught SOAPException (" + e.getfaultcode() + "): " + e.getmessage()); return; if (!resp.generatedfault()) Parameter ret = resp.getreturnvalue(); Object value = ret.getvalue(); TacheInfos tache = (TacheInfos) value; if (tache!=null) System.out.println("\nImpression envoyée sur " + nomimp + ", tâche " + tache.gettachecourante() + ", taille "+ tache.gettaillefichier() + " : "+ nomfic); else System.out.println("I don't know."); else Fault fault = resp.getfault(); System.err.println("Generated fault: " + fault); SOAP Simple Access Protocol 35

36 c) Exemple 3 : le gestionnaire d impression et WSDL Dans les exemples précédent nous avons vu que l appel de l objet distant dans le client n était pas tout à fait transparente. En effet il faut mettre tous les paramètres dans un vecteur en indiquant leur types, puis positionné la méthode que l on souhaite appeler et enfin faire invoke. L idée est donc cette fois ci de disposer du côté client d un proxy qui nous rendrait les appels transparents. D autre part ce proxy peut être générée automatiquement. Pour cela il faut dans premier temps créer un fichier WSDL qui va décrire le service d une manière indépendante du langage qui l implémente. Puis à partir du fichier WSDL il faut générer le proxy client (en java dans notre cas). HP Imprime GetInfos Gestionnaire ImpressionProxy.class SOAP (http) Gestionnaire Impression.class Imprimante.class Imprimante.class Clients Service CANON Figure 3 d) Exécution des exemples Aller dans le répertoire GIsoap et exécuter une seule fois pour tout les exemples : «../setclasspath» Puis dans chaque répertoire d exemple : «./testit.sh» SOAP Simple Access Protocol 36

37 Bibliographie 1. Articles Généraux sur SOAP! Articles sur SOAP, tests d implémentations et exemples de mise en œuvre, Tutoriel WSDL: Standard SOAP par le W3C: 2. Implémentations et installation! Une liste d implémentations sur Soapware.org : XML Apache Project: Apache SOAP: NuSOAP: SOAP::Lite: Installer Perl sans être super-utilisateur : 3. Divers outils pour SOAP! Outils AXIS : Outils SOAP en ligne: 4. Exemples de Web Services! APIs web Google: Xmethods: SOAP Simple Access Protocol 37