Nées des premières applications Internet qui reposaient déjà sur trois niveaux (navigateur, serveur Web et base de données), les architectures distribuées ont rapidement prouvé leurs qualités : rapidité, montée en charge et réutilisation de codes existants. Amenées à remplacer les modèles client-serveur, elles constituent la base d’intranets qui ne sont plus simplement des outils de communication mais de véritables applications transactionnelles. Pierre angulaire de ces nouveaux systèmes, les serveurs d’application et leurs outils de développement évoluent afin de simplifier la conception et le déploiement des applications en intranet.
Des applications segmentées en composants métiers
Le marché des architectures distribuées est divisé en deux clans : Microsoft avec sa plate-forme DNA et le reste de l’industrie informatique regroupée derrière Sun et Java. D’un point de vue purement fonctionnel, leurs objectifs s’avèrent similaires. Découpant les applications monolithiques en composants, ils favorisent la réutilisation du code : là où, en architecture client-serveur ou sur mainframe, il fallait revoir une application dans son intégralité pour la faire évoluer, il suffit désormais de modifier ou d’ajouter un composant pour introduire une nouvelle fonction dans une application. Orientées objet, ces architectures favorisent en outre la réutilisation de codes : plusieurs applications utilisant les mêmes services pourront ainsi se servir du même composant. Cette réutilisation suppose toutefois une modélisation très pointue de l’ensemble du système informatique avant de parvenir à un découpage en composants qui soient effectivement réutilisables.Toujours afin de minimiser les développements, ces architectures font également la différence entre les services métiers et les services techniques : les premiers sont développés par l’entreprise, tandis que les seconds sont fournis par l’environnement d’exécution, généralement un container (ajouté au serveur d’application), également appelé moteur d’EJB pour Enterprise JavaBeans (objets métier des environnements Java), ou son équivalent en environnement Microsoft, les objets COM+ (Component Object Model). Résultat, là où l’entreprise devait tout développer, elle se concentre aujourd’hui sur son métier : pour paramétrer les droits d’accès à un composant métier par exemple, il suffit en effet de le sélectionner et de cocher les options de sécurité à l’endroit où le développeur devait auparavant écrire son propre code. Enfin, aux objets métier exécutés côté serveur, ces architectures ajoutent des composants exécutés côté client (contrôles ActiveX pour Microsoft et applets Java chez Sun) qui accélèrent également les temps de développement. Peu adaptés en environnement Internet en raison du téléchargement des composants dont le volume reste trop important pour le débit limité du réseau public, applets et contrôles ActiveX sont davantage utilisés en intranet où l’entreprise maîtrise son trafic.
Un déploiement plus souple de composants distribués sur le réseau
Enfin, ces architectures réparties présentent un dernier avantage lié à la répartition de charge. Les applications étant découpées en composants, il est en effet possible de répartir les traitements sur plusieurs machines afin d’obtenir de meilleurs temps de réponse. La souplesse de distribution des composants optimise également l’exploitation de la bande passante : composants sur serveurs locaux pour exécution des tâches récurrentes, sur le poste client pour des traitements légers, sur des serveurs centralisés pour des besoins spécifiques nécessitant l’accès au système central, etc.Pour l’heure, les avantages des modèles de Microsoft et de Sun restent toutefois théoriques. Encore jeunes, ces technologies commencent tout juste à être installées au sein de l’entreprise. Faute d’outils adaptés et surtout de méthodologies opérationnelles, le découpage des applications en services fonctionnels relève encore du niveau expéri- mental, comme le souligne Alain Delahaye, directeur du pôle composants communs de Bouygues Télécom : “ Les outils de modélisation traditionnels en UML (Unified Modeling Language), tels que ceux de Rational Rose, sont globalement d’un piètre secours : ils permettent tout au plus d’établir une cartographie des applications, mais il leur manque une fonction pour établir le lien entre l’analyse et la génération des composants EJB. La méthodologie pour déterminer la bonne granularité, les différents niveaux de composants et les relations entre eux, nous l’avons élaborée en amont sur la base de notre ré-flexion uniquement !” On retrouve également ce problème sur le dé-ploiement, où l’absence d’outils de simulation qui prennent en compte les trois niveaux d’une architecture distribuée (client-serveur-données ou traitements) oblige l’entreprise à procéder par tâtonnements. Il existe encore un problème au niveau des outils qui n’ont pas été prévus pour gérer des architectures dans lesquelles il faut identifier les composants, tout en étant en mesure de les localiser en cas de dysfonctionnement et de tracer leur comportement de manière générale.Malgré ces lacunes dues en grande partie à la jeunesse du marché, il apparaît aujourd’hui clairement que les intranets de demain seront bâtis sur ces modèles, comme le prouve l’étude du Gartner Group. Selon ce cabinet américain, 41 % des entreprises employaient déjà ces architectures en 1999 pour les nouveaux développements.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
