La vague des places de marché et la généralisation des échanges électroniques ont accentué le phénomène de standardisation de la communication entre applications. Pour que celles-ci échangent des informations dans un cadre de procédures métiers préétablies, elles doivent en effet partager un langage commun. En informatique, ce langage prend deux formes : métier et technique. L’aspect métier est pris en charge par les schémas XML qui définissent l’utilisation de termes, ainsi que leurs syntaxe et grammaire (arborescence) dans un cadre d’échange spécifique lié à un secteur d’activité ou à une procédure métier définie.De son côté, l’aspect technique intervient directement dans les procédures reconnues et utilisées par les applications pour communiquer entre elles et relève directement de l’intégration entre systèmes hétérogènes. En avril 2000, le W3C franchissait un premier pas dans la normalisation des échanges entre applications en ratifiant Soap
1.1 (Simple Object Access Protocol). Protocole de type RPC (Remote Procedure Call), Soap s’appuie sur le protocole de transport du web (HTTP) ou de la messagerie électronique (SMTP) et le métalangage XML pour établir un lien entre 2 systèmes et assurer le transport des données.Pour compléter cette architecture, il manquait toutefois une brique fondamentale : la description des services assurés par chaque application. C’est précisément là qu’intervient WSDL, norme du W3C depuis mars dernier.
Pour concevoir des applications sur mesure
Concrètement, WSDL permet à une application de décrire ses fonctions (ou services) selon un modèle normalisé. Soap et WSDL ont en effet été conçus dans 2 buts précis indissociables des échanges en réseau, et notamment internet, d’où leur association à la notion de services web. En autorisant des fonctions à s’autodécrire, Soap et WSDL favorisent en effet une approche modulaire des applications qui se concrétise par l’apparition de nouveaux modèles économiques. Plutôt que de vendre sa suite bureautique en bloc, un éditeur commercialisera un composant fonctionnel qui sera invoqué à travers le web par l’entreprise cliente.Cette dernière assemblera ainsi les fonctions dont elle a réellement besoin pour concevoir une application sur mesure. Dans le même ordre d’idée, elle sera à même d’invoquer dynamiquement les systèmes informatiques de partenaires à travers le web pour enrichir son produit de services tiers, et ainsi fabriquer une offre personnalisée afin de répondre au besoin d’un client. Ces modèles soulèvent toutefois 2 problèmes : comment trouver le service cherché et comment facturer la consommation du service ? Si le premier est résolu avec UDDI (Universal Description, Discovery and Integration), troisième larron de la combinaison Soap/WSDL qui normalise la constitution d’annuaires de service, le second reste entier et devrait donner naissance à des plates-formes de rétrofacturation très complexes.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
