Présentation
des web-services
Problématique U-Portal
Dans U-Portal se pose le problème de récupérer des données
pour les afficher ensuite dans des canaux. La récupération de
ces données peut soit s'envisager de manière directe via une connection
base de données soit en interrogeant un service distant, un web-service.
Par ailleurs, l'utilisation de certaines fonctionnalités proposées
par des applications existantes (dans d'autres langages que Java) pourraient
se faire depuis le portail à l'aide d'appels de web-services.
L'interêt du web-service est donc qu'il permet de centraliser la logique
applicative d'une application sans avoir à la reporter dans U-Portal
(modularité), qu'il permet de décharger la machine faisant tourner
le portail et qu'il permet d'obtenir des données issues des bases de
gestion par exemple sans autoriser une connexion directe entre la machine du
portail et ces bases.
L'inconvénient, à l'heure actuelle, est que c'est une technologie
nouvelle pour nous dont il reste à démontrer la faisabilité,
la performance et la prise en charge de nos contraintes de sécurité
(surtout pour le CAS).
Le but de cette présentation est de donner les éléments
permettant de comprendre l'infrastructure liée aux web-services ainsi
que d'étudier l'implémentation de cette architecture en Java.
Présentation de l'architecture web-services (ou services web)
- Un web-service : c'est
un logiciel qui interagit avec d'autres au moyen de protocoles universels
(http, xml...)
- Il existe deux formes de services-web : SOAP
et XML-RPC. SOAP est orienté
objet et gère les états tandis que XML-RPC est procédural
et sans gestion des états.
- Les services web présentent les 2 caractéristiques suivantes
:
- enregistrement facultatif auprès d'un service de recherche (UDDI)
- interface publique avec laquelle le client invoque le service (WSDL)
- UDDI :
Universal Desciption, Discovery and Integration peut être vu
comme les pages blanches (ou jaunes) des services-web. C'est un annuaire permettant
à des fournisseurs de présenter leurs services à des
'clients'.
- WSDL : Web Service Description
Language est un langage reposant sur XML dont on se sert pour décrire
les services-web. Il est indispensable à UDDI pour permettre aux clients
de trouver les méthodes leur permettant d'invoquer les services web.
Beaucoup d'outils comme JBuilder, Delphi ou Office se servent de WSDL pour
découvrir et générer les mécanismes d'invocation
des services-web.
- SOAP : Simple Object
Access Protocol est un protocole basé sur XML et qui définit
les mécanismes d'échanges d'information entre les clients et
les fournisseurs de service-web. Les messages SOAP sont succeptibles d'être
transportés en HTTP, SMTP, FTP...
- XML-RPC : protocole RPC
(Remote Procedure Call) basé sur XML. Permet donc l'invocation
de procédure distante sur internet.
Précisions sur SOAP
- Une différence importante entre SOAP et XML-RPC est que les procédures
SOAP prennent des paramètres nommés. L'ordre des paramètres
lui n'a pas d'importance, contrairement à XML-RPC.
- Structure d'un message SOAP :
- une enveloppe qui déinit
le contenu du message,
- un en-tête (optionnel)
qui contient les informations d'en-tête (autorisations et transactions
par exemple),
- un corps contenant les
informations sur l'appel et la réponse
- une gestion d'erreur
qui identifie la condition d'erreur
- des attachements (optionnel)
- Les éléments SOAP peuvent prendre les attributs suivants :
- actor : indique le point
d'arrivée d'un élément d'en-tête. Ceci est
lié au fait qu'un message SOAP peut passer par un ensemble d'intermédiaires
avant d'arriver à sa destination finale. Il est donc possible de
cibler un attribut vers un de ces points intermédiaires via cet
attribut.
- encodingStyle : sert
à définir les types de données contenu dans le document.
- mustUnderstand : sert
à définir si le destinataire d'un message doit traiter un
élément d'en-tête (absence de cet attribut = false).
- SOAP autorise deux modes de communication :
- SOAP RPC : appel synchrone de procédures distantes où
une node SOAP envoie un requête SOAP avec des paramètres
et reçoit une réponse en retour.
- messages SOAP : communication orientée message où des
nodes SOAP envoient et recoivent des documents XML de manière synchrone
ou non.
Précisions sur WSDL
- Un fichier WSDL est un format de description des services web fondé
sur XML.
- Dans WSDL les services communiquent par échange de messages entre
des terminaisons, constituées d'un ou plusieurs ports, chacun doté
d'un type.
- WSDL définit donc :
- les Types
: un système de types applicable à des données. Utilisation
de XML Schema pour définir
les types de données.
- le Message : décrit
les données échangées entre services web. Peut-être
comparé aux paramètres d'un appel de procédure.
- le Type de Port (portType):
définit les opérations du service web et les messages impliqués
(de type input, output ou fault). Peut être
comparé à une interface Java.
- La Liaison (binding)
: définit le format des messages (par exemple soap:body
spécifie que le le message considéré sera transmis
dans la partie body du message soap) et le protocole utilisé par
chaque type de port (voir par exemple soap:binding et les attributs
style et transport). C'est l'implémentation de
l'interface.
- Le Port : un point de
terminaison identifié de manière unique par la combinaison
d'une adresse internet et d'une liaison
- Un Service Web (service)
: associe des liaisons à des process concrets de mise en oeuvre
des opérations qu'elles décrivent (typiquement une URL dans
le cas d'une liaison mettant en oeuvre SOAP sur HTTP)
- Une bonne connaissance des namespaces XML
et de XML Schema
est un pré-requis à la lecture d'un document WSDL.
Java et les web-services
- Java dispose de nombreuses API utiles aux services-web :
- API pour le traitement XML : JAXP
- API pour RPC-XML : JAX-RPC
- API pour l'échange de données XML : JAXM
- API pour les annuaires XML : JAXR
- Mais il existe surtout des librairies prêtes à l'emploi qui
vont simplifier grandement la conception et la consommation de services web
:
- AXIS : c'est une implémentation
Java de SOAP offerte par l'Apache Software Foundation qui couvre aussi
bien la conception que la consommation des services-web.
- Apache propose aussi une implémentation de XML-RPC
- Apache toujours, propose un framework dédié à l'invocation
des services-web : WSIF
(Web Service Invocation Framework).
- Ces trois librairies présentent l'avantage d'être open-source
et bénéficient d'une grande notoriété dans la
communauté Java. Elles semblent donc un choix judicieux pour le projet
Esup.
AXIS
- Axis est un package qui fournit :
- un environnement pouvant soit fonctionner comme un serveur SOAP indépendant
soit comme un plug-in de moteurs de servlet (en particulier TOMCAT),
- Une API pour développer des services web SOAP RPC ou à
base de messages SOAP
- le support de différentes couches de transport : HTTP, FTP...
- la sérialisation/désérialisation automatique d'objets
Java dans des messages SOAP
- des outils pour créer automatiquement les WSDL correspondant
à des classes Java ou inversement pour créer les classes
Java sur la base d'un WSDL (classe proxy en quelque sorte, qui fait le
lien entre l'application Java cliente et le service distant).
- des outils pour déployer, tester et monitorer des web-services.
- Axis est disponible à l'adresse http://xml.apache.org/axis
WSIF
- Le style d'invocation des services web le plus courant est basé sur
l'emploi de SOAP.
- Pourtant, la spécification WSDL prévoit un mécanisme
d'extension afin de lier les services web à de nouveaux protocoles
de transport et de communication. Ces nouveaux protocoles nécessiteraient
la réécriture des programmes clients.
- C'est pour éviter ce cas de figure que WSIF a été conçu
: il permet de prendre en compte des liaisons multiples pour un même
service WEB.
- Ainsi un client utilisant WSIF va pouvoir choisir dynamiquement d'invoquer
un service web via SOAP ou directement
par appel d'une classe Java (si le service est déployé
en local). Ceci ne serait pas possible en utilisant directement AXIS par exemple.
- Cette possibilité, même si elle ne trouve pas d'application
immédiate dans le projet ESup, semble être un gage de pérénité
pour les développements basés sur les web-services. Elle nécessite
par contre l'usage systématique de WSDL.
- Résumé des caractéristiques de WSIF :
- découplage entre le code du programme client et le protocole
d'accès au service WEB,
- compilateur de portType WSDL générant le code d'invocation
du web-service (classe proxy),
- possibilité d'invoquer dynamiquement un service (sans passer
par une classe proxy),
- une nouvelle liaison WSDL peut être installée au vol, en
cours d'exécution,
- permet de choisir dynamiquement, le protocole de communication à
utiliser (accès direct ou SOAP par exemple).
- WSIF est disponible ici : http://ws.apache.org/wsif/
Apache XML-RPC
- C'est une implémentation Java de XML-RPC
- Elle repose sur la classe org.apache.xmlrpc.XmlRpcClient qui permet de créer
des applications clientes
- Les appels peuvent être synchrones ou asynchrones
- Disponible ici : http://ws.apache.org/xmlrpc/
Exemples
Appel d'un service-web avec WSIF
- soit le fichier wsdl verifine.wsdl qui décrit
un service validant un numéro INE
- on génère le proxy d'accès à ce service web
avec la commande : java org.apache.axis.wsdl.WSDL2Java
verifine.wsdl qui nous donne la classe suivante :
package fr.univ_nancy2.gest;
public interface IVerifINE
extends java.rmi.Remote {
public java.lang.String verifINE(java.lang.String ACode_INE) throws java.rmi.RemoteException;
}
- on invoque ensuite le service-web comme suit (le programme s'appelle avec
2 arguments : le fichier WSDL et le code INE à vérifier) :
import org.apache.wsif.WSIFService;
import org.apache.wsif.WSIFServiceFactory;
import org.apache.wsif.WSIFException;
import java.rmi.RemoteException;
import org.tempuri.IVerifINE;
public class Run {
public static void main(String[]
args) {
try {
if (args.length != 2) {
System.exit(1);
}
// create a service factory
WSIFServiceFactory factory = WSIFServiceFactory.newInstance();
// parse WSDL
WSIFService service = factory.getService( args[0], null, null, "http://gest.univ-nancy2.fr/ws-bin/VerifINE/",
"IVerifINE");
// create the stub
IVerifINE stub = (IVerifINE) service.getStub( IVerifINE.class);
// do the invocation
java.lang.String res= stub.verifINE(args[1]);
System.out.println(res);
} catch (WSIFException we)
{
System.out.println( "Error while executing sample, received an exception
from WSIF; details:");
we.printStackTrace();
} catch (RemoteException re) {
System.out.println( "Error while executing sample, received an exception
due to remote invocation; details:");
re.printStackTrace();
} } }
Conception d'un service-web en PHP
- Utilisation de la librairie PEAR::SOAP
- Visiblement avec les web-services on commence à toucher les limites
de PHP par rapport à la plate-forme Java. Les outils pour PHP et
la qualité de ceux-ci pour la mise en oeuvre des services-web sont
vraiment très éloignés de ce qui est proposé pour
Java.
- Toutefois, comme il y a un existant PHP, autant essayer de l'exploiter.
- voir ici pour une explication détaillée.
Conception d'un service-web en ASP
Sources
Services Web Open Source chez Wrox
Services Web avec SOAP, WSDL, UDDI, ebXML chez Eyrolles
Developping Java Web Services chez Wiley