L’interopérabilité entre systèmes a toujours constitué un frein aux échanges électroniques. À moins d’adhérer à une plate-forme fédératrice spécifique, tels les réseaux EDI, le dialogue entre applications hétérogènes nécessite de longs et onéreux développements, qu’il faut revoir et adapter à chaque fois qu’un nouveau partenaire se présente.L’avènement des services web marque un tournant décisif dans l’approche du problème. Plutôt que de chercher à uniformiser les systèmes, les services web s’adaptent à l’hétérogénéité de l’existant et favorisent une meilleure réactivité. Deux critères qui correspondent très exactement aux besoins des nouveaux modèles économiques du commerce électronique, qui nécessitent une très grande souplesse d’adaptation des systèmes informatiques.
L’uniformisation n’est pas la solution à l’interopérabilité
Avec internet, le commerce électronique a pris la forme d’échanges très évolutifs. Moins figés, les accords se nouent et se dénouent, et le délai d’intégration d’un nouveau partenaire devient critique. Avec les services web, l’hétérogénéité ne constitue plus un problème. Ils n’imposent en effet ni langage de programmation, ni application spécifique, ni architecture particulière.Chacun développe son système comme il l’entend (Cobol, C++ ou Java), avec la base de données X ou Y, le serveur d’application Z, etc. Les technologies propriétaires sont ensuite encapsulées dans des enveloppes de métadonnées qui décrivent les messages des applications afin de les rendre compréhensibles par les autres technologies propriétaires. Tout service offert par une application peut en effet être encapsulé dans une enveloppe de métadonnées en XML. Baptisée WSDL, cette enveloppe s’apparente à une API universelle qui publie de façon standardisée les méthodes d’appel du service.Avec WSDL et un mécanisme normalisé de type RPC s’appuyant sur le protocole Soap au-dessus de HTTP ou de SMTP, les applications disposent de toutes les informations nécessaires pour dialoguer, sans forcément partager de langage commun.Simple, le modèle des services web présente néanmoins des lacunes, notamment en matière de qualité de service (QoS) et de sécurité. Monolithiques, les applications existantes doivent en effet être découpées en services. Il faut que chaque fonction isolée réponde à un besoin d’ouverture du système à un partenaire, sans pour autant créer des brèches de sécurité et engendrer des pertes de performance.Or, comme toute application à base de composants distribués, plusieurs services web de granularité variable sont susceptibles d’être impliqués dans une même transaction. Ils peuvent être répartis sur différents serveurs, s’invoquer à travers un réseau local ou étendu entre plusieurs entreprises, servir à différentes applications, etc. Soit autant d’hypothèses et d’options qui doivent être prévues lors du découpage des fonctions, de façon à tenir compte des possibles réutilisations d’un même service web par plusieurs partenaires, de la charge CPU gérée par chaque machine, du trafic réseau, etc.En l’absence de solution de simulation, la tâche se révèle d’autant plus ardue que les protocoles HTTP et SMTP n’offrent pas la garantie de service nécessaire aux échanges B to B. Impossible en effet de vérifier qu’une commande est bien arrivée chez le partenaire, de savoir si une transaction bloque parce que le message n’a pas été délivré, parce que le service web invoqué à disparu ou plus simplement parce que le message s’est perdu dans les méandres du maillage d’internet.
Un modèle adopté par les entreprises
Plusieurs initiatives tentent de répondre à cela. En janvier dernier, BEA lançait BTP (Business Transaction Protocol), une norme pour les transactions couplées chargée de vérifier leur bonne exécution. Plus récemment, Sun, associé à BEA et à SAP, annonçait WSCI (Web Service Choreography Interface), une interface destinée à décrire les messages émis par un service web au sein d’un processus impliquant d’autres services web.IBM et Microsoft ne sont pas en reste, chacun proposant également d’enrichir les enveloppes Soap et WSDL, ou encore d’ajouter de nouvelles fonctions au proxy Soap ; ce dernier serait ainsi capable de s’assurer de la QoS des applications. Celle-ci pourrait également être prévue dans la modélisation des applications, des initiatives de normalisation des langages des outils de BPM (Business Process Management) prenant également en compte cette notion de QoS chez Microsoft (Xlang), chez IBM (WSFL) ou encore au sein du consortium BPMI (BPML). Loin d’être exhaustive, cette liste d’initiatives met en évidence la jeunesse et les lacunes des plates-formes des services web. Ce qui n’empêche pas les entreprises de se lancer dans la mise ?”uvre de ces nouvelles technologies.Selon une étude menée par le cabinet américain Evans Data, 98 % des responsables informatiques envisagent en effet de concevoir des applications s’appuyant sur les services web dans les deux années à venir et 75 % d’entre eux en utilisent déjà. En France, les expériences se multiplient : AlloResto a développé un service de réservation de tables à destination de ses partenaires (hôtels, agences de voyages, etc.) ; Air Liquide partage son savoir-faire métier avec ses clients via une plate-forme qui repose sur les services web ; le groupe Exclusive Hôtel gère ses réservations avec ses partenaires ; Inéas a créé un réseau de partenaires qui revendent ses produits d’assurances…Alors que le concept de services web doit son succès à la gestion de l’interopérabilité entre systèmes hétérogènes, principale problématique des échanges B to B, l’étude d’Evans Data estime que la plupart des projets actuels restent limités à l’usage interne. D’après le cabinet américain, seuls 15 % des projets relèvent en effet des échanges B to B. Les lacunes des services web en matière de sécurité freinent les entreprises et ne sont pas étrangères à cette estimation ; cette dernière est toutefois loin de la réalité du marché français, où les sociétés développent avant tout des applications d’e-commerce B to B.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
