Premier véritable banc d’essai consacré aux services web, le comparatif réalisé par la rédaction en collaboration avec Cosmosbay met en évidence leur facilité de mise en ?”uvre et leur réelle interopérabilité. Des performances dues en partie à l’adoption des standards tels que Soap (Simple object access protocol), XML et HTTP.Si leur utilité s’avère confirmée par le marché, les projets ne fleurissent pas aussi rapidement dans les entreprises. Afin d’aider les choix, quatre outils de développement ont été passés au crible. Parmi eux, figurent trois offres commerciales BEA WebLogic 7, IBM WebSphere 4 et Microsoft.Net, ainsi que le logiciel libre Apache Axis b3. L’état d’avancement de ces plates-formes, leur interopérabilité et l’adéquation de leurs capacités techniques avec les outils de développement proposés par les éditeurs eux-mêmes ont été évalués par Jean-Louis Vila, consultant technique chez Cosmosba, société de conseil en développement d’entreprises et intégrateur de solutions e-business et CRM.
Une interopérabilité assurée par tous
À l’issue des tests, ces quatre logiciels ont rassuré quant à leur interopérabilité. Et même si certaines des briques technologiques ne sont pas encore totalement finalisées, les spécifications existantes autorisent déjà une mise en production industrielle. Seule la version Apache Axis b3 est une bêta et non un produit final. Cette mouture se destine donc plutôt à des programmeurs chevronnés.En raison de la disparité des besoins, il est difficile de recommander un outil en particulier. Ce banc d’essai présente, pour chaque critère fonctionnel, les avantages et les inconvénients des produits sélectionnés. Cinq couches ont été identifiées : le développement des interfaces clients ; l’orchestration des processus métiers et la gestion des transactions ; les registres qui regroupent les annuaires des services ainsi que la gestion de leur cycle de vie ; les composants servant à la conception et à la réalisation de services métiers ; et enfin, la communication, où se trouvent les services de transport et de sécurité.Lorsqu’un client appelle un service web, il lance la recherche d’un service dans un annuaire UDDI, récupère le fichier de description WSDL (Web services description language), puis génère un proxy client et le teste. Cette procédure reste très complexe à écrire et risque de rebuter nombre de programmeurs. Les éditeurs ont donc doté leurs logiciels d’assistants dédiés. Seul Apache Axis b3, qui n’a pas pour vocation d’être un produit final, ne dispose pas d’un tel outil.Avec les autres logiciels, le proxy client est constitué d’une ou de plusieurs classes faciles à utiliser, même pour un profane. Du côté de BEA Workshop, la page de test du service web donne accès à une bibliothèque Java contenant un proxy client correspondant au service web, ainsi qu’à une autre renfermant les packages techniques nécessaires à l’exécution du proxy client. Cette manière de procéder se révèle intéressante lorsque l’outil de développement n’autorise pas la génération d’un proxy client à partir d’un fichier WSDL ou lorsque l’on ne souhaite pas que chacun des développeurs génère son propre proxy.L’orchestration des transactions reste nécessaire pour automatiser les processus métiers intervenant entre les différents acteurs mis en relation. Certes, le besoin transactionnel existe pour ces processus, mais il n’est pas comparable à celui d’une base de données ou d’un système bancaire traditionnel. Pour cette raison, les services web doivent se doter de mécanismes d’orchestration adaptés et de modèles transactionnels compatibles avec la nature découplée et asynchrone des échanges entre les partenaires. Les logiciels capables de gérer les processus transactionnels ne sont pas présents dans les ateliers de développement mais dans des outils annexes. BEA Workshop propose une gestion de conversation bâtie sur une proposition d’extension Soap, qui vise à gérer les corrélations de messages et les états de la conversation. Ce mode de fonctionnement diminue son intérêt.Le rôle d’un fournisseur de services consiste à publier une interface de connexion via un fichier de description WSDL. Le développement des interfaces clients s’effectue soit en Top-down, une approche qui part de l’interface pour arriver à l’implémentation, soit en Bottom-up, qui va dans l’autre sens. Pour les nouveaux composants, mieux vaut privilégier la première afin d’exprimer le besoin via l’interface, sans se préoccuper de la façon dont le composant sera élaboré. Si les composants métiers existent déjà, nous recommandons la seconde pour notamment la publication via un wrapping.
Les 4 solutions assurent la conception de services
La conception des services web est aujourd’hui partie intégrante des ateliers de développement. Mais si l’ensemble des éditeurs dispose d’outils de conception dédiés, tous ne sont pas au même niveau. Cependant, toutes les offres testées assurent le développement d’un service web et génèrent le fichier WSDL correspondant.La couche communication prend en charge les aspects relatifs au traitement des messages, en mode RPC (Remote procedure call) ou en mode Message/Document. Avec RPC, le service web s’apparente au modèle d’objet distribué traditionnel. La communication entre le client et le service web est centrée sur l’interface, ce qui introduit de fait un couplage. Ce mode s’appuie sur un modèle requête-réponse synchrone. Avec le mode Message/Document, la communication est considérée comme une standardisation de l’échange de documents. Le client et le service web ne sont couplés que par l’utilisation d’un format XML commun et par le protocole de transport utilisé. Le mode Message autorise le fonctionnement synchrone ou asynchrone. L’ensemble des plates-formes testées gère les deux. Dans la version actuelle de Microsoft.Net, Soap avec attachement Mime (Multipurpose internet mail extension) n’est pas pris en compte, mais les éditions futures supporteront Dime (Direct internet message encapsulation). La prise en charge des services web dans WebSphere s’effectue par une version revue d’Apache Soap 2.2 et s’appuiera, dans plus tard, sur les évolutions d’Apache Axis, avec lequel les spécificités relatives au transport restent celles du serveur d’applications.La sécurité est gérée au niveau de la couche communication. Elle concerne l’authentification, l’autorisation, la confidentialité, l’intégrité et la non-répudiation. Cependant, les solutions testées montrent une grande disparité. Sur l’authentification et l’autorisation, l’architecture pipeline d’Apache Axis, séduisante, favorise le traitement spécifique d’un message Soap par une chaîne d’opérations. Entre autres, elle effectue les tâches d’authentification et d’autorisation en cascade avant d’invoquer le service métier. Cela découple les problématiques d’infrastructure avec les traitements métiers. De plus, le pipeline force l’adoption d’un modèle modulaire qui accepte les évolutions des spécifications sans remettre en cause l’architecture de la plate-forme.Le framework.Net possède une caractéristique novatrice d’extension par les mécanismes de Custom Attributes. L’exposition d’une méthode d’un objet service web s’effectue ainsi par ce mécanisme. Ces extensions offrent un avantage certain qui apporte à la plate-forme.Net une évolutivité indéniable. Néanmoins, cela impose de spécifier les caractéristiques du service web au sein même du code, d’où une corrélation entre les aspects métiers et l’infrastructure. Ce mélange n’offre pas de solution cohérente. Même si la sécurité n’est pas aboutie, les différentes implémentations de la spécification Soap, du moins dans sa version 1.1, sont maintenant suffisamment stables pour être utilisées en production.Apache Axis/Apache Tomcat fournit un ensemble d’utilitaires, destiné à réaliser toutes les étapes de la conception. Ce logiciel libre est présent dans un grand nombre de solutions de développement. Associé à un JDK (Java development kit), il ne nécessite aucune autre librairie. L’écriture d’un fichier JWS (Java web service), compilé à la volée comme une page JSP (Java server pages), bien qu’intéressante, trouve ses limites dans le manque de paramétrage.
Revue de détail des toolkits
IBM WebSphere Developer Studio, quant à lui, s’articule autour du package Apache Soap 2. Les assistants, bien que performants, ne masquent pas toujours la technique. Les versions suivantes pallieront certainement ces quelques défauts par le recours à Apache Axis, déjà utilisé dans IBM Web Service Toolkit 3.1.De son côté, Microsoft Visual Studio.Net dispose d’un assistant qui crée, en très peu d’actions, un service web. Une fois compilés, le service web et son fichier WSDL conçu dynamiquement sont disponibles immédiatement. Cependant, nombre de services web développés avec Microsoft.Net sont en style Document. La modification du style ou de tout autre paramètre du fichier WSDL nécessite en effet l’ajout d’un ensemble de Custom Attributes, alors qu’il n’existe aucun assistant pour cela.Enfin, BEA Workshop ne constitue pas un outil de développement traditionnel, mais un atelier spécifiquement dédié aux services web. Il s’adresse à une large majorité de développeurs non spécialistes des technologies utilisées. La matérialisation graphique du service web et les méthodes sont clairement exposées avec les contrôles, lesquels se révèlent très bien exploités, bien que ne représentant pas une nouveauté en terme de composant wrapper. Seul reproche, la spécialisation de cet atelier logiciel sur les services web oblige les programmeurs à recourir à un atelier de développement traditionnel.Pour évaluer les logiciels, Cosmosbay a développé deux services web visant à obtenir la température en fonction d’une ville et d’une date donnée. L’un repose sur le mode RPC avec l’encodage XML Schema, l’autre sur le mode Document.
Un bilan plutôt satisfaisant
Leur écriture n’a posé aucun problème majeur. Néanmoins, il s’avère plus facile de concevoir des services web en mode RPC avec IBM Developer Studio ou Apache Axis, et des services web en mode Document avec Microsoft.Net. Orienté service, BEA Workshop bénéficie d’une approche cohérente ; il est tout aussi simple de basculer d’un style RPC à un style Document par sélection dans une liste.Tous les fichiers WSDL générés pour les deux services web de lecture de la température se révèlent quasiment identiques, ce qui atteste d’une certaine maturité des solutions. Tous les ateliers savent naviguer au sein d’un registre UDDI et y publier une description.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
