http://www.01net.com
L'ÉVÉNEMENT
Services web : les entreprises appliquent l'idée... sans les standards

Marie Varandat
, 01 Informatique, le 28/11/2003 à 00h00

Confrontés à la réflexion sur les coûts de mise en oeuvre, les avantages du couple WSDL/Soap cèdent du terrain face à l'approche XML/HTTP, moins standard, mais plus réaliste.

C'est vrai pour toute jeune technologie : les entreprises procèdent d'abord à un round d'observation avant de céder à leurs belles sirènes. Les services web n'ont pas fait exception. Mais, après la prudence, le temps est venu de leurs premiers déploiements dans les entreprises françaises. Tel est le constat dont s'est fait l'écho le salon Intégration 2003, Forum XML et Web Services. Dans ce cadre, les applications de Printemps.com , de Sandvik et de Mondial Assistance font preuve d'un même pragmatisme vis-à-vis des services web. Ces entreprises ont, en effet, retenu les deux caractères fondamentaux de ces technologies : le métalangage XML pour décrire les données, combiné à des mécanismes d'appel à distance pour dialoguer avec d'autres systèmes. Reste qu'elles mettent à profit ces vertus sans forcément s'embarrasser des standards idoines.

S'adapter en priorité à l'architecture de son partenaire

La sécurité des échanges n'est pas en cause, car elles utiliseraient alors les services web en interne, là où les échanges sont protégés. Or, en interne aussi, elles préfèrent le couple XML/HTTP à la paire WSDL/Soap pour éviter le développement d'interfaces spécifiques entre leurs applications. Pour autant, ces entreprises ne rejettent pas les normes des services web. Elles en attendent même beaucoup pour gagner en coûts et en délais de développement. Mais pas en interne, où, apparemment, Soap ne présente pas suffisamment d'avantages pour justifier une mise à jour de l'existant. Et pas encore avec l'extérieur, car imposer aujourd'hui des échanges en services web, c'est prendre le risque de se couper de partenaires qui, pour la plupart, ne sont pas équipés d'architectures compatibles.

En standardisant les méthodes d'invocation et les échanges, les services web favorisent une réduction significative des délais et des coûts de développement. Cependant, en raison de la jeunesse des technologies, peu d'entreprises disposent d'une infrastructure adéquate. Les pionnières sont donc confrontées à un dilemme : imposer au partenaire le déploiement d'une architecture compatible WSDL/Soap ou s'adapter à son existant, tout en tirant les bénéfices des avantages du XML pour limiter les développements.

Dilemme que Printemps.com a résolu par une approche pragmatique. Basée sur.Net, son architecture a été conçue pour gérer tous les sites du groupe et faciliter la création d'opérations avec des partenaires. Par exemple, l'achat de fleurs sur un site, dont le montant serait débité sur la carte de paiement du Printemps. « Si nous avions dû développer des interfaces point à point avec nos partenaires, les surcoûts et les délais en développement se seraient révélés prohibitifs, explique Benoît Rigaut, directeur technique de Printemps.com . Nous comptons beaucoup sur les services web pour limiter les développements et étendre notre réseau de partenaires. Mais, en attendant, nous nous adaptons à leur système en leur proposant une solution souple et ouverte. » Pour l'heure, un seul de ces partenariats repose sur une procédure d'invocation en Soap, le restant étant effectué par transfert de messages XML sur HTTP.

XML/HTTP, moins standard mais plus ouvert

Une approche également retenue par Mondial Assistance, dont les échanges sont réalisés en XML-RPC ­ spécification qui prévoit l'utilisation de HTTP et XML pour effectuer des appels de fonctions à distance. Développé avec Eclipse et s'appuyant uniquement sur des briques open source ­ Tomcat, Apache et Linux ­, le projet est destiné à la vente d'assurances de voyages sur des sites partenaires ou en agence. Objectif : éviter au client ou à l'agent les ressaisies d'informations. Toutes les conditions du voyage sont ainsi automatiquement transmises à Mondial Assistance, qui peut alors proposer une assurance adaptée. Au passage, les traitements sont enregistrés et historisés afin de faciliter ensuite le calcul des commissions.

Décrites en XML, les informations et requêtes peuvent être interprétées par n'importe quel système. Côté partenaires, une « moulinette » suffit pour traduire le fichier XML dans un format de données adapté à son application. En s'appuyant sur XML, Mondial Assistance s'épargne les développements spécifiques pour dialoguer avec ses partenaires ­ sans leur imposer une technologie particulière. Raison qui l'a également conduit à préférer l'open source à la solution d'un éditeur. Si le partenaire souhaite héberger une partie de l'application ­ le calcul de la commission, par exemple ­, Mondial Assistance ne lui impose pas l'achat d'un serveur d'applications.

Si l'absence d'architectures compatibles WSDL/Soap constitue un frein pour les échanges avec l'extérieur, en interne le problème est d'ordre économique. L'utilisation de Soap pour dialoguer avec le back office suppose, en effet, l'ajout d'un proxy sur les sites centraux pour interpréter les enveloppes WSDL. Ajout qui va de pair avec une mise à jour de l'existant. Il implique donc des investissements importants, que les apports fonctionnels et techniques de Soap ne justifient pas si l'on s'arrête aux choix effectués par Printemps.com , Sandvik et Mondial Assistance. Bien qu'équipées d'infrastructures compatibles WSDL/Soap, ces trois sociétés ont, en effet, choisi de dialoguer avec leurs applications existantes, hébergées sur grand système, en XML et HTTP.

Tous les avantages de Soap sans les contraintes

Sandvik, spécialisée dans la machinerie et l'outillage industriel, s'appuie ainsi sur les outils de développement et le middleware EntireX, de Software AG, pour extraire des informations de son progiciel de gestion intégré et les véhiculer vers la plate-forme.Net, hébergée à son siège, en Suède. Laquelle transforme ensuite les informations en services web pour dialoguer avec les places de marché et autres partenaires de la société. « Les services web constituent réellement une évolution importante, qui facilite les échanges avec nos partenaires. Mais pas à notre niveau, où l'envoi de messages XML s'avère largement suffisant » , explique Philippe Lefaucheux, directeur informatique de la filiale française.

Même constat chez Mondial Assistance, où XML s'est imposé comme un langage descriptif permettant à chaque agence de comprendre et d'adapter les messages transmis par la plate-forme centrale. Laquelle peut ainsi dialoguer avec des systèmes hétérogènes, répartis à travers le monde. Au Printemps, « dès le départ, notre volonté était de ne travailler qu'en IP pour éviter les dialogues sur protocole spécifique à chaque application, plus longs et coûteux à mettre en oeuvre, explique Benoît Rigaut. Les spécialistes de l'existant ont été chargés de nous fournir une API pour nous permettre de récupérer ces messages en XML via HTTP. Une approche qui favorise le découplage des technologies et des équipes, chacune travaillant sur son domaine de compétence. Découplage tellement réel que je serais bien incapable de dire en quoi les applications du groupe sont développées ! »

En d'autres termes, si le couple XML/HTTP implique légèrement plus de développements ­ moulinette de transformation ­ que l'utilisation des normes WSDL/Soap, il ne gêne pas le découplage des applications et favorise une ouverture des mainframes ­ et de l'existant en général ­ aux technologies du web. Le tout à moindre coût, et sans imposer de technologie spécifique. Dès lors, on peut sérieusement se demander si la vision idyllique d'une informatique parfaitement standardisée, parée pour n'importe quel type d'échange, comme celle prônée par les services web, a des chances de croiser un jour la réalité des entreprises.

Stratégie : des solutions peu intrusives pour exposer CICS en Soap

La plupart des données et processus de l'entreprise sont aujourd'hui enfermés dans des applications Cobol sur des mainframes. Pour dialoguer avec ses partenaires, rationaliser son système informatique, ou encore faire évoluer ses applications, la majorité des entreprises doit « ouvrir » ces grands systèmes. Dans ce cadre, les services web pourraient constituer une solution standardisée moins coûteuse que le développement d'interfaces spécifiques. Sauf que le déploiement d'un proxy Soap sur cet existant s'accompagne souvent d'une mise à jour onéreuse. Et que, à tort ou à raison, les spécialistes du mainframe détestent en général l'idée d'ouvrir leurs applications de production aux technologies d'internet, et encore plus celle d' « exposer » leurs données ou les transactions CICS.

C'est très probablement pour contourner ces freins économiques et psychologiques que des éditeurs comme Attachmate, Hostbridge, Wynsoft, ou encore Microsoft avec, respectivement, myExtra! Smart Connector for CICS 3270, Hostbridge, Tanit CICS et HIS (Host Integration Server) se sont orientés vers des solutions reposant sur un serveur intermédiaire. Ce dernier dialogue dans le protocole propriétaire avec le mainframe, récupère la transaction CICS, et l'enrobe ensuite d'une enveloppe WSDL pour l'exposer sous forme de service web. Lequel peut être invoqué en Soap. Ce fonctionnement présente l'avantage de ne pas être intrusif pour le mainframe, car il ne nécessite aucun déploiement, pas d'accès en IP...


Témoignages

Philippe Lefaucheux (Sandvik France) : « C'est avant tout XML qui compte »

« Nous utilisons depuis longtemps les technologies de l'EDI pour dialoguer avec nos différents partenaires. En termes de maturité, les services web sont encore très loin de l'EDI. Cependant, même en l'état, ils constituent une solution beaucoup plus facile à mettre en oeuvre et simplifient énormément les échanges entre sociétés. Plus que Soap ou que toute autre procédure d'invocation, c'est XML qui tient un rôle clé dans ce cadre, en permettant de décrire les données de façon à les rendre, par la suite, interprétables par tous nos partenaires. Et ce quelles que soient les technologies utilisées initialement par les applications. Notre progiciel de gestion intégré est conçu sur des technologies propriétaires. Mais cela ne nous empêche pas de transmettre des données en XML à notre siège, en Suède, qui se charge ensuite de les formater en services web. »

Benoît Rigaut (Printemps.com SA) : « La sécurité ne constitue pas un frein »

« Il est vrai qu'en début 2002 les standards ne proposaient pas encore vraiment de solutions pour sécuriser les échanges à l'aide des services web. Mais, pour nous, cela n'a jamais été un frein, car cette sécurité peut souvent être assurée au niveau de l'infrastructure réseaux. Et, lorsque ce n'est pas suffisant, rien n'empêche de faire du spécifique au sein d'une enveloppe Soap à l'aide d'algorithmes connus de chiffrement, tel Blowfish, ou d'authentification, comme HMacSHA1. Nous voulions profiter des services web sans attendre une standardisation de la sécurité. Depuis, le standard WS-Security s'est largement imposé. L'usage des services web s'avère, en revanche, moins mûr du point de vue de la fiabilité et de la gestion des contextes transactionnels. Le protocole HTTP n'assure pas de valeur ajoutée sur ce terrain, et les développements spécifiques sont trop importants pour contrebalancer les bénéfices des services web. »


Enquête : de moins en moins de réfractaires aux services web

Selon l'étude menée auprès de six cent dix entreprises à travers le monde et publiée au mois de février 2003 par le groupe SQLI, les services web continuent de susciter la curiosité des entreprises. Elles sont 26 % à avoir des projets en cours, contre 30 % l'an dernier, selon les résultats d'une même étude menée avec les mêmes critères. En 2003, 26 % d'entre elles réalisent des tests et des prototypes, contre 18 % un an plus tôt. Et si elles sont toujours pratiquement aussi nombreuses à s'interroger sur la meilleure approche à adopter pour implémenter des services web ­ 32 % en début 2002, contre 20 % un an plus tard ­, le pourcentage de ceux qui y sont réfractaires a, lui, fortement diminué ­ 11 % en 2003, contre 20 % en 2002.


Avis d'expert

Didier Girard (Improve) :« Tout repose sur la souplesse des architectures »

« La véritable valeur ajoutée des services web repose sur le couple WSDL/Soap. Faute de normes abouties ou implémentées, les entreprises nagent entre deux eaux. Et il faudra attendre encore quelques années avant que la situation n'évolue. En attendant, la réussite d'un projet dépend avant tout du poids de l'entreprise face à ses partenaires. Ou, en d'autres termes, de celle qui impose la pile des services web à utiliser ­ tant pour les spécifications que pour les versions des technologies. La meilleure approche, pour les sociétés qui ne peuvent se permettre d'imposer leurs versions des standards, consiste encore à opter pour une architecture souple, intégrant une couche d'interprétation qui leur permettra de s'adapter aux versions de leurs partenaires. »

Frédéric Bon (Clever Age) :« Soap, un truc de technophiles »

« Soap n'apporte rien d'un point de vue fonctionnel, et pas grand-chose sur le plan technique. Ce qui est important, c'est de pouvoir pratiquer l'appel de service à distance avec une mise en oeuvre facile du côté client. Son implémentation s'avère, certes, plus aisée que la mise en oeuvre de RPC, qui suppose un peu plus de développements. Mais elle n'est valable qu'entre deux entreprises ayant le même niveau technologique. Or, outre le fait que Soap souffre encore de trop nombreux manques ­ notamment sur les aspects transactionnels ­ pour être réellement utilisable, il en existe aujourd'hui différentes versions. Sans compter que chaque éditeur « personnalise » ce protocole pour l'optimiser. Résultat : même deux entreprises dotées d'une architecture compatible Soap ne sont pas assurées d'aboutir à des services web interopérables. »




    © 1999-2003, 01net.