Que l’on considère les sites de vente en ligne, les applications d’e-procurement ou la connexion aux places de marché, certains constituants d’une plate-forme e-business sont toujours nécessaires : le serveur d’applications, fondation des nouvelles applications ; et le serveur d’intégration, qui intégrera les nouvelles applications aux systèmes d’information de l’entreprise et de ses partenaires. Ces serveurs sont complétés par les outils de développement et de déploiement des applications.Le serveur d’applications a trois rôles essentiels. D’abord, son premier rôle est d’offrir aux structures logicielles d’accueil des composants de l’application. Que l’on utilise les technologies de Microsoft ou la plate-forme Java, la structure des applications reste la même : des pages de script serveur chargées de la présentation des données aux internautes (avec les ASP, Active server pages, pour la plate-forme Windows 2000 ; et avec les JSP, Java server pages, pour la plate-forme Java), plus des composants serveurs hébergeant la logique métiers (avec COM+, Component object model, pour la plate-forme Windows 2000 ; et avec les EJB, Enterprise JavaBeans, pour la plate-forme Java).Ensuite, le rôle d’un serveur d’applications est de fournir des services de niveau middleware aux applications, comme la gestion des sessions utilisateurs, la prise en compte de la sécurité (soit en direct, soit par l’intermédiaire d’une infrastructure externe : annuaire, certificats, infrastructure PKI, etc.), la gestion des transactions distribuées, ou encore, la gestion de la persistance des états des composants avec la conversion objet-relationnel ainsi que leur stockage dans une base de données relationnelle.
Gérer l’équilibrage de charges entre serveurs
Ces services peuvent être fournis soit par le serveur d’applications, soit par des modules très finement intégrés à ce dernier. Ainsi, dans le cas de la persistance, certains serveurs d’applications offrent en interne le service, d’autres non. Dans le cas où le service n’est pas offert en interne, il faut avoir recours à des modules, tel Enjin, de Versant, qui prennent en compte la persistance des objets dans une base de données objet jouant le rôle de cache vis-à-vis du backend, et qui libèrent les développeurs du codage du stockage des objets en base de données relationnelle.À cette liste de services, la version 2.0 des composants EJB adjoint le service de messagerie JMS. Ce dernier interface ces composants avec des messageries interaplicatives telles que MQSeries. Enfin, le dernier rôle d’un serveur d’applications consiste à assurer la montée en charge, la disponibilité et les performances des applications par la mise en place de caches, par l’équilibrage des charges entre les machines serveurs et, enfin, par la gestion des pannes et du redémarrage automatique des éléments hors service. L’ensemble de cette fonction fait naître plusieurs débats importants entre les éditeurs.Ainsi, compte tenu que 80 % des pages affichées sont toujours les mêmes, Oracle préconise l’emploi d’un cache de pages dynamiques rafraîchi lors des mises à jour de données pour tripler les performances des applications. L’emploi d’un cache de données est plus généralisé parmi les différents éditeurs. À ce niveau, il existe des différences par rapport aux diverses technologies, la plate-forme Windows 2000 n’étant pas apte à monter en charge comme celles des principaux serveurs d’applications J2EE et ce, malgré la sortie de l’outil AppCenter qui autorise la gestion de grappes de serveurs Windows 2000.Compte tenu de la non-standardisation des architectures de connecteurs dans la plate-forme J2EE actuelle, les capacités d’intégration du serveur d’applications avec l’existant ont longtemps constitué une source importante de différenciation, chaque éditeur créant ses propres connecteurs pour les applications existantes ou préconisant l’emploi d’une solution d’EAI pour ne pas ajouter une couche au ” spaghettiware “. Ainsi, un serveur d’applications offrant une solution d’intégration des applications disposait d’un avantage compétitif. Avec la création de l’architecture standardisée JCA (Java connectors architecture), incluse dans la version 1.3 de la J2EE, ce critère va tomber progressivement. Cette architecture définit en pratique une structure générique d’accueil de connecteurs, à inclure dans les serveurs d’applications.
Transparence de rigueur
Avec la JCA, le serveur d’applications et l’application à intégrer collaboreront pour offrir de façon transparente aux composants métiers les mécanismes de gestion des transactions distribuées multisources, de la sécurité du système existant (tel le contrôle d’accès) et du partage des accès (pools de connexions). Les ” connecteurs logiciels ” sont alors fournis soit par un éditeur d’EAI, soit par l’éditeur du progiciel à ” connecter “. Par exemple, Borland a pris en compte la structure d’accueil de la JCA dans la version 4.5 de son serveur d’applications et Tibco lui fournit les “connecteurs” pour les principaux progiciels du marché. Les autres éditeurs de serveurs d’applications sont, en général, moins avancés.La différenciation liée aux capacités d’intégration est donc appelée à disparaître, à terme, entre les serveurs d’applications J2EE. Elle reste toutefois valide avec la plate-forme Windows 2000. Cependant, Microsoft vient enfin de sortir son serveur d’intégration BizTalk Server, qui inclut la gestion de processus et de transformation des données.Un outil très attendu par les architectes. On commence aussi à voir apparaître des architectures mixtes comprenant un serveur d’applications J2EE et le serveur BizTalk. Les technologies de services Web promises par les éditeurs pour la seconde moitié de 2001 renforceront cette convergence entre serveurs d’applications et intégration d’applications.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
