Les entreprises ont de plus en plus recours à la plate-forme J2EE pour bâtir leurs applications à mission stratégique. De ce fait, le déploiement et l’administration deviennent des critères essentiels. Les directions informatiques doivent, en effet, s’engager sur des contrats de services garantissant le bon fonctionnement des applications basées sur la plate-forme J2EE, comme elles le font pour les autres applications. Ce besoin va même plus loin, car les serveurs d’applications sont souvent employés pour ouvrir le système d’information à l’extérieur de l’entreprise (clients, partenaires, fournisseurs…).Face à ces besoins, qu’existe t-il ? En pratique, l’aspect administration est de loin le moins développé des serveurs d’applications J2EE. Cet état de fait est dû à l’histoire de la plate-forme. Pendant de longs mois, l’objectif des éditeurs de serveurs d’applications J2EE a été de convaincre les directions informatiques d’utiliser la J2EE. Ils ont donc porté leurs efforts sur l’élaboration du modèle de programmation. Début 2001, beaucoup d’éditeurs ne fournissaient pas de console d’administration avec leurs serveurs d’applications. Tant que les applications J2EE ne contenaient qu’une couche de présentation accédant à une base de données, l’administration était réalisée par les outils livrés avec la base de données.Désormais, les applications J2EE étant de plus en plus complexes, et interconnectées au système d’information, la capacité à les administrer correctement devient un critère de différenciation entre les serveurs d’applications proposés sur le marché. Or, les serveurs d’applications J2EE sont intrinsèquement difficiles à administrer. “Il existe de très nombreux paramètres qu’il faut bien régler pour obtenir un fonctionnement et des performances satisfaisants. Il convient également de superviser de très nombreux états (charge des processeurs, occupation mémoire du système et des machines virtuelles Java, chargement dynamique des composants en mémoire…). De plus, pour obtenir une montée en charge et une disponibilité suffisantes, les serveurs d’applications sont de plus en plus souvent déployés dans des architectures mettant en ?”uvre des grappes de serveurs, difficiles à administrer sans de bons outils”, affirme Arnaud Ladrière, directeur technique d’Alpha CSP France.Les entreprises utilisatrices de serveurs d’applications J2EE ont donc poussé les éditeurs à pourvoir leurs produits de fonctions permettant leur administration. Les éditeurs ont pris conscience de ce besoin et ont inclus des fonctions d’administration dans leurs serveurs d’applications respectifs. Ainsi, BEA Systems, IBM et Sun iPlanet ont doté, en 2001, leurs produits d’une console d’administration de leur serveur d’applications assez complète.
Toutes les interfaces doivent fonctionner
Toutefois, les consoles d’administration fournies par les éditeurs permettent la supervision et la configuration de leurs serveurs d’applications J2EE respectifs, mais ne donnent pas de vision globale du fonctionnement de l’application distribuée.Considérons ainsi une application J2EE connectée à l’ERP de l’entreprise et offrant à ses partenaires des voies d’accès personnalisées. Le bon fonctionnement de cette application pour les partenaires de l’entreprise correspond notamment à la possibilité d’accéder en temps réel au suivi de ses commandes. Assurer le bon fonctionnement de l’application implique évidemment que le serveur Web, le serveur d’applications J2EE, la base de données, le connecteur reliant le portail à l’ERP et, enfin, l’ERP remplissent leur rôle, chacun pris de façon indépendante. De plus, le fonctionnement de chacun de ces constituants n’entraîne pas forcément la bonne marche de l’application complète. Il faut que toutes les interfaces soient opérationnelles. “Quatre-vingts pour cent des réglages de paramètres dans une telle application sont relatifs aux interfaces, précise Arnaud Ladrière. Une base de données mal configurée ou un paramétrage trop faible du nombre de connexions parallèles à la base de données peuvent ainsi introduire des retards dans les traitements des requêtes utilisateurs, ce qui, éventuellement, donne lieu à des délais d’attente inadmissibles pour les utilisateurs, alors que chaque constituant sera vu en fonctionnement correct par leurs administrateurs respectifs.”Il est donc essentiel d’adopter une approche globale de l’administration en mettant en place une solution centralisée d’administration et en y connectant tous les constituants de l’application globale.
SNMP, pour une supervision centralisée
En 2001, certains éditeurs, tels BEA Systems ou Sun iPlanet, ont doté leurs serveurs d’applications d’un agent et d’une MIB, ou base d’informations destinée à l’administration, SNMP pour permettre leur supervision par une plate-forme centralisée.Les éditeurs des plates-formes d’administration centralisée ont également travaillé pour prendre en compte les serveurs d’applications J2EE : création d’agents pour les serveurs d’applications ou corrélation des informations remontées des différents serveurs commerciaux. BMC Software a créé, début 2001, des agents Patrol pour les serveurs d’applications WebLogic, de BEA Systems ; et WebSphere, d’IBM, agents qui viennent en complément de ceux qui sont prévus pour les serveurs Web et les SGBD, par exemple. Ces agents offrent notamment la possibilité de superviser en temps réel l’utilisation des ressources (threads, composants EJB précréés, connexions à la base de données, etc.), les taux d’utilisation des processeurs et de la mémoire, ainsi que les alertes éventuelles. Ils autorisent, de plus, le redémarrage de serveurs depuis une console centrale Patrol.
Prise en compte des principaux serveurs Web
Mi-2001, Computer Associates a créé les produits Unicenter Management for WebLogic et Unicenter Management for WebSphere, qui prennent en compte les principaux serveurs Web, ainsi que les serveurs d’applications correspondants.“Notre plate-forme Unicenter apporte une vision globale du fonctionnement des applications distribuées. Avec nos agents pour les serveurs Web, les serveurs d’applications WebLogic et WebSphere, nos agents pour les SGBD et, enfin, nos agents pour les principaux progiciels, nous concentrons les informations relatives au fonctionnement de chaque constituant au niveau de notre console centralisées, dans laquelle toutes ces informations sont corrélées pour indiquer aux administrateurs la véritable source des incidents”, précise Arnaud Gay, responsable technique avant-vente de Computer Associates pour la gestion des applications. De son côté, HP a ajouté à son catalogue des produits “smart plug-in” pour les serveurs d’applications WebLogic, de BEA Systems ; iPlanet, de Sun ; et HPAS, de HP. Enfin, IBM Tivoli a lancé Web Component Manager, qui autorise l’administration de la plate-forme WebSphere.
Une mise en ?”uvre particulièrement coûteuse
Il reste néanmoins plusieurs problèmes. D’abord, la mise en ?”uvre de telles plates-formes est très chère. Ensuite, peu d’entreprises disposent, en interne, de personnels formés à l’administration d’une application J2EE. En effet, être capable d’administrer des applications distribuées, comme le sont les applications J2EE, implique de pouvoir comprendre les causes des incidents rencontrés, ce qui nécessite un accès rapide à des spécialistes de la plate-forme J2EE. Aussi, de nombreuses entreprises décident de mutualiser les coûts d’administration en ayant recours à l’infogérance. Par exemple, Antargaz a sous-traité l’administration de son application J2EE raccordant son centre d’appels à ses applications back-end. De même, la place d’affaires Seliance, filiale du Crédit Lyonnais, a sous-traité l’administration de ses applications J2EE.Le premier réflexe pourrait être de confier cette prestation aux hébergeurs. Malheureusement, la majorité d’entre eux n’a pas la compétence de la plate-forme J2EE. Aussi, la plupart des prestations d’infogérance relatives à des applications J2EE sont prises en compte par des sociétés de services. Dans les deux exemples cités ci-dessus, les prestations ont été confiées à Teamlog (pour Antargaz) et à Ifatec (pour Seliance).La version J2EE 1.3 impose aussi aux éditeurs de serveurs d’applications de mettre en ?”uvre le nouveau standard d’administration des applications Java que représente JMX. Selon le GartnerGroup, en 2003, 50 % des applications Java déployées au-dessus d’un serveur d’applications seront administrées à travers JMX. Ce standard est dérivé des travaux de Sun Microsystems relatifs à l’administration de services Java embarqués dans des équipements de télécommunications et inclus dans JDMK (Java dynamic management kit). Un certain nombre de serveurs d’applications J2EE sont déjà conformes à JMX, tels BEA Web Logic Server, Borland Enterprise Server, HPAS, ou encore, Sybase Enterprise Application Server. Iona Technologies a également participé à l’élaboration de JMX. Même les serveurs d’applications Open Source ont adopté JMX. Le meilleur exemple est celui de JBoss, dont l’architecture interne est désormais basée sur JMX.Ce standard a aussi reçu un écho favorable de la part des éditeurs de plates-formes d’administration. Ainsi, le nouvel outil Tivoli Web Component Manager (TWCM), d’IBM, est basé sur JMX, même si le serveur d’applications WebSphere, d’IBM, ne l’est pas encore. Cet outil permet de superviser le serveur Web d’Apache et le serveur d’applications WebSphere.
Pas de mécanisme standard d’assemblage
L’agent assure la remontée des informations au Manager TIMS (Tivoli Internet management server), qui peut ensuite les présenter sur une console d’administration, éditer des rapports, envoyer des événements à la console d’entreprise de Tivoli, ou encore, émettre des notifications SNMP.Computer Associates et Bull Evidian ont également adhéré au standard JMX. De même que les spécialistes de la mesure des performances des applications J2EE que sont Wily Technologies et Precise Software Solutions. Le premier se sert de JMX dans la version 3.0. de son outil Introscope, pour obtenir une meilleure supervision du serveur d’applications WebLogic 6.1., de BEA Systems, tandis que le second commence à mettre en ?”uvre JMX, dans le cadre de ses outils de mesure de performances de la chaîne complète de traitement des requêtes utilisateurs intégrant les progiciels d’entreprise. En outre, il escompte profiter de JMX pour ne pas avoir à développer un agent 100 % spécifique pour chaque serveur d’applications J2EE. Pratiquement, le standard JMX consiste en un ensemble de spécifications et d’outils de développement destinés à gérer les environnements Java, complété d’une mise en ?”uvre de référence et de tests de conformité. Il définit une architecture d’administration, des interfaces d’accès, ainsi que des services d’administration de base.L’architecture définie par JMX comprend trois niveaux, dénommés instrumentation, agent et manager. Le niveau instrumentation est en contact avec l’application J2EE à administrer. Il est composé de Managed Beans, qui représentent une ressource Java administrée. Le niveau agent joue le rôle traditionnel d’agent vis-à-vis des plates-formes d’administration centralisée à la manière d’un agent SNMP traditionnel. Il joue également le rôle de serveur de Managed Beans, qui sont chargeables dynamiquement. Cette structure a été conçue pour charger en dynamique selon les besoins des services, qui, dans le cas de la J2EE, pourront être des composants, une application, une nouvelle version du serveur d’applications, etc.Le niveau supérieur est celui des managers, c’est-à-dire des consoles d’administration centralisées. JMX standardise très fortement le niveau instrumentation, mais beaucoup moins ceux des agents et des managers. Ainsi, le cabinet d’analyse GartnerGroup considère comme une limitation de JMX le fait qu’il n’y ait aucun mécanisme standard d’assemblage des composants de services d’administration au niveau des agents JMX. En outre, JMX ayant pour cible l’administration des applications Java en général et non uniquement J2EE, il n’existe pas de définition standard des objets principaux, éditeurs de serveurs d’applications.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
