Applications composites : les autres clients du web 2.0

On l'a vu, les données et services des sites web ne sont plus limités aux interfaces HTML classiques. ' Il est désormais possible d'assembler les API* et les flux XML au sein d'applications composites [ou mash-up* en anglais, Ndlr], exactement comme on le ferait avec des composants logiciels traditionnels ', explique Jérémy Chatard, directeur technique de Breek, une SSII spécialiste du web 2.0. Ce concept consiste à agréger directement au sein d'une interface graphique utilisateur des données et services hétérogènes provenant à la fois de l'entreprise et de fournisseurs tiers. On peut ainsi enrichir un outil de GRC avec le service de téléphonie de Skype, le service de cartographie Google Map, un flux RSS fournissant des renseignements sur la santé financière d'un prospect et sur l'état du stock d'un partenaire.

Toute l'intégration s'effectue côté client par de simples appels vers les API distantes, sans recourir à un serveur d'intégration ou à une infrastructure de portail. C'est l'application composite qui joue ces deux rôles à la fois. Une application composite est donc le client idéal des architectures orientées services (SOA), car elle préserve un haut niveau de découplage et gomme progressivement la frontière entre les systèmes d'information pour se concentrer sur le processus.

Deux types de technologies permettent ce développement : les technologies de client riche Internet, ou RIA* (Rich Internet Application), telles qu'Ajax*, XUL et Flex ; et celles s'exécutant sur le poste de travail, ou RDA* (Rich Desktop Application), telles qu'Eclipse RCP, Sun NetBeans RCP, IBM Workplace, et les smart clients de Microsoft.

Ces technologies s'appuient toutes sur un modèle de programmation événementiel et une architecture asynchrone. Le modèle événementiel permet de piloter chaque composant de l'interface graphique indépendamment les uns des autres en fonction des actions de l'utilisateur. Il est donc idéal pour créer des interfaces utilisateurs ergonomiques. L'architecture asynchrone est, quant à elle, essentielle pour garantir des temps de réponse rapides. Elle associe, en effet, à chaque composant graphique un ou plusieurs services web ou flux XML sous-jacents et les interroge séparément pour éviter de bloquer l'exécution de toute l'application si l'un d'entre eux est défaillant.

C'est sur ces principes que repose l'architecture Ajax. Contrairement aux autres technologies qui nécessitent un runtime propriétaire, Ajax reproduit les concepts du client-serveur traditionnel au sein d'un navigateur en s'appuyant sur des technologies standards. Chaque composant graphique est fondé sur des feuilles de styles (CSS) et des éléments XHTML manipulés par du code ECMAScript via le DOM (Document Object Model). L'association entre la couche graphique du composant et le service web ou le flux XML sous-jacent s'effectue via l'objet ECMAScript XMLHttp-Request*. Celui-ci permet au navigateur d'échanger des flux XML avec un serveur en empruntant HTTP (ou d'autres protocoles). Malheureusement, bien qu'ils soient très respectueux des standards, les frameworks Ajax sont encore jeunes. Et ils ne compensent pas les lacunes des navigateurs : pas de base de données locale, aucune couche de sécurité pour simplifier l'authentification et la gestion des droits des utilisateurs, etc. C'est pourquoi certaines entreprises et éditeurs de logiciels préfèrent se tourner vers une technologie RDA telle qu'Eclipse RCP pour assembler leur application composite. Eclipse RCP est un socle d'exécution qui s'installe sur le PC de chaque utilisateur au-dessus d'une machine virtuelle Java (JVM). Ce runtime contient les contrôles graphiques utilisés pour construire l'application, un cache de données, un moteur de synchronisation pour gérer le mode déconnecté, et tout le nécessaire pour dialoguer avec les services distants en utilisant des protocoles Internet standards. ' Plus performante et disposant d'une plus large couverture fonctionnelle qu'un client composite Ajax, cette technologie est incontournable lorsque l'application doit piloter des ressources localisées sur le poste client [périphériques, fichiers, etc., Ndlr], qu'elle fait un usage intensif de la 2D/3D temps réel, ou qu'elle manipule de gros volumes de données [traitement d'images, vidéos, etc., Ndlr] ', explique Sébastien Brunot, architecte chez Octo Technology.