Rapport Soap [PDF]

Zitiervorschau

Adolphe Francois Julien Marmel Dominique Perlat Olivier Printemps

SOAP Simple Object Access Protocol

Encadrant : Chantal Taconet

Sommaire Sommaire ....................................................................................................................... 2 Première Partie : Présentation Générale de SOAP...................................................... 3 1.

Présentation et fonctionnement SOAP........................................................... 3

2.

Présentation et fonctionnement des Webservices.......................................... 4

3.

Le protocole WSDL.......................................................................................... 4

4.

Le protocole UDDI ........................................................................................... 4

5.

Différence entre IIOP et SOAP....................................................................... 5

6.

Protocoles utilisés par SOAP........................................................................... 5

7.

Problèmes posés par SOAP :........................................................................... 8 a) Problèmes HTTP ............................................................................................ 8 b) Problèmes XML ............................................................................................. 8 c) Problèmes liés à SOAP .................................................................................. 9

8. a) b) c) d) e)

Les fichiers WSDL ........................................................................................... 9 Services ........................................................................................................ 10 Port ............................................................................................................... 10 Message........................................................................................................ 11 Port Type et Opérations................................................................................ 12 Bindings ....................................................................................................... 13

Deuxième Partie : Installation et mise en œuvre ....................................................... 14 1. a) b)

Apache SOAP ................................................................................................. 14 Installation.................................................................................................... 14 Exemple d’utilisation ................................................................................... 15

a) b)

NuSoap ............................................................................................................ 18 Installation.................................................................................................... 18 Exemples d’utilisation.................................................................................. 18

a) b)

SOAP::Lite...................................................................................................... 20 Installation.................................................................................................... 20 Exemple d’utilisation : ................................................................................. 21

2.

3.

4.

Tests d’interoperabilité.................................................................................. 22

Troisième Partie : Exemples d’utilisation .................................................................. 23 1.

Exemple de Web Service : Google™ Web Service...................................... 23

2.

Exemple du gestionnaire d’imprimante....................................................... 24 a) Exemple 1 : l’imprimante HP....................................................................... 24 b) Exemple 2 : le gestionnaire d’impression .................................................... 33 c) Exemple 3 : le gestionnaire d’impression et WSDL ................................... 36 d) Exécution des exemples ............................................................................... 36

Bibliographie ............................................................................................................... 37

SOAP – Simple Access Protocol

2

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 « ». 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

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

• • • •

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

//corps

//espace de nommage pour la fonction getStateName

//on spécifie un argument à passer à getStatName 41

//gestion d’erreurs



est la racine ; , ,et sont les enfants.

SOAP – Simple Access Protocol

6

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: 131.107.72.13 Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://soapinterop.org/echoString"



string



Le nom de la méthode est appelé par la balise et le paramètre de type chaîne est défini par . La méthode qui est invoqué est donc de cette forme : SOAP – Simple Access Protocol

7

public String echoString(String inputString);

Le serveur réponds alors: HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length



string



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 (http://www.w3.org/tr/soap).

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: http://test.org/ » 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

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 http://groups.yahoo.com/group/soapbuilders. 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, http://www.learnxmlws.com/tutors/wsdl/wsdl.aspx)

SOAP – Simple Access Protocol

9

Un fichier WSDL commence par et finit par . 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

...

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 . 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)





SOAP – Simple Access Protocol

10

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é.



Définition d’un message Chaque « part » du message a un nom et un type. Ici un type simple

Utilisation d’un type complexe



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











SOAP – Simple Access Protocol

11

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 indique les flux de messages en entrée et en sortie correspondants en définissant les élément et . 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)







On indique le nom des messages en entrée et en sortie





SOAP – Simple Access Protocol

12

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









SOAP – Simple Access Protocol

13

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 (http://xml.apache.org/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 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

Pour tester le bon fonctionnement du serveur, il suffit d’ouvrir les pages suivantes : http://elaphe.int-evry.fr:8080/soap/servlet/rpcrouter http://elaphe.int-evry.fr:8080/soap/servlet/messagerouter

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 http://elaphe.intevry.fr:8080/soap/servlet/rpcrouter 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-tomcat4.0.3/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

! client : GetEcho.java package samples.echo; import import import import

Importation des classes nécessaires

java.net.*; java.util.*; org.apache.soap.*; org.apache.soap.rpc.*;

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 ();

Appel

System.err.println("Generated fault: " + fault); } else { Parameter result = resp.getReturnValue (); System.out.println (result.getValue ()); }

Verification de la réponse

} } Affichage du résultat

SOAP – Simple Access Protocol

16

! DeploymentDescriptor.xml



org.apache.soap.server.DOMFaultListener

! Utilisation : Les services peuvent être déployés à l’aide de l’interface web de la distibution Apache SOAP (http://elaphe.int-evry.fr:8080/soap), ou plus simplement en utilisant la classe ServiceManagerClient fournie : java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter deploy DeploymentDescriptor.xml java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter undeploy urn:test-myEcho java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter list

Le client prend en paramètres l’adresse du routeur RPC et le texte à envoyer : java samples.echo.GetEcho http://elaphe.intevry.fr:8080/soap/servlet/rpcrouter 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

2. NuSoap NuSOAP est une implémentation en PHP de SOAP disponible gratuitement sur Internet (licence LGPL) : http://dietrich.ganx4.com/nusoap/. Il a été développé par Dietrich Ayala pour Nusphere (IDE pour PHP : http://www.nusphere.com/). 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’

SOAP – Simple Access Protocol

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.

18

! 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

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

Exemple d’utilisation :