web services -zakaria bentahar
DESCRIPTION
Dans ce document, on va aborder la notion des web services, leur raison d’être, leur concept, les protocoles et les langages qui circulent autour.Dans la deuxième partie, on présentera trois démonstrations qui présenteront tous les étapes de création du web service, son déploiement et sa consommation depuis un client qu’on créera nous même.TRANSCRIPT
Web services Concepts et initiations
Mr. Zakaria BENTAHAR
MAI 2010
Dans ce document, on va aborder la notion des web services, leur raison d’être, leur
concept, les protocoles et les langages qui circulent autour.
Dans la deuxième partie, on présentera trois démonstrations qui présenteront tous
les étapes de création du web service, son déploiement et sa consommation depuis
un client qu’on créera nous même.
Introduction ............................................................................................................................................. 3
Web Service ............................................................................................................................................. 4
3.1 Invocation ...................................................................................................................................... 5
3.2 Découverte .................................................................................................................................... 5
3.3 Description .................................................................................................................................... 5
Démonstration ........................................................................................................................................ 6
4.1 démonstration ............................................................................................................................... 6
Axis : ........................................................................................................................................ 6
La première étape : ................................................................................................................. 6
La deuxième étape : ................................................................................................................ 7
La troisième étape : ................................................................................................................. 7
4.2 démonstration ............................................................................................................................... 8
La première étape : ................................................................................................................. 8
La deuxième étape : ................................................................................................................ 8
La troisième étape : ................................................................................................................. 9
Résumé : .............................................................................................................................................. 9
4.3 démonstration ............................................................................................................................ 10
La première étape : ............................................................................................................... 10
La deuxième étape : .............................................................................................................. 10
La troisième étape : ............................................................................................................... 13
La quatrième étape : ............................................................................................................. 14
La cinquième étape : ............................................................................................................. 14
Résumé : ............................................................................................................................................ 15
Conclusion ............................................................................................................................................. 16
Annexe : Lexique ................................................................................................................................... 17
Introduction
vec l'interconnexion des ordinateurs en réseau et en particulier à travers internet, il
devient possible de faire fonctionner des applications sur des machines distantes.
L'intérêt d'une application fonctionnant à distance peut à première vue sembler
inutile dans la mesure où les applications fonctionnent fort bien en local (sur le poste de
l'utilisateur), néanmoins une application distante peut répondre aux problématiques
suivantes :
Les données peuvent être présentes uniquement sur le serveur distant (par exemple
un catalogue produit, un classement en temps réel, etc.) ;
Le serveur distant peut disposer d'une puissance de calcul ou de capacités de
stockage dont l'utilisateur local ne dispose pas ;
L'application distante peut être utilisée simultanément par un grand nombre
d'utilisateurs et sa mise à jour n'intervient qu'à un seul endroit.
Pour toutes ses raisons, une interaction entre des programmes distants peut être utile. Les
Web Services apportent une solution à ce problème en définissant une manière standard
d'invoquer une application distante et d'en récupérer les résultats à travers le web.
A
Web Service
out d'abord, le concept de web-service veut simplement dire qu'un serveur propose des
fonctions (des "services") que vous pouvez invoquer à distance à travers le web afin de
déclencher un traitement sur le serveur distant et/ou obtenir une information de ce serveur.
Ce concept n'est pas nouveau. Avant on appelait ça des RPC pour "Remote Procedure Calls". Outre
les RPC du monde UNIX, il existe pour cela des standards ouverts depuis belle lurette, en particulier
CORBA et la réponse propriétaire de Microsoft: DCOM.
La seule nouveauté avec les web services, c'est que ces appels de procédures à distance se font
comme des appels de page web, c'est à dire sur le protocole HTTP. "Je demande une URL, je reçois
une page" devient "Je demande un service, je reçois une réponse". L'unique avantage de passer par
HTTP est de ne pas nécessiter l'ouverture de ports spécifiques sur les firewalls.
Bien évidemment, les web services ont leurs propres standards, en particulier SOAP (le plus utilisé)
ou encore XML-RPC (le plus ancien).
Grâce aux services web, les applications peuvent être vues comme un ensemble de services métiers,
structurés et correctement décrits, dialoguant selon un standard international plutôt qu'un ensemble
d'objets et de méthodes entremêlés.
Le premier bénéfice de ce découpage est la facilité de maintenance de l'application, ainsi que
l'interopérabilité permettant de modifier facilement un composant (un service) pour le remplacer
par un autre, éventuellement développé par un tiers. Qui plus est, les services web permettent de
réduire la complexité d'une application car le développeur peut se focaliser sur un service,
indépendamment du reste de l'application.
Les services web facilitent non seulement les échanges entre les applications de l'entreprise mais
surtout permettent une ouverture vers les autres entreprises. Les premiers fournisseurs de services
web sont ainsi les fournisseurs de services en ligne (météo, bourse, planification d'itinéraire, pages
jaunes, etc.), mettant à disposition des développeurs des API payantes ou non, permettant d'intégrer
leur service au sein d'applications tierces.
T
Couches
e fonctionnement des services web repose sur un modèle en couches, dont les trois couches fondamentales sont les suivantes :
Invocation, visant à décrire la structure des messages échangés par les applications. Découverte, pour permettre de rechercher et de localiser un service web particulier
dans un annuaire de services décrivant le nom de la société, l'objectif de chaque service, etc.
Description, dont l'objectif est la description des interfaces (paramètres des fonctions, types de données) des services web.
3.1 Invocation
Il existe deux grands standards de services web, tous deux basés sur XML :
XML-RPC (XML Remote Procedure Call), le plus ancien, fonctionnant sur un principe procédural et sans gestion des états.
SOAP (Simple Object Access Protocol), fonctionnant selon le modèle objet.
Quel que soit le standard utilisé, le principe de programmation est le même : l'appel de
méthode distante est réalisé grâce à une bibliothèque cliente qui transmet la demande au
fournisseur de service en la formatant en XML de manière transparente; au niveau du
serveur une bibliothèque serveur décode la requête, le serveur fait ses traitements, puis
répond grâce à cette même bibliothèque; la bibliothèque client décode enfin la réponse afin
qu'elle puisse être utilisée par l'application client.
3.2 Découverte
Le protocole standard le plus utilisé pour la découverte de services est UDDI.
3.3 Description
Le protocole standard le plus utilisé pour la description de services est WSDL.
L
Démonstration
On aura dans cette partie, trois démonstrations dont le les méthodes se différent mais leur but et
leur objectif est le même c’est de créer un service, le déployer et le consommer.
4.1 démonstration
Dans cette partie, on va essayer de déceler le rideau sur l’implémentation d’un webservice
et la manière avec laquelle on le fait avec Java.
Dans un premier temps, on aura besoin du serveur Tomcat bien installé sur la machine, aussi
on doit installer Axis mais juste avant on a le droit de marquer une pause et donner à Axis les
privilèges qu’il mérite.
Axis :
Axis ou ce qu’on appelle aussi Apache Axis est une implémentation du protocole SOAP, là on
est à la version Axis2 mais on va se contenter dans cette démonstration par l’Axis d’où
d’ailleurs on peut le télécharger depuis le site officiel : http://ws.apache.org/axis/.
Une fois téléchargé, il suffit de décompresser le fichier "axis-bin-1_4.zip", puis copier le
dossier "axis-1_4\webapps\axis" dans "dossierInstallation\Tomcat 6.0\webapps\", comme
ça Axis sera une application web déployée sous Tomcat. Il vous manquera la librairie
"activation.jar" et d'autres optionnelles: "soap.jar" et "mail.jar",… que vous pouvez copier
dans "dossierInstallation\Tomcat 6.0\common\lib\". Pour vérifier la bonne installation et
éventuellement accéder aux services web existants sur " Axis ", vous redémarrez Tomcat et
vous tapez dans un navigateur : http://localhost:8080/axis.
Maintenant on peut dire qu’on est près pour se lancer dans l’aventure de la création de
notre premier web service.
La première étape :
Nous avons choisi comme exemple une classe somme qui sera responsable de faire la
somme de deux entiers.
La définition de cette classe est comme suit :
public class Somme {
public double sum(double x, double y) {
return x+y;
}
}
Important : lors de la sauvegarde il faut donner comme extension à ce fichier «.jws » c'est-à-
dire ‘Somme.jws’.
La deuxième étape :
Cette étape consiste à déployer le service au sein d'un fournisseur de services web et qui
n’est autre dans cette démonstration qu’Axis. Ainsi, on déplacera le fichier ‘Somme.jws’ dans
le répertoire "Tomcat 6.0/webapps/axis", une fois fait on pourra lancer Tomcat par l’adresse
URL : http://localhost:8080/axis/Somme.jws.
Une page s’ouvrira vous annonçant que le service a été bien déployé et vous invitant à voir
WSDL (Click to see the WSDL).
Une fois on clique sur le lien, on arrive à une page bien rempli du code XML à premier coup
d’œil, mais à vrai dire c’est comme vous l’avez deviné du WSDL.
La troisième étape :
Là, on va tester notre premier web service et savoir si on peut récupérer la somme de deux
entiers ou non.
Toujours sur le navigateur, tapant :
http://localhost:8080/axis/services/Somme?method=sum&x=40&y=60
Analysant ce URL, après avoir déployer le web service à l’aide de Axis, le web service s’est
ajouté à la liste des services déjà disponible par défaut, chose qui nous permet à accéder aux
services de Axis dans un 1er temps puis de spécifier le service et juste après on spécifie la
méthode qu’on veut utiliser avec la passation des paramètres comme on avait l’habitude de
faire avec PHP ou ASP.
C’est vrai qu’on va attendre à un résultat sur une seule ligne affichant juste ‘100’, mais là on
tombe encore une fois sur un fichier XML c’est ce qu’on appelle SOAP c’est le format de la
réponse du web service.
4.2 démonstration
Dans cette deuxième démonstration, on va faire appel à eclipse et on va toujours garder le
fichier WSDL déjà généré dans la démonstration précédente.
La première étape :
On crée un nouveau projet, on le nomme ‘webServiceSomme’, on crée un fichier « lib » où
on va mettre toutes les librairies nécessaires à savoir les librairies qui se trouve dans le
fichier lib de Axis, ainsi que les deux librairies ‘activation.jar’ et ‘mail.jar’, ensuite on crée un
fichier « WSDL» où on va mettre le fichier WSDL qu’on a déjà généré (lors de la précédente
démonstration), puis on crée une classe qu’on nomme « Generator» d’où le code :
public class Generator {
public static void main(String[] args) {
WSDL2Java.main(new String[]{"src/wsdl/Somme.wsdl"});
}
}
La deuxième étape :
Une fois compilé, on remarque qu’il y a carrément un package qui s’est généré
automatiquement sous le nom de « Localhost» contenant 4 fichiers :
Somme.java ;
SommeService.java ;
SommeServiceLocator.java ;
SommeSoapBindingStub.java.
La troisième étape :
On crée maintenant le client qui va consommer ce web service, on crée une classe Client qui
va contenir :
public class Client {
public Client() {
SommeService s = new SommeServiceLocator();
try {
Somme cal=s.sum();
System.out.println(cal.sum(34, 20));
} catch (Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
Client clt = new Client();
}
}
On a finalement consomé notre service et on a un résultat qui n’est pas calculé en interne
normalement mais c’est en externe et au niveau de ce client on fait appel juste à ce web
service pour qu’il nous fasse le traitement et pour qu’il nous renvoie le résultat.
Résumé :
Dans ces deux démonstrations, on s’est familiarisé avec les concepts clés du web service à
savoir WSDL, SOAP, Axis.
4.3 démonstration
On va voir dans cette partie comment créer un service, puis la génération d’un fichier WSDL,
puis son déploiement au niveau du serveur et finalement la manière avec laquelle on
consomme ce service et tout ceci on va le faire sur eclipse GALILEO.
La première étape :
On va crée dans un premier temps un nouveau projet, on va le nommer cette fois-ci
« webServiceStock », on crée une classe « Stock » où on va mettre le service qu’on veut
rendre mettant ce bout de code pour comprendre :
public class Stock {
Hashtable<String, Double> stock;
public Stock() {
stock = new Hashtable<String, Double>();
stock.put("Clavier", 1000.0);
stock.put("Ecran", 800.0);
stock.put("souris", 300.0);
}
public double getPrice(String prix) {
return stock.get(prix);
}
}
Dans cet exemple, on a juste mis quelques produits avec leur prix et le service qu’on
suppose qu’on va rendre c’est qu’on va retourner le prix du produit demandé c'est-à-dire
qu’au niveau du client il ne sera pas les prix des produits qu’après les avoir demandé depuis
ce service.
La deuxième étape :
A l’aide d’eclipse, on crée le web service et ceci en cliquant avec la droite de la souris sur la
classe ‘Stock’, on clique ensuite sur ‘web services ’ puis sur ‘Create web service’.
Chose faite, on aura un écran comme celui là :
Il vaut mieux changer de nom pour générer un nouveau projet séparé de celui où on
était entrain de travailler, ainsi on le nommera « stockPrice ».
On clique sur suivant, on retrouvera la méthode qu’on a déjà définie, puis on clique sur
suivant, on aura cet écran :
On cliquera sur Start server pour déclencher le serveur.
Une fois cette étape est terminée, on remarquera qu’il y a un nouveau projet nommé
« stockPrice » avec des composants mais le plus important à noter c’est ‘web content’ qui
contient à son tour ‘wsdl’ qui contient quant à lui ‘Stock.wsdl’.
Ainsi, à l’aide d’eclipse on a pu générer le fichier wsdl avec moins d’effort.
La troisième étape :
Dans cette étape, on va juste faire le test et voir si notre service fonctionne, alors pour faire on va
cliquer avec le bouton droit de la souris sur ‘Stock.wsdl’ et puis sur ‘web services’ juste après sur
‘Test with Web Services Explorer’ , on aura quelque chose qui ressemble à ceci :
On remarque que la méthode ou si on veut l’appeler par le service est bien généré et il suffit
de cliquer là-dessus pour avoir le champ où on va mettre le nom du produit qu’on veut
connaitre son prix.
La quatrième étape :
Une fois le test est fait, passant aux choses sérieuses.
Une fois le fichier wsdl est généré, on doit par la suite générer ceci au niveau du client aussi
et pour faire il suffit de cliquer sur le fichier wsdl, encore une fois avec le bouton droit de la
souris, sur web services, puis sur ‘Generate client’ ce qui va engendrer un ensemble de
classe et interface :
Stock.java ;
StockProxy.java ;
StockService.java ;
StockServiceLocator.java ;
StockSoapBindingStub.java.
La cinquième étape :
Dans cette étape, on va crée la classe qui jouera le rôle du client et on va la nommer
d’ailleurs comme ainsi c'est-à-dire « Client » d’où le code sera comme suit :
public class Client {
public Client() {
StockService s = new StockServiceLocator();
try {
Stock stock = s.getStock();
System.out.println("Clavier :
"+stock.getPrice("Clavier"));
} catch (Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
Client client = new Client();
}
}
Une fois ceci est exécuté, on aura le prix du produit ‘Clavier’ et ainsi on pourra dire qu’on a
consommé le dit web service bien comme il le faut.
Résumé :
Dans cette troisième démonstration, on a crée le service dans un premier temps, puis on a
généré le service à l’aide de la commande ‘Create web services’, une fois ceci est fait il y a eu
une génération automatique d’un package contenant le fichier wsdl, on pourra se demander
pourquoi ce fichier wsdl, alors dans ce cas la réponse sera la suivante :
Une fois le service est là, on veut le rendre sous format d’un web service alors selon le
protocole SOAP, tout web service devra être mis sous un format wsdl.
Après avoir eu le fichier wsdl ou si on veut dire le web service, on veut le consommer ainsi
on va créer le client et pour faire il y a deux étapes :
i. A l’aide de ‘’Generate client’ (en cliquant sur le fichier wsdl déjà généré);
ii. Construction d’une classe qui jouera le rôle d’un client.
Conclusion
e web services est une galaxie qu’on a essayé d’explorer doucement avec ce document, où on a
essayé de mettre surtout l’accent sur le principe et le concept de fonctionnement, à savoir que
le web service repose sur trois choses :
Création du web service ;
Déploiement du web service ;
Consommation du web service.
Bien qu’en réalité c’est plus compliqué que ça mais ceci est dans la mesure où un développeur il sera
amené à développer soit le service soit consommer le service et qui dit consommer dit l’un des
protocoles dédiés à la couche découverte dont le plus célèbre est UDDI.
Pour conclure, on peut dire que les web services, à plus long terme, deviendront plus qu’une simple
technologie d’intégration faiblement couplée. Ils deviendront la pierre angulaire des interactions
inter-organisationnelles.
L
Annexe : Lexique
DCOM (Distributed Component Object Model) : Ensemble d’interfaces programmes et de
concepts développé par Microsoft qui est en fait l’équivalent de CORBA. Il est utilisé entre
autre pour faire des appels RPC (Remote Procedure Call).
EAI (Enterprise Application Integration) : Terme se référant à des logiciels, des entreprises ou
des applications permettant l’intégration d’applications d’affaires à l’intérieur d’une
entreprise. Par exemple les EAI servent à intégrer un SCM avec un CRM.
EDI (Electronic Data Interchange) : Standard décrivant les formats utilisés dans l’échange de
données d’affaires entre entreprises.
HTTP (Hypertext Transfer Protocol) : Protocole de communication permettant l’échange
de fichiers sur le World Wide Web. HTTP est un protocole d’application développé par le
W3C.
HTTPS (Hypertext Transfer Protocol over Secure Socket Layer, or http over SSL) :
Protocole HTTP auquel l’entreprise Netscape a ajouté la couche SSL pour en augmenter
la sécurité. HTTPS est un protocole permettant l’échange sécurisé de fichiers sur le World
Wide Web.
OASIS (Organization for the Advancement of Structured Information Standards): OSBL
technologique international visant la promotion et l’adoption de standards indépendants
des manufacturiers, dans le domaine des technologies de l’information. OASIS tente de
rapprocher les acteurs industriels et les groupes de standardisation afin qu’ils s’entendent
sur l’utilisation universelle de XML.
RMI (Remote Method Invocation) : Manière qu’utilise un programmeur dans un
environnement Java pour écrire une programmation orientée objet et permettre aux objets
qui sont sur différents serveurs d’interagir dans un environnement distribué. RMI est la
version Java de RPC.
RPC (Remote Procedure Call) : Protocole permettant à un programme de requérir un
service d’un autre programme situé dans le serveur d’un autre réseau, sans avoir à
connaître tout les détails techniques de ce réseau au préalable. Il s’agit d’un protocole
utilisé dans une architecture client/serveur.
SOAP (Simple Object Access Protocol) : Protocole de base des Web Services. Il sert à
l’échange d’informations dans un environnement distribué et décentralisé. Il permet à un
programme résidant dans un système d’opération de communiquer avec un autre
programme résident d’un système d’opération complètement différent.
UDDI (Universal Description, Discovery and Integration) : Spécification XML
chapeautée par l’organisme OASIS régissant l’information relative à la publication, la
découverte et l’utilisation d’un Web Service.
URI (Uniform Resource Identifier) : identifiant d‘un point de contenus sur le Web . Le
URI le plus connus est le URL (Uniform Resource Locator) qui est en fait l’adresse d’une
page Web. Un URI décrit typiquement le mécanisme utilisé pour accéder à une resource
sur le Web, l’ordinateur spécifique où cette ressource est logée et le nom de fichier
spécifique sur cet ordinateur.
WSDL (Web Services Description Language) : Un des standards du corpus Web Services.
Il sert à décrire et publier le format et les protocoles d’un Web Service de manière
homogène par l’utilisation du format XML. Il est chapeauté par W3C.
WS-Security (Web Services-Security) : Une des tentatives de standardisation d’un
mécanisme de sécurisation des données échangées à l’aide des Web Services. Cette
spécification est proposée par IBM, Microsoft et Verisign et est l’une des activités de WS-
I Organization.