Exercices « Web Services Java » 1 Robert Voyer

Transcription

Exercices « Web Services Java »
1
Robert Voyer
Accès aux services Web « Axis »
Lancement et accès aux services web du fournisseur « Axis ».
Lancement du fournisseur de services « Axis »
Le serveur « Axis » est installé comme une application Web au sein du moteur de servlets et
de JSPs « Tomcat ». Vous devez, pour accéder aux possibilités de « Axis », activer
préalablement le serveur « Tomcat ».
Pour cela, vous double-cliquez sur :
<dossierInstallation>\Tomcat 4.1\bin\startup.bat
Accès aux services déployés
Pour vérifier la bonne installation et éventuellement accéder aux services web existants sur
« Axis », vous tapez dans un navigateur :
http://localhost:8080/axis
Ensuite, vous pouvez cliquer sur « Validate » et « View »
2
Robert Voyer
Initiation aux Services Web « Axis »
Exercices illustrant le développement de base des Services Web sous Axis.
Exercice Service1 : un premier service simple
Un premier exercice qui affiche tout simplement le célèbre : HELLO WORLD
Dans ce premier exercice, nous allons simplement nous remettre en tête les modes de
développement d’applications Java.
Remarque : Les phases de déploiement et de publication du service que vous allez
développer sont automatisées.
Etape 1 : définition de la classe du service
La première étape consiste à définir la classe du service web qui retournera au client lchaîne
de caractères « HELLO WORLD ».
La définition de cette classe est la suivante :
public class ServiceHelloWorld {
public String message() {
return “Hello World”;
}
}
Utilisez un éditeur de texte simple (emacs sous Unix) ou NotePad sous Dos.
Attention, vous devez sauvegardez votre classe sous le fichier portant le même nom et suffixé
par « java » ! Ici, le fichier de sauvegarde sera donc : ServiceHelloWorld.java.
Etape 2 : déploiement du service par fichier « JWS »
La deuxième étape consiste à déployer le service au sein d’un fournisseur de services web.
L’environnement d’exécution et de déploiement des services web que nous utilisons est l’outil
« Axis ».
Le premier mode de déploiement sous « Axis » que nous allons mettre en œuvre est le plus
simple qui soit ; c’est le déploiement instantané par fichier « JWS ». Vous noterez qu’il n’est
pas nécessaire de compiler le source java.
Pour réaliser le déploiement, il suffit de copier le fichier « HelloWorld.java » (en le
renommant « HelloWorld.jws ») dans le domaine applicatif de « Axis ». Le domaine
application de « Axis » est :
<dossierAxis>/webapps/axis
Vous devez donc effectuer :
copy HelloWorld.java <dossierAxis>\webapps\axis\HelloWorld.jws
Vous êtes désormais en mesure d’accéder à votre service à l’URL suivante :
http://localhost:8080/axis/HelloWorld.jws
Vous devez alors constater que votre service a bien été déployé sur « Axis » en ayant en
retour la page « html » suivante :
There is a Web Service here
Click to see the WSDL
3
Robert Voyer
Si vous cliquez sur ce dernier lien, vous verrez la définition « WSDL » (générée
automatiquement par « Axis ») de votre service web.
Etape 3 : exécution du service par fichier « JWS »
La dernière étape consiste à mettre en œuvre votre service qui est désormais accessible à
travers tout le net !
Pour exécuter une méthode de votre service et obtenir la réponse « SOAP » correspondante,
vous tapez l’expression suivante dans votre navigateur :
http://localhost:8080/axis/HelloWorld.jws?method=message
Par rapport à l’expression précédente, vous précisez ici le nom de la méthode à exécuter, sous
la forme de la valeur de l’attribut « method ».
La réponse affichée est le contenu « SOAP », c’est-à-dire un fichier « XML » dont voici un
extrait :
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
- <soapenv:Body>
- <messageResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<messageReturn xsi:type="xsd:string">Hello World</messageReturn>
</messageResponse>
</soapenv:Body>
</soapenv:Envelope>
Exercice Service2 : un deuxième service simple
En procédant comme précédemment, on vous demande de définir un service web qui calcule
de carré d’un nombre.
Il y a deux différence par rapport à l’exercice précédent :
Le service retourne cette fois-ci un nombre
La méthode à invoquer possède un parameter.
Pour traiter les méthodes avec paramètres, supposons que votre service possède la méthode
ayant la signature suivante :
public int calcule(int nb) ;
L’invocation sera alors réalisée de la façon suivante :
http://localhost:8080/axis/Carre.jws?method=calcule&nb=10
Vous obtiendrez la réponse suivante (toujours sous un format SOAP XML) dont voici un
extrait :
- <soapenv:Body>
- <calculeResponse
<calculeReturn xsi:type="xsd:int">100</calculeReturn>
</calculeResponse>
</soapenv:Body>
</soapenv:Envelope>
4
Robert Voyer
Déploiement des Services Web « Axis »
Exercices illustrant le déploiement des Services Web sous Axis.
Dans les précédents exercices, nous avons mis en œuvre un mode de déploiement entièrement
pris en charge par « Axis ». Ce mode automatique de déploiement présente les contraintes
suivantes :
Nécessité de disposer des sources des classes dont on veut définir le ou les services. En effet,
le mode de déploiement automatique d’Axis travaille sur le source des classes Java
Impossibilité de décrire (en l’état actuel du système « Axis », mais cela pourrait évoluer par
l’introduction de méta-données dans le source des classes) des particularités de déploiement.
Ce sont pour ces raisons, que nous devons parfois réaliser un déploiement explicite. Cela
implique la définition d’un fichier particulier, appelé descripteur de déploiement du service
web.
Ce fichier porte l’extension « wsdd » pour Web Service Deployment Descriptor.
Exercice Deploiement1 : un premier déploiement simple
Nous allons reprendre l’exercice « Service1 » qui retourne la chaîne de caractères « Hello
World » et lui définir un descripteur de déploiement.
Avant de commencer, créer un nouveau dossier de travail et placez-y la définition java de
votre futur service, à savoir « HelloWorld.java ».
Etape 1 : compilation de la classe du service
La première étape consiste à compiler la classe que vous avez définie. Pour ce faire dans une
fenêtre Dos ou Shell, vous tapez : javac HelloWorld.java.
A l’issue de cette étape, vous devrez avoir dans votre dossier de travail, un nouveau fichier
« HelloWorld.class ».
Etape 2 : définition du descripteur de déploiement
Le descripteur de déploiement doit être placé dans le même dossier que le « .class »
définissant le service. Appelons ce descripteur « deploy.wsdd ». Son contenu sera
minimalement celui-ci :
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="HelloService" style="RPC">
<parameter name="className" value="HelloWorld"/>
<parameter name="allowedMethods" value="*"/>
</service>
</deployment>
Expliquons les différents éléments :
Balise de début avec comme attributes les espaces de noms des balises mises en oeuvre
dans un descripteur de deployment.
Le nom d’invocation du service, avec le mode, ici “RPC”. Ce sera le principal mode
que nous mettrons en oeuvre.
5
Robert Voyer
<service name="HelloService" style="RPC">
Ensuite, la classe compilée associée au service
<parameter name="className" value="HelloWorld"/>
Ensuite, les autorisations d’accès au service (ici toutes les méthodes)
Fin de la balise “service”
</service>
Fin de la balise “deployment”
</deployment>
Etape 3 : activation du déploiement
Le descripteur de déploiement doit être maintenant pris en compte par le serveur « Axis » (i.e.
le fournisseur de services) pour réaliser le déploiement du service.
Pour ce faire, il convient d’utiliser l’utilitaire « AdminClient » du serveur « Acxis ».
La ligne de commande est alors :
java org.apache.axis.client.AdminClient deploy.wsdd
Etape 4 : installation du service
Nous avons, lors de l’étape précédente, demandé au serveur « Axis » d’être en mesure de
traiter toutes les requêtes « SOAP » correspondant à notre service « HelloWorld ».
Cela signifie donc qu’à la réception d’une requête « HTTP-SOAP », le serveur pourra
appliquer la méthode spécifiée dans la requête à une instance de la classe correspondant à
notre service (en lui passant, le cas échéant des valeurs).
Cependant, pour que le serveur « Axis » soit en mesure d’utiliser la classe de notre service, il
doit être en mesure d’y accéder. Techniquement, cela implique que la classe soit accessible
par le chemin d’accès aux classes (classpath) du serveur « Axis ». Pour ce faire, vous devez
copier votre classe compilée (HelloWorld.class) dans le dossier :
<dossierAxis>\webapps\axis\WEB-INF\classes
http://localhost:8080/axis/services/HelloService
Le nom « HelloService » correspond au nom du service que nous avons indiqué dans le
descripteur de déploiement.
Vous pouvez alors constater que votre service a bien été déployé sur « Axis » en ayant en
HelloService
Hi there, this is an AXIS service!
Perhaps there will be a form for invoking the service here...
Etape 5 : exécution du service par son « alias »
6
Robert Voyer
http://localhost:8080/axis/services/HelloService?method=message
La réponse affichée est le contenu « SOAP », c’est-à-dire un fichier « XML » comme :
<?xml version="1.0" encoding="UTF-8" ?>
-
- <soapenv:Body>
- <messageResponse
<messageReturn xsi:type="xsd:string">Hello World</messageReturn>
</messageResponse>
</soapenv:Body>
</soapenv:Envelope>
Exercice Deploiement2 : un deuxième déploiement simple
En vous basant sur le modèle de l’exercice précédent, on vous demande d’effectuer le
déploiement du service « Service2 » qui retourne le carré d’un nombre passé en paramètre de
méthode.
Exercice Désactivation1 : pour désactiver un service web
Pour retirer des services déployés, un service, il suffit d’appliquer que l’utilitaire
« AdminClient », le fichier « undeploy.wsdd » correspondant au service.
Le contenu du fichier « undeploy.wsdd » sera toujours le même, au nom de service près. Pour
le service « HelloService », nous aurons :
<undeployment xmlns="http://xml.apache.org/axis/wsdd/">
<service name="HelloService"/>
</undeployment>
Ensuite, la ligne de commande est simplement :
java org.apache.axis.client.AdminClient undeploy.wsdd
Essayez de désactiver les deux services que vous avez déployés dans les deux exercices
précédents.
7
Robert Voyer
Déploiement avancé
des Services Web « Axis »
Exercices illustrant le déploiement avancé des Services Web sous Axis.
Exercice Deploiement3 : un service plus complet
Etape 1 : définition et compilation de la classe du service
On vous demande dans un premier temps de définir un service web de gestion de compte.
Pour cela,, vous allez définir une classe «java « Compte.java », très simple qui ne contient
qu’une seule variable d’instance « solde » représentant le contenu du compte, et qui propose
les services suivants :
public void depotDe(int montant)
Permet d’effectuer un dépôt spécifique sur le compte.
public void retraitDe(int montant)
Permet d’effectuer un retrait spécifique sur le compte.
On ne veut pas pouvoir effectuer le retrait si le solde devient négatif.
public int valeurDuSolde()
Retourne la valeur du solde du compte.
Voici le squelette de la classe que vous devez compléter :
public class Compte {
// declaration de la variable solde
// insérez votre code ici
// le constructeur
public Compte() {
solde = 0;
}
public void depotDe(int montant) {
// actualisez le solde
}
public boolean retraitDe(int montant) {
// verifiez que le solde ne devient pas negatif
// si c’est OK alors actualisez le solde et retournez true
// si ce n’est pas OK alors retournez false
}
public boolean retraitAutorise(int montant) {
// retourne true si le solde ne deviant pas negative
// retourne false si le solde ne deviant pas negative
}
}
public int valeurDuSolde() {
}
8
Robert Voyer
Etape 2 : définition du descripteur de déploiement
Le descripteur de déploiement doit être placé dans le même dossier que le « .class »
définissant le service. Appelons ce descripteur « deploy.wsdd ». Son contenu sera
minimalement celui-ci :
<service name="CompteService" style="RPC">
<parameter name="className" value="Compte"/>
</service>
</deployment>
Expliquons les différents éléments :
Balise de début avec comme attributes les espaces de noms des balises mises en oeuvre
dans un descripteur de deployment.
Le nom d’invocation du service, avec le mode, ici “RPC”. Ce sera le principal mode
que nous mettrons en oeuvre.
Ensuite, la classe compilée associée au service
Ensuite, les autorisations d’accès au service (ici toutes les méthodes)
Fin de la balise “service”
</service>
Fin de la balise “deployment”
</deployment>
Etape 4 : installation du service
Nous avons, lors de l’étape précédente, demandé au serveur « Axis » d’être en mesure de
traiter toutes les requêtes « SOAP » correspondant à notre service « CompteService ».
Cela signifie donc qu’à la réception d’une requête « HTTP-SOAP », le serveur pourra
appliquer la méthode spécifiée dans la requête à une instance de la classe « Compte »
correspondant à notre service « CompteService » (en lui passant, le cas échéant des valeurs).
Cependant, pour que le serveur « Axis » soit en mesure d’utiliser la classe de notre service, il
doit être en mesure d’y accéder. Techniquement, cela implique que la classe soit accessible
par le chemin d’accès aux classes (classpath) du serveur « Axis ». Pour ce faire, vous devez
copier votre classe compilée (Compte.class) dans le dossier :
9
Robert Voyer
http://localhost:8080/axis/services/CompteService
Le nom « CompteService » correspond au nom du service que nous avons indiqué dans le
descripteur de déploiement.
Vous pouvez alors constater que votre service a bien été déployé sur « Axis » en ayant en
CompteService
Hi there, this is an AXIS service!
Perhaps there will be a form for invoking the service here...
http://localhost:8080/axis/services/CompteService?method=valeurDuSolde
La réponse affichée est le contenu « SOAP », c’est-à-dire un fichier « XML » comme :
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Body>
<valeurDuSoldeResponse
<valeurDuSoldeReturn xsi:type="xsd:int">0</valeurDuSoldeReturn>
</valeurDuSoldeResponse>
</soapenv:Body>
</soapenv:Envelope>
Exercice DeploiementAvance1 : un service plus complet
Etape 1 : restreint des accès client
Lors de l’exercice précédent, en effectuant un déploiement qui autorise l’accès à toutes les
méthodes du service, nous donnons une trop grande visibilité du service.
En effet, la méthode « retraitAutorise » est une méthode interne de travail de notre service.
Pour éviter d’accéder à cette méthode, nous avons les 2 possibilités suivantes :
Déclarer la méthode « retraitAutorise » comme « private ». De cette façon, lors du
déploiement, Axis en générant le document « WSDL », ne rend pas visible cerre méthode
pour les clients du service.
Cependant, cette façon de faire n’est pas toujours possible, car parfois, on veut rendre
accessible une méthode pour d’autres objets (serveur en autres), sans pour autant qu’elle soit
10
Robert Voyer
visible pour les clients. Si on converse la déclaration « private » de la méthode, elle ne sera
pas utilisable par les autres objets serveur.
Pour pallier cette difficulté, on peut conserver la méthode comme « public » (c’est
information de développement reste inchangée), mais cacher l’accès aux client. Dans ce cas,
on doit l’indiquer explicitement comme information de déploiement.
Vous devez modifier le contenu du descripteur de déploiement de votre service, le fichier
« deploy.wsdd », en précisant uniquement les méthodes accessibles aux clients. Le fichier
devra renssembler à :
<parameter name="allowedMethods" value="valeurDuSolde depotDe retraitDe"/>
</service>
</deployment>
On indique pour l’attribut « allowedMethods », uniquement les noms de méthodes accessibles
à distance.
Etape 2 : désactivation du service
Pour retirer un service déployé, il suffit d’appliquer que l’utilitaire « AdminClient », le fichier
« undeploy.wsdd » correspondant au service.
Le contenu du fichier « undeploy.wsdd » sera toujours le même, au nom de service près. Pour
le service « CompteService », nous aurons :
<undeployment xmlns="http://xml.apache.org/axis/wsdd/">
<service name="CompteService"/>
</undeployment>
Ensuite, la ligne de commande est simplement :
java org.apache.axis.client.AdminClient undeploy.wsdd
Essayez de désactiver les deux services que vous avez déployés dans les deux exercices
précédents.
Maintenant, vous pouvez vérifier si la méthode interdite « retraitAutorise » est toujours
accessible à distance !
11
Robert Voyer
Exercice DeploiementAvance2 : la perte des informations
Etape 1 : modification du mode conversationnel
L’exercice précédent met en évidence un problème de fonctionnement essentiel. En effet, si
vous effectuez un dépôt (en passant par l’URL d’activation de la méthode du service, comme
nous l’avons fait depuis le début) d’un montant quelconque et qu’ensuite vous demandez la
visualisation du solde, vous obtiendrez toujours la même valeur : 0 !
Pourquoi ?
La réponse est simple : à chaque fois que vous invoquez une méthode du service (en fait à
chaque utilisation du service), le serveur « Axis », avant d’appliquer la méthode envoyée, crée
une nouvelle instance de la classe correspondante (ici « Compte »).
De ce fait, à chaque invocation de méthode, nous aurons toujours une nouvelle instance qui
sera obtenue avec le constructeur par défaut qui initialise la variable « solde » à la valeur 0 !
// le constructeur
public Compte() {
solde = 0;
}
Détaillons ce qui ce passe avec les deux appels suivants :
•
http://localhost:8080/axis/services/CompteService?method=depotDe&montant=100
•
http://localhost:8080/axis/services/CompteService?method=valeurDuSolde
Le premier appel correspond à une demande de dépôt de 100 et le second correspondant à une
demande de visualisation du solde.
•
Premier appel
Le serveur crée une nouvelle instance
C1 = new Compte() ;
Il applique la méthode correspondant à l’appel
C1.depotDe(100) ;
A ce moment l’instance C1 dispose bien d’un solde de 100.
Si on effectue, sur cette instance, l’appel suivant :
C1.valeurDuSolde() ;
Nous obtiendrons bien la valeur : 100
•
Deuxième appel
Le serveur crée une nouvelle instance
Nous la nommons C2 pour bien montrer qu’elle est différente de C1
C2 = new Compte() ;
C2 dispose alors d’un solde initial égal à 0.
Le serveur « Axis » applique la méthode correspondant à l’appel
C2.valeurDuSolde() ;
Nous obtenons alors : 100
Pour éviter que le serveur ne crée une nouvelle instance à chaque appel, nous devons lui
préciser que l’accès au service doit être associée à la session utilisateur. En d’autres termes,
nous voulons que lors du premier accès, le serveur crée une nouvelle instance, puis lors des
appels suivants, à partir du même navigateur (i.e. ce qui représente la notion de session), le
serveur utilise toujours la même instance.
Pour ce faire, vous devez inclure dans le descripteur de déploiement de votre service :
<parameter name="scope" value="application"/>
12
Robert Voyer
Vous devrez donc avoir quelque chose comme :
… // les autres elements habituels de déploiement
<parameter name="scope" value=" application "/>
</service>
</deployment>
Etape 2 : exécution de votre service
Exécutez plusieurs fois les méthodes de dépôt et de retrait et visualisez à chaque fois votre
solde pour constater que les différentes opérations s’appliquent bien au même objet serveur !
Exercice DeploiementAvance3 : la représentation complexe des informations
Etape 1 : modification de la classe du service
On vous demande de modifier la définition de la classe du service « CompteService » pour
mémoriser dans une liste (un Vector Java), les différents montants des dépôts et des retraits.
Vous devrez modifier votre classe et votre descripteur de déploiement pour accepter ces
nouvelles caractéristiques.
Voici les parties concernées dans votre classe :
public class Compte {
// declaration de la variable mouvements de type Vector
// le constructeur
public Compte() {
// initialiser votre variable mouvements
solde = 0;
}
public void depotDe(int montant) {
// actualisez la variable mouvements
}
public boolean retraitDe(int montant) {
// actualisez la variable mouvements dans le cas où le retrait est accepté
}
// definition de la méthode “listeMouvements”
}
Etape 2 : prise en compte des modifications
Pour que les modifications du service (changement de la classe, recompilatrion) soient
correctement prises en compte, il faut :
Effectuer un « undeploy » de la version actuellement déployée
13
Robert Voyer
Effectuer un « deploy » de la nouvelle version
Copier la définition « .class » de votre service dans le dossier réservé aux implémentations
des services, c’est-à-dire :
Si vous continuez d’accéder à l’ancienne version de votre service, vous devez alors arrêtez le
serveur « Tomcat », puis le redémarrer.
Etape 3 : mise en oeuvre du service
On vous demande d’appliquer diverses méthodes sur votre services, afin de valider vos
définitions. A chaque fois, vous pouvez utiliser la méthode qui retourne la liste des
mouvements afin de vérifier que vous mémorisez bien les différents montants de chaque
dépôt et de chaque retrait.
14
Robert Voyer
Interopérabilité
Exercices illustrant la mise en œuvre des Services Web depuis le langage Java.
Préliminaires
Jusqu’à ce stade, nous avons toujours utilisé le navigateur Web pour invoquer les services et
visualiser (sous le format SOAP) les résultats retournés.
Nous allons étudier maintenant, un autre mode de communication avec les services plus
adapté à leur mise en œuvre, et surtout à l’intégration avec d’autres applications. Ce deuxième
modèle consiste à définir une application Java qui réalise les étapes suivantes :
1. Création d’un accès au service
2. Création d’un appel vers le service
3. Récupération de l’adresse URL du service accédé
4. Récupération de la méthode à appliquer
5. Mise en place des éventuels valeurs des paramètres de la méthode
6. Invocation du service
7. Récupération du résultat
Le squelette standard et très général de définition d’un client d’accès à un service est :
// importation des packages
import org.apache.axis.client.*;
import javax.xml.namespace.*;
// definition de la classe
public class ClientHelloWorld {
// definition du “main”
public static void main(String [] args) {
try {
// étape 1 : creation de l’accès vers le service
Service service = new Service();
// étape 2 : creation d’un appel vers le service
Call call = (Call)service.createCall();
// étape 3 : récupération de l’adresse URL du service accédé
String endpoint = "http://localhost:8080/axis/services/HelloService";
call.setTargetEndpointAddress( new java.net.URL(endpoint));
// étapes 4-5-6-7 :
Récupération de la méthode à appliquer
Mise en place des éventuels valeurs des paramètres de la méthode
Invocation du service
Récupération du résultat
String message = (String)call.invoke(“message”, new Object[]{});
}
}
System.out.println("Retour de Hello World " + message);
} catch (Exception e) {
System.err.println(e.toString());
}
15
Robert Voyer
Exercice Client 1 : définition d’un client Java pour HelloWorld
On vous demande, en reprenant directement le modèle précédent, d’écrire un client pour le
service web, déjà déployé, « HelloWorldService ».
Exercice Client 2 : définition d’un client Java pour Carre
Ecrire un client Java qui utilise le service « CarreService ».
Exercice Client 3 : définition d’un client Java pour Compte
Ecrire un client Java qui utilise le service « CompteService ».
On veut :
•
effectuer plusieurs dépôts ;
•
effectuer plusieurs retraits ;
•
visualiser le solde global ;
•
visualiser la liste des différents mouvements (i.e. les montants des dépôts et des
retraits)
16
Robert Voyer
Surveillance des
Services Web « Axis »
Puisque nous activons les services directement depuis des applications Java, nous ne
visualisons plus le contenu des messages « SOAP » qui sont transités dans les échanges
« http », et c’est bien pratique ainsi.
Cependant, parfois, et même souvent pour les développeurs, il peut être utile d’examiner les
messages « SOAP » qui sont échangés entre le client et le serveur.
Pour cela, nous devons mettre en œuvre un moniteur qui aura en charge la visualisation des
messages « SOAP ».
Utilisation d’un moniteur de messages « SOAP »
Pour pouvoir surveiller les messages SOAP échangés entre le client et le serveur, nous devons
installer un moniteur spécifique.
Lancement
Pour cela, nous utilisons le moniteur intégré à « Axis » en exécutant :
•
java org.apache.axis.utils.tcpmon
Paramétrage
Ensuite, nous devons préciser :
•
Listen Port# Æ 9000 (par exemple)
•
Target Hostname Æ localhost (proposé par défaut)
•
Target Port# Æ 8080 (proposé par défaut)
Fonctionnement
Comment fonctionne le moniteur ? En fait, il intercepte toutes les requêtes et toutes les
réponses « SOAP ». Pour cela, il écoute un numéro de port particulier (ici 9000) et il doit
aiguiller vers le serveur de services grâce aux paramètres « Target Hostname » et « Target
Port# ».
Mise en oeuvre
Pour que le moniteur puisse remplir son office, vous devez modifier l’URL d’accès à votre
service en précisant, non plus le numéro de port actuel « 8080 », mais celui écouté par le
moniteur, à savoir 9000 ! Ne pas oublier que c’est le moniteur qui redirige vers le serveurs de
services web.
Classiquement, notre client pour le service « HelloWorld » est défini comme suit :
17
Robert Voyer
import org.apache.axis.client.*;
import javax.xml.namespace.*;
public class ClientHelloWorld {
public static void main(String [] args) {
try {
Service service = new Service();
Call call = (Call)service.createCall();
}
}
System.out.println("Retour de Hello World " + message);
} catch (Exception e) {
System.err.println(e.toString());
}
Le seul changement concerne le numéro de port indiqué dans l’URL. Pour utiliser notre
moniteur, nous changerons « 8080 » par « 9000 ». La modification sera simplement :
Exercice Moniteur1 : visualisation des échanges
On vous demande de modifier vos différents clients, à savoir :
•
ClientHelloWorld
•
ClientCarre
•
ClientCompte
pour visualiser dans la fenêtre du moniteur, les différents messages échangés.
18
Robert Voyer
L’adaptation avec Java
Préliminaires
Exercices illustrant la mise en œuvre des Services Web depuis le langage Java en générant
automatiquement la définition du proxy côté client. Cela sous-entend la création de toutes les
interfaces et classes nécessaires à la mise en œuvre du service depuis Java.
Cete fois-ci, plutôt que de mettre en œuvre un schéma générique comme précédemment, à
savoir une référence du « endpoint », puis appel de méthode par « invoke » :
on peut utiliser le modèle classique, et plus performant, de Corba pour la définition des
clients.
Dans ce cas, on aura la mise en oeuvre de définitions Java qui correspondront directement à la
définition du service utilisé., à savoir :
•
Utilisation du stub côté client et du skeleton côté serveur
•
Utilisation des Holders, lorsque les paramètres d’appel sont de type :
o out ou inout
•
Utilisation des interfaces représentant les types des objets Java à manipuler
Installation
Il faut avoir dans le classpath (ce qui n’était pas le cas, jusqu’ici), le jar suivant :
•
<DossierAxis>/lib/wsdl4j.jar
Utilisation du générateur « WSDL2Java »
L’outil « Axis » qui permet la génération des définitions Java côté client et côté serveur,
s’appelle « org.apache.axis.wsdl.WSDL2Java ». L’invocation depuis une fenêtre DOS, est la
suivante :
java org.apache.axis.wsdl.WSDL2Java (WSDL-file-URL)
Prenons, par exemple, le fichier « wsdl » du service « CompteService » :
java org.apache.axis.wsdl.WSDL2Java CompteService.wsdl
Remarque : le fichier « CompteService.wsdl » peut-être créé simplement en sauvegardant le
contenu de la fenêtre navigateur, lorsque l’on visualise la définition « wsdl »
du service : http://localhost:8080/axis/services/CompteService?wsdl (avant la
sauvegarde, affichez le source du contenu de la fenêtre)
L’outil « WSDL2Java » génère l’ensemble des définitions dans un sous-dossier correspondant
au nom « target namesspace » du descripteur « wsdl ». En effet, les namespaces sont mappés
en packages Java.
19
Robert Voyer
Génération côté client
On l’effectue en tapant :
java org.apache.axis.wsdl.WSDL2Java CompteService.wsdl
Element WSDL
Element Java généré
Pour chaque type déclaré
Une classe Java
Une classe Holder si le type est utilisé
comme paramètre out/inout
Pour chaque type de port
Une interface Java
Pour chaque liaison
Une classe Stub
Pour chaque service
Une interface Java
Une classe d’implémentation (locator)
Génération côté serveur
On l’effectue en tapant :
java org.apache.axis.wsdl.WSDL2Java
–server-side
–skeletonDeploy true
CompteService.wsdl
Element WSDL
Element Java généré
Pour chaque liaison
Une classe Stub
Une classe d’implémentation (locator)
Pour chaque service
Un descripteur « deploy.wsdd »
Un descripteur « undeploy.wsdd »
La génération côté serveur n’est pas indispensable, aussi nous ne la mettrons pas en œuvre
dans les exercices qui suivent.
Exercice AdaptationWSDL2Java1 :
On vous demande de mettre en œuvre l’outil de génération Java, sur votre premier service
web, à savoir « HelloService ».
Pour ce premier exercice, nous allons vous donner le squelette de définition du client
correspondant à ce nouveau modèle de mise en œuvre des services web.
Etape 1 : création du fichier « wsdl »
La première opération consiste à créer le descripteur « wsdl » de votre service web. Pour cela,
vous devez prendre la définition obtenue depuis une fenêtre navigateur avec l’URL suivante :
•
http://localhost:8080/axis/services/HelloService?wsdl
Ensuite, vous affichez le source que vous sauvegardez sous le nom « HelloService.wsdl »
dans le même dossier que votre service web.
20
Robert Voyer
Etape 2 : génération des classes du proxy
Vous générez les classes utilitaires pour mettre en œuvre votre service depuis un client écrit
en Java. Pour ce faire, et comme indiqué précédemment, vous évaluez depuis une fenêtre
« DOS » (ou shell sous Unix) :
•
java org.apache.axis.wsdl.WSDL2Java HelloService.wsdl
Comme indiqué, les packages Java sont obtenus en fonction des namespaces xml, ce qui
devrait créer le package suivant :
•
localhost.axis.services.HelloService
En d’autres termes, vos différentes classes et interfaces générées sont localisées dans le sousdossier suivant :
•
\localhost\axis\services\HelloService
Etape 3 : définition du client
Vous devez ensuite définir le client Java qui met en œuvre les classes générées lors de l’étape
précédente.
Pour cela, votre client ressemblera à ceci :
package localhost.axis.services.HelloService;
public class HelloServiceClient
{
public static void main(String [] args) throws Exception {
// Création du service depuis le endpoint
// HelloWorldService correspond au nom du service dans le fichier “wsdl”
// c’est la balise : <wsdl:service name="HelloWorldService">
HelloWorldService service = new HelloWorldServiceLocator();
// Utilisation du service pour obtenir un stub qui implemente le SDI
// (Service Definition Type ; i.e. PortType).
// Pour le typage, c’est la balise : <wsdl:portType name="HelloWorld">
// Pour le getHelloService(), le HelloService correspond à la balise :
// <wsdl:port binding="impl:HelloServiceSoapBinding" name="HelloService">
HelloWorld port = service.getHelloService();
}
}
// Mise en oeuvre du service par application directe des méthodes
String texte = port.message();
System.out.println("Message obtenu : " + texte);
Pour connaître les noms des classes et interfaces à utiliser, vous devez examiner le contenu du
dossier contenant les classes et interfaces générées ainsi que le fichier « wsdl » ayant permis
cette génération.
web, à savoir « CarreService ».
web, à savoir « CompteService ».
21
Robert Voyer
Synthèse sur la mise en oeuvre des
Services Web « Axis »
On vous demande de mettre en œuvre les différentes phases que nous avons étudié tout au
long des travaux dirigés.
L’exercice consiste à définir un service web qui réalise la conversion « francs/euros » et
« euros/francs ».
Votre service web devra donc disposer des deux méthodes suivantes :
•
float getEuros(float montantEnFrancs) ;
•
float getFrancs(float montantEnEuros) :
On prendra comme base de conversion :
•
1 euro = 6.56 francs
Voici la définition de la classe Java correspondante :
public class ConvertisseurEF {
public float getEuros(float montantEnFrancs) {
return (float)(montantEnFrancs / 6.56);
}
}
public float getFrancs(float montantEnEuros) {
return (float)(montantEnEuros * 6.56);
}
Phase 1 : génération automatique
Ecriture du fichier « .jws » correspondant
Phase 2 : génération avec déploiement avec « .jws »
Ecriture du fichier « .wsdd » correspondant
Phase 3 : écriture d’un client générique
Ecriture du client en utilisant le schéma générique d’accès au service web. On trouvera dans
votre client quelque chose comme :
String endpoint = "http://localhost:8080/axis/services/ConvertisseurService";
Float message = (Float)call.invoke(“getEuros”, new Object[]{new Float(100)});
Phase 4 : écriture d’un client spécifique par proxy
Ecriture du client en utilisant le schéma par proxy d’accès au service web. Vous devrez donc
générer les classes et interfaces nécessaires à partir du fichier « .wsdl » de votre service web.
22
Robert Voyer

Exercices « Web Services Java » 1 Robert Voyer

Transcription

Documents pareils

Déploiement et Invocation de services web Java avec Axis

04-TD Web Service Java AXIS

SERVLET TP 1 Installation du JDK Installation de Glassfish

TP 5 : Programmation réseau en Java

Glossaire - ecol2com

CV - WordPress.com

Architecte de solutions

Services Web – SOAP en Java

Java et les bases de données: JDBC et SQLJ

Java Avance - Java : Notation Lambda

Les Services Web

Projet ROSES - Equipe BD@LIP6

Objectif :