À ses débuts, en 1993, le web se composait de sites statiques présentant les brochures commerciales des entreprises. L’émergence du commerce sur la Toile a ensuite créé le besoin de disposer de sites dynamiques, dont le contenu des pages se modifie automatiquement selon le profil des internautes et les politiques commerciales des sociétés. Inadaptée pour répondre à ce nouveau besoin, l’infrastructure des sites statiques a donc évolué afin, notamment, d’introduire des données enregistrées dans un SGBD au sein des pages statiques.
1 – Une première tentative avec les scripts CGI
Dans un premier temps, les éditeurs de serveurs web ont développé plusieurs types d’interfaces afin d’insérer des données dynamiques dans les pages. L’interface CGI (Common Gateway Interface) demeure l’une des plus populaires. Lors de la réception d’une requête HTTP, le serveur web lance l’exécution d’un programme accédant au SGBD et fournit, en retour, les pages contenant les données lues et prêtes pour l’affichage. Pratique, l’interface CGI présente toutefois quelques défauts. À commencer par de piètres performances, son fonctionnement se révélant assez complexe. En effet, à chaque requête HTTP, le serveur web lance un programme qui ouvre la base de données, lit les informations, puis ferme le SGBD. De plus, cette interface n’assure pas le maintien de l’état des sessions utilisateurs entre les requêtes HTTP.
2 – Les serveurs d’application pour un web plus interactif
Pour pallier ces problèmes, une nouvelle classe d’infrastructures logicielles, appelées serveurs d’application, a été élaborée. Le principal rôle de cette première génération de plates-formes consistait à relier les serveurs web aux SGBD, sans ployer sous la montée en charge. Les technologies employées sont les servlets et les JSP (Java Server Page) du monde J2EE (Java 2 Enterprise Edition), les ASP (Active Server Page) de Microsoft ou les scripts PHP du monde open source. Toutes fournissent aux entreprises des moyens simples pour gérer des interactions dynamiques avec le web, au travers de sessions dont le contexte est maintenu entre les requêtes HTTP.
3 – Accroître les performances
Les serveurs d’application prennent également en charge le parallélisme du traitement des requêtes en provenance des internautes. Ils facilitent la bonne tenue de l’infrastructure face à la montée en charge, en assurant un partage des ressources des serveurs entre les différents internautes. Ainsi, la majorité des technologies de serveurs d’application gèrent un pool de connexions au SGBD. Ces dernières sont affectées successivement aux différentes requêtes des internautes et évitent de rouvrir la base de données à chaque fois. Les performances et l’aptitude à monter en charge sont en conséquence grandement améliorées vis-à-vis des anciens scripts CGI.
4 – Une programmation proche du client-serveur
Bien que les technologies d’affichage aient évolué, grâce au remplacement de l’interface locale Windows par une interface web standardisée et déportée sur les postes clients des internautes, le modèle de programmation des applications n’a que peu changé. En effet, la logique métier et celle de présentation sont toujours mélangées dans le code source de la plupart des applications web, ce qui rend impossible toute réutilisation de code source.
5 – La structuration apportée par les composants métier
Aussi, les éditeurs de serveurs d’application proposent des modèles de composants métier (Com+ pour la plate-forme Microsoft, EJB [Enterprise JavaBeans] pour la plate-forme J2EE) en complément des pages ASP/JSP, de façon à mieux structurer en couches la logique applicative. On obtient alors une découpe en 4 couches : client web, logique de présentation web, logique métier et accès aux données. Cette segmentation facilite la réutilisation de la logique métier. Toutefois, les composants métier restent encore peu utilisés, car ils impliquent de nouvelles méthodes de travail et une réflexion architecturale hors de portée de bon nombre d’entreprises.
6 – Des composants arrivés à maturité
Selon les analystes du Gartner Group, 10 % des applications web recourent à des composants Com+ ou EJB. Toutefois, la situation est en train d’évoluer avec le couplage croissant des applications web avec le système d’information des entreprises, ce qui implique des services middlewares d’une complexité plus élevée. Naturellement, la mise au point de ces services se révèle assez longue, étant donnée la réalisation de composants facilitant leur utilisation. La maturité des modèles de composants proposés avec les serveurs d’application fut donc également longue à obtenir. Voilà pourquoi il a fallu attendre la version 2 ou 3 de ces modèles de composants, tant du côté Com+ que du côté des EJB, pour un véritable déploiement sur le marché.
7 – Les services offerts aux développeurs
Les modèles de composants Com+/EJB fournis avec les serveurs d’application simplifient grandement l’usage des services middlewares de ces derniers, tels que la gestion des transactions et de la sécurité, l’activation et la désactivation des composants. Toutes ces invocations de services middlewares sont gérées par la structure d’accueil des composants, dénommée “conteneur de composant”. Le comportement de chaque composant vis-à-vis de ces aspects est déclaré par un descripteur de déploiement, fixé le plus souvent lors de l’intégration de l’application. Les développeurs n’ont plus à s’occuper de ces aspects, à la différence, par exemple, de Corba.
8 – Une interopérabilité avec de nombreux systèmes
Les serveurs d’application proposent de nombreuses interfaces d’accès, chargées d’assurer l’interopérabilité des composants métier avec le monde extérieur : communication synchrone prise en charge par un courtier d’objet (DCom, Corba…), communication asynchrone via un middleware orienté message (MQ Series), accès aux bases de données et aux applications d’entreprise via des connecteurs adéquats, etc. Cette interopérabilité place de fait les serveurs d’application au centre des nouvelles architectures informatiques.
9 – Des composants disponibles, supportant la charge et administrables
Ces plates-formes assurent également la disponibilité et la montée en charge des composants, au travers de services d’équilibrage de charge et de basculement sur panne à l’intérieur de serveurs multiprocesseurs ou de fermes de serveurs. L’ensemble de ces services est géré grâce aux consoles d’administration, fournies avec les serveurs d’application.
10 – Un engouement croissant pour les composants
Enfin atteinte, la maturité rend ces modèles de composants réellement exploitables et autorise une certaine réutilisabilité. Ces composants sont d’ailleurs de plus en plus employés dans les applications stratégiques des entreprises ; selon plusieurs analystes, près de 40 % des applications web recourront aux composants métier en 2003.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
