Les Web Services

Généralité

Ces dernière années ont vus l'émergence d'un nouveau type d'appel distant s'appuyant sur le protocole HTTP : Les Web Services . Ils permettent de réaliser des appels distants de manière standard et simple.

Bien que, ces aspects sont abordés par CORBA et RMI, la complexité de ces protocoles les a réservés à des applications très techniques. Les Web Services, en revanche sont facile à mettre en oeuvre .

Les services Web permettent de traiter les requêtes synchrones. Fonctionnement, un Web Service est comme un Call mais ses fonctions de sérialisation et de transport sont réalisées à l'aide des protocole HTTP et SOAP et non plus en utilisant une méthode propriétaire. Initié par Microsoft, SOAP (Simple Object Access Protocol) fournissait un cadre pour une généraliser les opérations de Call en utilisant le XML. Le Web Service ajoute les bénéfices du HTTP à SOAP. Le Web Service possède donc les qualités ces protocoles.

• La robustesse de HTTP
• L’interopérabilité du XML
• Les réalisations de Web Service sont indépendantes du système d'exploitation et du langage de programmation utilisé.

A l'aide de son langage de description (WSDL), il permet de faciliter les échanges de données. Il permet également la communication normalisée entre les applications au sein des entreprises et entre les entreprises. Le langage de description de WebService : le WSDL (Web Service Deploiement Langage) permet de décrire un Web Service.

Il convient de bien comprendre les atouts qui ont fait le succès des Services Web et pour savoir les utiliser à bon escient.

• Ils s’appuient sur le protocole le plus robuste de tous les réseau : HTTP
• Ils ne sont pas propre à un langage en particulier et sont formalisé par un standard
• Ils proposent un langage de description de service (Descripteur simples à comprendre)
• Ils sont à la mode et dispose donc d'un support important
  

Prérequis technique

Pour utiliser des services Web, il faut d'abord un serveur d'application et d'un moteur de Web Service. En java, les implémentations incontournables sont

• AXIS implémentation libre sous licence apache
  
• Websphere
  
• WebLogic

Le rôle de ce composant est de répondre au requêtes HTTP en les transformant en appel d'un efonction JAVA.

Dans le cadre d’un développement de Service-Web il est recommandé de n’avoir aucune interface visuelle dans la Webapp.

Utilisation des service Web

Le « Service Web » est utilisé pour retourner le résultat d'une fonction de traitement d'un objet Métier. Concrètement, vous n'aurez pas à modifier vos anciens développements pour transformer votre classe métier en service Web car vous utiliserez les Web Services comme une surcouche. Cela permet d’éviter les re-développement de l'application.

Une bonne pratique consiste à ne pas appeler directement les classes métiers mais en passant par des «Classes Façades » qui permettent de définir clairement quelles sont les méthodes de accessibles par le Web.

Avantages

Dans les systèmes d'information, il est fréquent de voir des réseaux se modifier, soit du point de vue des machines soit du point de l'architecture. Le service Web est alors idéal car il ne nécéssite que peut de développement pour être mis en place autour d'une ancienne architecture et garanti un agencement très souple de l'architecture.

Bien souvent, vous mettrez en comparaison les Web Service avec des appels RMI car la fonction première du RMI (Remote Method Invocation) est la même que les services WEB.

RMI	Web Service
Faible interropérabilité	Forte interropérabilité
Cout de traitement 2/3 moins élevé que le Web Service	Cout processeur élevé
Transmet l'état de l'objet	L'état de l'objets doit être transmis en paramètre.
Complexe à mettre en ouvre	Simple à mettre en oeuvre
Protocole nécessitant une forte cohérence des unités de traitement entre elle. (Quand un composant ne fonctionne plus plus rien ne fonctionne)	Protocole robuste.
Difficile à optimiser	Plus simple à optimiser.

Dans les pages précédentes j'ai souvent affirmé que la performance d'une méthode dépendait de l'intelligence de la programmation. Il en va de même pour les services Web, même s'ils sont réellement plus coûteux que des appels RMI, il sont plus simples à étudier et donc à optimiser.

Si vos machines ne se trouvent pas dans un même endroit, il n'est pas nécessaire de se poser de question c'est le Web Service qu'il faudra choisir. Dans le cas contraire, pour contrebalancer le couts des appels au Web Service il faut tout simplement diminuer le nombre des appels et augmenter la granularité.

En un mot, toute la richesse du Web Service réside dans sa simplicité et son interopérabilité. Ces qualités doivent être préservées.

Ce que ne sont pas les Web Services / Inconvénients

Les Web Services ne sont pas une méthodologie de développement de services utilisée dans le Web. En clair, ce n’est pas parce que votre service est utilisé dans une page Web qu’il doit utiliser un Web Service.

En outre, les services Web ne sont pas appropriés pour tous les types de traitements.Ils ne concernent qu’une sous classe de service (Qu’on appelle les services sans état – stateless ) :

• Ne les utilisez pas pour des processus asynchrones.
• Ne les utilisez pas pour des fonctions qui doivent être fréquemment appelées

Enfin, il faut signaler que les Web Services sont à la mode et plus ou moins succeptible d'être assaisonés à toutes les sauces. A vous de voir...

Le plus simple des services Web

Le plus simple des services web est une simple classe JAVA que l'on utilise avec l'extension JWS (Java Web Service) et qui se place dans un repertoire de la WebApp. On peut alors directement appeler les service en question par un Call. Vous programmer donc une fonction Web de la même manière qu'une JSP. Le fin du fin étant qu'elle peut être compilée à la volée.

Architecture

L'architecture des applications

Par rapport aux applications standard l'architecture d'une service web est un petit peu différente, en effet, il est possible de déployer un service web unitairement. Par conséquent il est envisagable de n'avoir qu'un seul moteur de service Web.

Supposons que vous ayez deux applications Web : une application de facturation et une application pour les payes. Ces WS sont appeléspar une troisième application extérieure. La première tendance sera de rajouter à chaque application un moteur de service web. Cette solution n'est pas mauvaise, toutefois elle presente l'inconvénient de caler le cycle de vie de l'application de Service Web sur le cycle de vie de l'application Web IHM. Généralement les services Web sont appelés à partir de traitements batch. Ceci a pour conséquence de rendre interdépendantes au panne et maintenance l'application WebService de l'application IHM. Il vous faudra donc faire un arbitrage entre le degré d'interconnexion entre le service Web et l'application et la tolérance au pannes que vous souhaitez assurer.

Ces trois possibilités sont détaillées dans le schéma ci dessous.Les grand rectangles représentent les application.

La mécanique interne d’un service Web

Pour utiliser un service Web il faut réaliser les 5 couches techniques que l'on voit sur le dessin ci dessous. Nous n'évoquerons pas la partie Métier du coté du serveur car elle est complètement dépendante de la problématique.

• Configurer le dispatcher : C'est ici que nous décrivons notre service Web à partir du langage de description de service web WSDL.
• Couche de Médiation : Elle nous permet d'écrire notre requête directement à partir du code JAVA sans avoir une seule ligne de XML à taper. Ces médiateurs sont générés automatiquement à partir du fichier WSDD.Nous le verrons dans le chapitre suivant
• Les façades : Il s'agit de l'opération qui consiste à utiliser les classes métier. Dans les facades on doit gérer les instanciations des classes métier.

Préparer votre classe métier

Vous avez le choix dans les réponses que le web service vous retournera après son appel, ce peut être des type simples comme int ou double, mais le plus souvent vous souhaiterez faire transiter des type structurés (des beans). Cependant, les web service ne permettent pas de sérialiser et de désérialiser des types aussi complexes que l'on pourrait le souhaiter. Par exemple les interfaces java.util.Set ne sont pas sérialisables dans les web service et il est nécessaire de passer par une étape intermédiaire.

Lorsque vous créez votre web service à partir d'une classe métier, il vaut mieux faire intervenir une classe façade qui au lieu de retourner des beans complexe qui intègre de la logique métier ne retournera que des beans stricto senso qui seront des copies de vos bean métiers qui leur enlève le superflux.

On a donc trois opérations pour créer notre façade :

• Créer des beans de retour allégés
• Créer des beans de paramètres allégés
• Créer la méthode façade acceptant ces beans

Les utilitaires vont générer un WSDL qui comportera les informations qui permettront d'enrichir le bean des méthodes qui permettront la sérialisation. Il existe deux méthodes pour enrichir le bean, soit on utilise des classes qui manipuleront le bean pour le remplir, c'est cette méthode qui est retenue par IBM, soit le code du bean est modifié, c'est cette philosophie qui est utilisée par Axis.

Création d'un fichier WSDL à partir d'une classe JAVA

Une fois que notre service est isolé à l'aide des façade, il est temps de créer le descripteur de Web Service. A partir de ce descripteur, nous allons enrichir le bean pour le rendre serialisable.

WSAD

Puis, sous WSAD c'est très simple, il suffit de se servir de l'assistant et de se laisser guider.

Dans cet environnement, les classes de médiation sont appelée proxy. Vous devez choisir votre implémentation, selectionner la classe que vous souhaitez transformer en WebService. Attention, dans les premières versions de WSAD, ce n'est pas très fiable.

Axis et Eclipse

Axis nous fournit des utilitaires qui permettent de générer le WSDL.

% java org.apache.axis.wsdl.Java2WSDL -o wp.wsdl -l"http://localhost:8080/axis/services/WidgetPrice"
-n "urn:Example6" -p"samples.userguide.example6" "urn:Example6" samples.userguide.example6.WidgetPrice

où

• -o indique le nom du fichier de sortie
• -l indique l'endroit ou est rendu le service ( Notez qu'à l'interieur d'un web service nous avons des information qui sont propore au serveur.
• -n est l'espace de nommage du WSDL cible
• -p indicates a mapping from the package to a namespace. There may be multiple mappings.
  the class specified contains the interface of the webservice.

Nous générons un fichier WSDL qui décrit la signature de la méthode ainsi que le serveur qui rend ce service. En parcourant ce fichier on voit qu'il contient les informations

• La première partie types contient la description des Types (Bean de paramètre et de résultats qui seront utilisés dans notre WebService.
• La deuxième partie comporte la structure des messages.
• La troisième partie comporte les bindings.Qui représente les fonctions accessible par notre service.
• La quatrième partie nous présente la liste des services chaque service est rattaché à une URL.

Appel de Web Service

Nous avons deux possibilités pour tester un service web que nous avons déployé sur le serveur :

• Utiliser le client de test fourni par WSAD et accessible par un click droit sur un WSDL
• Générer automatiquement les classes de proxy à partir du WSDL et les utiliser

WSAD propose un assistant pour vous aider à construire des clients de WebService à partir de
Descripteurs de Web Service (Fichier aux extensions .wsdl ). Le WSDL comprend des informations de :

• Définition de Schéma de message.
• Point d’appel (EndPoint)

Le produit de cette opération est une série de classes qui vous permettrons d’appeler les services Web et de reconstruire un objet à partir d’un flux.

Penser au moment de livrer le wsdl à remplacer l’adresse ‘localhost :9080’ par le nom ou l’adresse IP du serveur sur lequel le service est déployé.

La génération des classes de médiation

Vocabulaire :

Binding désigne en anglais un lien entre deux choses, c'est précisement ce qu'il fait : Il vous permet de relier votre code java au web service en ignorant le fonctionnement d'une web service. C'est souvent bien utile. En pratique on se sert pratiquement toujours des bindings.

Les binding sont générés en même temps que sont généré vos bean enrichis.Alors utilisez les !

Cas d'école :

Etudions le descripteur de déploiement des WebServices fournis par google : GoogleSearch.wsdl. Nous y voyons le schéma du Web Service. A partir de ce schéma, il nous est possible de générer les classes qui permettrons d'appeler ce service sans que jamais nous n'ayons besoin de coder nous même les fonctions d'appel. Il faut comprendre que les bean enrichis doivent être présent non seulement du coté serveur mais également du coté client.

Voici la ligne de commande utilisée pour axis

java org.apache.axis.wsdl.WSDL2Java -o src -d Session -s -S true -Nurn:Matrix matrix.ws wp.wsdl

Déploiement

Il nous reste ensuite à générer les fichiers de déploiement, ces fichiers seront utiles pour informer le dispatcher des services qu'il doit rendre. C'est le seul lien qui exite entre la classe JAVA que vous avez créer et votre dipatcher de requête. Sans le savoir vous les avez déjà générés, ce sont les fichiers deploy.wsdl et undeploy.wsdl qui se trouvent au même endroit que vos dindings.

Table d’association des type JAVA->SOAP

Vous pouvez vous servir de ce tableau pour comprendre ce qui est décrit par votre WSDL.

xsd :base64Binary	byte[]
xsd:boolean	boolean
xsd:byte	byte
xsd:dateTime	java.util.Calendar
xsd:decimal	java.math.BigDecimal
xsd:double	double
xsd:float	float
xsd:hexBinary	byte[]
xsd:int	int
xsd:integer	java.math.BigInteger
xsd:long	long
xsd:QName	javax.xml.namespace.QName
xsd:short	short
xsd:string	java.lang.String

Et l'interropérabilité ?

Dans certaine entreprise des petites applications ont parfois des besoins d'appeler des services qui sont déjà disponibles sur d'autre serveurs. Les WS seront intéressant pour faire communiquer une application PHP et JAVA.

• JAVA
• C++
• Perl / Python etc.
• Rebol
• PHP