Passer au contenu

Les portails, premiers utilisateurs de services Web

Les technologies des services Web simplifient la construction des portails. Elles assurent l’interopérabilité des plates-formes logicielles concourant à leur fonctionnement.

Grands consommateurs d’informations, les portails d’entreprise sont les premiers bénéficiaires des services Web. Chargés d’afficher un contenu personnalisé suivant l’utilisateur et d’autoriser un accès sélectif aux applications centrales de l’entreprise, “les portails sont des outils d’agrégation de services, d’applications et d’informations. En s’appuyant sur les technologies simples des services Web, les éditeurs de ces plates-formes vont gagner en adaptabilité et en facilité d’intégration “, affirme Arnaud Ladrière, directeur technique d’AlphaCSP. Les technologies Soap et WSDL, en particulier, font l’objet d’un consensus entre les principaux éditeurs, tels IBM, Microsoft ou Oracle. Ces technologies apportent une interopérabilité bienvenue dans le cas des portails, puisque ceux-ci doivent agir avec de multiples environnements hétérogènes.

Récupérer du contenu et accéder aux applications

Deux usages des services Web devraient coexister. Il s’agit, d’abord, des services de récupération de contenu chez un partenaire. De nombreux portails échangeaient déjà des fichiers XML, via HTTP, pour capter des contenus tels que l’état de la circulation routière, les prévisions météo, ou encore, les plans des villes, comme dans le cas du portail ViaMichelin. Dans cette éventualité, le couple Soap et WSDL constitue un mécanisme d’échange particulièrement bien adapté. Cette récupération de contenu correspond à la consultation d’une base de données, à la différence près que l’accès est encapsulé dans des services de plus haut niveau d’abstraction. La seconde utilisation privilégiée des services Web concerne l’accès aux applications traditionnelles de l’entreprise. La Société Générale a ainsi connecté son portail à l’une de ses applications métiers développée en Cobol, sous CICS, et fonctionnant sur son grand système. Un serveur d’applications J2EE, également hébergé sur le mainframe, joue alors les traducteurs en présentant l’application Cobol sous la forme de services Web exploitables par le portail. L’équipe de création du portail n’a pas, ainsi, à apprendre les dialectes des applications à intégrer, et l’équipe des grands systèmes n’élargit pas ses prérogatives.Le même type d’encapsulation est possible avec les progiciels du marché. Des éditeurs tels que Commerce One, Oracle ou SAP ont d’ailleurs annoncé qu’ils dotaient leurs produits de centaines de points d’entrée, accessibles sous la forme de services Web. De cette façon, les portails communiqueront avec ces systèmes sans imposer de lourdes solutions d’intégration d’applications. De plus, dans le cas où les entreprises mettent en place une gestion de leurs processus métiers, via un outil de BPM (Business process management), les portails pourront faire appel à des compositions de services Web.Afin de faciliter l’appel de services Web depuis les portlets, Epicentric et Documentum ont proposé le langage WSUI (Web service user interface) pour définir “l’expérience utilisateur” appliquée aux services Web : saisie des paramètres d’appel et affichage des résultats. À partir de fichiers XML, WSUI génère les portlets indispensables à l’appel des services Web dans les cas simples ne nécessitant qu’un seul affichage à l’écran. L’utilisation des services Web ne devrait toutefois pas se limiter à un appel de services Web externes.En effet, nombreux sont les portails qui reprennent tout ou partie des portails de partenaires. Par exemple, une banque qui commercialise les contrats d’une compagnie d’assurances, devra intégrer toute la logique de navigation du site partenaire afin d’aboutir à la vente d’un contrat. Un tel travail d’intégration du processus de navigation du site partenaire dans le portail est souvent considérable. Afin de supprimer ces difficultés, certains éditeurs tels qu’IBM ont pensé déporter les portlets et utiliser les services Web pour les relier au portail. Les portlets sont ainsi mutualisés. Dans ce but, Big Blue a proposé le langage WSXL (Web services experience language), soumis au consortium Oasis pour normalisation.Le futur standard réunira les caractéristiques de WSUI et de WSXL. Baptisé WSCM (Web services component model), il devrait être finalisé à la fin de 2003. Il ne s’agit donc que d’un travail de recherche, non utilisable actuellement. En attendant, le français Orchestra Networks propose sa solution EBX (Enterprise business extension). Utilisable aussi bien pour la délégation de sites Web que pour celle de portails, EBX fonctionne selon le concept de processus métiers Web (Web business process). Ce dernier est en charge de toute la navigation qui orchestre l’appel et l’agrégation de services Web proposés par les applications d’entreprise. EBX ne semble pas avoir d’équivalent pour l’instant. Il est déjà en production au sein de la banque SBE du groupe Banque Populaire et chez l’assureur Ineas. En conclusion, les services Web sont appelés à être consommés en grand nombre par les portails. Toutefois, certaines applications devront toujours être accessibles via des protocoles propriétaires ou des standards tels que Corba ou COM, car aucune technologie ne peut faire table rase du passé. À cet effet, les bus XML, comme ceux proposés par Iona Technologies ou Cape Clear, joueront les passerelles vers les portails qui négligeraient une telle intégration.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Jean-François Masler