Il ne s’agit plus de vendre d’environnement de développement sans une console d’administration. Avec la généralisation, dans de nombreuses entreprises, des architectures conformes au standard J2EE (Java 2 enterprise edition) pour bâtir les nouvelles applications de l’e-business, le problème du passage en production et celui de l’administration de ces nouvelles applications se posent de façon criante. En effet, durant ces dernières années, l’objectif des éditeurs de serveurs d’applications J2EE était, prioritairement, de convaincre les entreprises d’adopter leurs solutions, en vantant plus particulièrement l’environnement de développement dont le but était de gagner en productivité. L’administration des applications J2EE a ainsi été longtemps considérée par les éditeurs de serveurs d’applications J2EE comme la dernière de leurs préoccupations, et la plupart des serveurs d’applications J2EE ont été commercialisés sans même qu’une console d’administration ne soit livrée avec le produit.“La version 6 du serveur d’applications WebLogic, de BEA Systems, est la première version de ce produit livrée avec une console d’administration. Jusqu’à l’automne 2000, la mise en production d’une application J2EE utilisant ce serveur d’applications ?” pourtant leader du marché ?” passait par l’édition de fichiers plats et l’analyse des journaux. Il convient, en outre, de préciser que ce serveur d’applications n’était pas une exception et représentait l’état réel du marché. Seul Borland proposait un outil d’administration avec AppCenter “, précise Franck Gonzales, directeur technique de la société Owendo Technologies. Et d’ajouter : “Cet état de fait était admissible tant que l’on restait au stade des pages de scripts serveur accédant à une base de données. L’administration de la base de données réglait alors les problèmes. Il ne l’est plus actuellement, avec l’emploi des composants métiers Enterprise JavaBeans, nécessaires pour coupler le site de commerce électronique au système d’information de l’entreprise, avec une charge importante en nombre d’utilisateurs. Les problèmes posés sont dorénavant d’un autre ordre de grandeur, et il faut administrer l’activation des composants, leur persistance, les transactions réalisées, l’intégration de l’existant, etc. Les outils d’administration sont loin du niveau atteint avec les solutions de client-serveur de deuxième génération, qui étaient beaucoup plus abouties, comme celles de Forté.”
Le manque de compétences des administrateurs
Le problème est bien réel.“La plupart des incidents d’exploitation se produisent lors des pics importants de charge, précise Arnaud Ladrière, directeur technique de l’activité d’hébergement d’applications chez Alpha CSP. Or, c’est justement à ce moment que l’activité de commerce électronique est la plus forte. Un arrêt d’un site d’enchères de billets d’avion au moment des enchères du week-end a des conséquences catastrophiques pour la survie du site. Une politique d’administration consistant simplement à attendre le plantage du site pour intervenir serait donc irresponsable pour de nombreux sites. Le problème vient d’un manque de maturité de la plupart des hébergeurs, qui appliquent à l’administration des applications J2EE les principes d’administration de réseaux, pour lesquels le simple remplacement des équipements tombés en panne peut suffire. L’absence d’outils dignes de ce nom n’arrange rien, mais les éditeurs travaillent, et les premiers produits arrivent sur le marché : consoles d’administration des serveurs d’applications, prise en compte des serveurs d’applications au niveau des plates-formes d’administration d’applications, tel Patrol, de BMC Software.”
Prévoir un budget pour éviter toute panne dramatique
Les entreprises rencontrent également un autre problème important : le manque de compétences des administrateurs. “L’administration des applications J2EE nécessite de bien connaître le fonctionnement du serveur d’applications. Ainsi, pour régler les performances d’un site, il faut, par exemple, régler le nombre d’instances des différents composants EJB présents en mémoire à un instant donné ou le dimensionnement des pools de connexion à la base de données. Cela demande une connaissance affinée du fonctionnement des serveurs d’applications J2EE “, précise Franck Gonzales. ” Il est même nécessaire d’obtenir à un instant donné une vision locale et une vision globale, car il faut corréler les problèmes de niveau système et de niveau applicatif, complète Arnaud Ladrière. Administrer une application distribuée en considérant chaque serveur de façon indépendante serait une grave erreur. Environ 80 % des réglages nécessaires sont relatifs aux communications entre les différents serveurs : serveur Web, serveur d’applications, SGBD, EAI, etc. Une application J2EE n’est pas une application monolithique, comme celles qui fonctionnent sur les gros systèmes. “” Il faut placer l’aspect distribué au premier plan des préoccupations des équipes mettant l’application en production et réglant ses performances, puis le gérer de façon proactive, si l’on ne veut pas avoir de problème,continue Arnaud Ladrière. Si la mise en production et le réglage des performances ont été bien pris en compte, et si l’administration est faite de façon proactive, la robustesse des serveurs commerciaux assurera ensuite une fiabilité élevée aux applications J2EE, avec de très faibles taux d’incidents, rendant l’architecture apte à prendre en compte les applications stratégiques des entreprises”, conclut-il.Ainsi, il ne faut pas confondre l’installation des logiciels avec leur mise en production, qui va plus loin et implique un réglage fin de nombreux paramètres pour obtenir des performances correctes. Un budget doit donc être affecté à un travail continu d’administration afin d’éviter que le responsable du site n’ait à mobiliser des moyens exceptionnels, lors d’une panne qui serait dramatique pour l’activité commerciale de l’entreprise.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
