Concevoir des services Web facilement en Java: XFire, la solution?

Concevoir des services Web facilement en Java: XFire, la solution?



La mise en œuvre de services Web avec Java se montre souvent complexe. Grâce à l'évolution constante des implémentations Open Source, le développeur a aujourd'hui accès à des outils légers, élégants et faciles à utiliser.
(09/11/2006)

Prolégomènes
Les services Web sont incontournables. On les trouve aujourd’hui dans la plupart des applications informatiques distribuées : Internet, téléphones mobiles, vous les utilisez sans même vous en rendre compte – sur Google par exemple pour vous informer de la météo ou de l’état du trafic sur le périphérique. Mais au fond, de quoi parle-t-on ?

Un service Web doit être vu comme un ensemble de protocoles et de normes informatiques pour l’échange de données entre les applications. Dès lors, des logiciels écrits dans des langages de programmation différents et fonctionnant sur des systèmes d’exploitation hétérogènes peuvent "communiquer" les uns avec les autres et s’échanger des données à travers des réseaux informatiques comme Internet. C’est ce qu’on appelle l’interopérabilité. Cette dernière est rendue possible grâce à l’utilisation de normes ouvertes regroupées au sein du terme générique SOA (pour Service Oriented Architecture ou Architecture Orientée Service en français).

Les points forts des services Web se résument donc à l’interopérabilité qu’ils rendent possible entre divers logiciels fonctionnant sur des plates-formes hétérogènes, mais aussi à l’utilisation de standards et de protocoles ouverts. Ces derniers, ainsi que les formats de données, sont au format texte dans la mesure du possible, ce qui facilite grandement la compréhension du fonctionnement global des échanges.

Un autre avantage des services Web est qu’ils utilisent le protocole HTTP et donc le port 80 par défaut, ce qui permet d’éviter des dysfonctionnements quand il s’agit de passer au travers de nombreux pare feu. Avec HTTP, nul besoin de changement sur les règles de filtrage.
Retours d'expérience et état des lieux

Le cas Java
Les services Web sont utilisés depuis plusieurs années, mais ils présentent toujours des inconvénients majeurs. Il ne sera pas question ici de limitation d’ordre fonctionnel, mais plutôt de difficultés de mise en œuvre.

Tout d’abord, dans le monde Java, sont proposés de nombreux – et même de trop nombreux – environnements d’exécution pour services Web, ce qui ne facilite pas toujours le choix de l’architecte logiciel. Citons, parmi les plus connus, Axis du projet Apache, JWSDP de Sun, WebLogic de BEA, WebSphere d’IBM, etc.

Cette multiplication des environnements est représentative des succès de cette technologie mais également de ses faiblesses. En effet, chacun d’eux possède son propre mode de fonctionnement et un spécialiste des services Web sous Axis peut se perdre lorsqu’il s’agit de faire la même chose sous WebLogic, et inversement. Si de nombreux standards définissent le mode de fonctionnement des services Web, il n’y en a aucun qui définisse un moyen unique pour les implémenter.

Les moteurs d’exécution actuels pour services Web en Java souffrent d’un modèle de programmation complexe. Pour preuve, au lieu de se concentrer sur la logique métier, le développeur doit gérer les différents aspects techniques comme l’accès distant, la gestion des exceptions et le cycle de vie du dit service. Il doit par exemple proposer de nombreuses implémentations même pour un service simple, un document WSDL verbeux (fichier XML qui décrit les méthodes métiers rendues par le service Web) ainsi que plusieurs descripteurs de déploiement qui dépendent du serveur d’applications utilisé (quid de la portabilité ?). Certains, comme Sun dans son serveur d’application J2EE SAS 1.4 ou BEA avec WebLogic, vont même jusqu’à proposer des passerelles Web Services / EJB pour pouvoir travailler avec les services Web alors que les EJB sont bien connus pour leur complexité.

De ce fait, les environnements d’exécution pour services Web en Java sont difficiles à configurer, à maîtriser et il faut souvent compter plusieurs heures pour déployer le moindre petit service Web. Certes, il existe des outils (tâches Ant avec Axis) qui facilitent grandement le travail mais ces derniers restent complexes dans leur utilisation et le travail qu’ils accomplissent n’est pas toujours à la hauteur - problèmes d’optimisation du code par exemple.

Le cas particulier : .Net
Microsoft a su, en revanche, proposer une vision très simplifiée des services Web pour le développeur. En .Net, il n’existe qu’un seul environnement d’exécution à savoir le couple IIS / ASP.Net.

Avec cette technologie, le développeur n’a aucun fichier WSDL à fournir. De plus, il suffit pour le développeur de créer une classe, et surtout une seule, héritant de WebService et le tour est joué.

Lors du prochain démarrage de l’application, non seulement, le service Web se déploie automatiquement - génération du WSDL de manière dynamique grâce au mécanisme d’introspection automatique des classes -, mais un client de test est automatiquement généré pour tester le service fraîchement déployé.

Le seul problème que l’on peut reprocher à .Net est sa compatibilité limitée avec d’autres environnements d’exécution Java surtout lorsqu’il s’agit de travailler avec des valeurs null.

Java peut donc sembler avoir un temps de retard comparé à .Net pour tout ce qui touche de près ou de loin aux services Web. Et pourtant…

XFire, la solution ?
XFire est un projet Open source de la communauté CodeHaus, disponible à l’adresse http://xfire.codehaus.org.

Il représente une implémentation SOAP en Java aussi performante que simple d’utilisation, se basant sur une approche dite "document" au lieu d'équivalents comme Axis qui proposent une approche JAX-RPC, souvent responsable de goulots d’étranglement concernant l’utilisation réseau.

Comme .Net, XFire utilise la réflexion pour générer à la volée un service Web. Il ne nécessite aucun outil spécifique pour cette génération, à la différence de la plupart des solutions concurrentes déjà citées précédemment (tâches Ant pour Axis par exemple). De plus, XFire est 100% compatible Axis et .Net.

Pour développer un service Web avec XFire, il suffit de créer une interface listant les méthodes métiers accessibles à distance ainsi qu’un simple JavaBean implémentant les méthodes métiers de l’interface.

Aucun descripteur de déploiement spécifique n’est à fournir et encore moins de fichier WSDL, ce dernier étant généré à la volée, comme c’est le cas de .Net.

Pour un utilisateur Java, XFire permet donc de réaliser extrêmement facilement des services Web. Mais XFire ne s’arrête pas là. En effet, ce dernier propose une intégration complète au Framework Spring bien connu des développeurs Web Java/J2EE tout en proposant des temps de réponse moyens inférieurs à 30 millisecondes.

Certains benchmarks, comme celui effectué par Tim Pokorny, montrent que la comparaison avec Axis dans cet exemple est sans appel :
- 80 requêtes et réponses par seconde pour des messages ne dépassant pas 4 ko ;
- Une utilisation du CPU réduite qui ne dépasse pas les 50% côté serveur ;
- Une comparaison avec Axis (le plus largement utilisé dans le monde Java) qui montre que ce dernier ne dépasse pas plus de 8 messages par seconde.

Un autre benchmark apporte lui-aussi des éléments intéressants :
- XFire se montre entre deux et six fois plus rapide qu’Axis 1.3 ;
- La latence est réduite de 50 à 80 % avec XFire par rapport à Axis 1.3.

De bons présages pour le futur...
Java semble donc rattraper son retard par rapport à .Net grâce à XFire. De plus, XFire est compatible avec la JSR 181 qui consiste à utiliser les annotations Java 5 pour configurer encore plus simplement le déploiement d’un service Web.

Cette spécification sera intégrée dans la prochaine version de Java et il sera même possible de concevoir des services Web nativement dans Java 6 SE.

Il y a fort à parier que Sun s’inspire des travaux réalisés par la communauté pour intégrer cette nouveauté et que l’équipe XFire y sera mise à contribution comme ce fut le cas avec Gavin King (créateur de la solution de persistance Hibernate) et la spécification des EJB 3.0.Etude menée sur la base des travaux de Sébastien Hébert, Architecte Netapsys


Source:
http://www.journaldunet.com/developpeur/expert/6368/concevoir-des-services-web-facilement-en-java--xfire--la-solution.shtml