Inscrivez-vous gratuitement à la Newsletter BFM Business
Les processus métier requièrent des échanges entre différentes applications. Ceux-ci peuvent désormais s'opérer au niveau du portail entre les portlets, ou plus en profondeur entre les applications via un mécanisme de type EAI ou
ESB.
Le portail a vocation à décloisonner les applications. Or, historiquement, celles exposées dans des portlets restent hermétiques entre elles. Elles ne s'échangent ni données ni instructions. Soit ces portlets s'appuient sur des
connecteurs et des API spécifiques pour accéder aux données et bâtir une interface, soit, lorsque l'application dispose d'une interface web, ils utilisent la technique du ' web clipping ' (des tronçons
de la page sont affichés dans le portail). Mais ces deux mécanismes traditionnels d'intégration répondent mal aux besoins de dialogue interapplicatif exigés par les processus métier complexes.Deux récentes techniques autorisent aujourd'hui l'interaction, voire la synchronisation des portlets. La première génère un dialogue interportlets en se référant à un courtier de messages. ' Ce
" property broker " est un composant du portail qui transforme les données dans le bon format. Il agit comme un EAI de surface et évite les développements spécifiques entre portlets ', précise Eric
Cheze, technico-commercial chez IBM. La seconde option repose sur un dialogue interapplicatif classique. Elle est utilisée lorsque le traitement effectué dans un portlet induit des mises à jour dans un autre portlet et son application associée.
' Mieux vaut alors invoquer un mécanisme d'intégration de plus bas niveau, comme un EAI ou un ESB ', estime Yves Lhéraut, directeur technique de BEA. La synchronisation de données entre applications
s'opère alors via un courtier de messages. Lequel renvoie au portail les mises à jour exposées par les portlets. ' Le portail devient consommateur de services. Il ne s'adresse plus à une source et à un connecteur spécifiques,
mais à un annuaire qui lui renvoie l'adresse du bon service web ', détaille Christophe Bourven, responsable avant vente chez Vignette. A noter que cette consommation de services web s'effectue en quasi-temps réel. A la
différence d'une intégration classique, les données ne sont pas stockées temporairement, puis transformées pour être exploitables par le portail. Elles sont directement publiées dans ce dernier.
Habiller des services web en portlets
Reste que cette consommation exige, en théorie, un minimum de développement pour habiller le service web dans le portlet. En théorie, car de plus en plus d'outils de développement intuitifs sont directement livrés avec les
portails pour ' portlétiser ' des services web. Mieux encore : avec WSRP (Web Services for Remote Portlets), cette problématique d'affichage devrait disparaître. En effet, les services web
conformes à ce récent protocole embarquent, outre des données structurées en XML, des informations de présentation. Résultat : ils sont immédiatement exposables dans les portlets, sans aucun travail préalable.Adapté à la consommation de services web, le portail devient aussi l'endroit privilégié pour exposer les processus de l'entreprise, qui reposent souvent sur des services. L'enjeu devient alors de
' portlétiser ' les différentes étapes au fur et à mesure de leur modélisation par les outils de BPM. Ainsi, chez IBM, Rational Application reçoit de la couche de modélisation de processus un fichier
WSDL (structure XML décrivant toute la chaîne du processus), et génère en retour autant d'ébauches de portlets que nécessaire. ' D'ici trois à quatre ans, le portail deviendra la principale interface de restitution
d'applications - celles-ci se contenteront d'exposer des services web, prévoit Guillaume Plouin, de SQLI. Son déploiement ne nécessitera plus aucun connecteur spécifique. Il deviendra ainsi moins onéreux. Ce qui favorisera son
adoption. '
Votre opinion