Nouveaux il y a encore deux ans, les serveurs d’applications Java sont désormais entrés dans les m?”urs. Ils sont aujourd’hui à la base de la plupart des sites de commerce électronique qui, il y a peu, étaient encore construits autour de technologies propriétaires. Sous l’impulsion des éditeurs qui mettent en ?”uvre les spécifications de Sun, ces logiciels d’infrastructure tendent de plus en plus à se standardiser. Ces spécifications apportent certes quelques contraintes de développement, mais elles présentent l’avantage d’homogénéiser les serveurs du marché. Pour Philippe Lagente, directeur général d’AVS Consulting, responsable du développement et de la mise en production de Health (de Telemedicine Technologies), un service d’assistance médicale en ligne sur serveur SilverStream, la norme J2EE offre de gros avantages. “Le premier est de ne pas nous lier à un seul fournisseur. La norme standardise les développements et facilite leur déploiement sur différentes plates-formes. Une adaptation ne représente qu’un à deux pour cent du développement total de l’application”, argumente-t-il. Chez Scoot, Xavier Laurent, directeur des systèmes d’information, a pu ainsi remplacer un serveur IBM WebSphere par un serveur BEA WebLogic : “En évitant tout développement supplémentaire, nous avons gagné entre 15 et 20 % de performances ainsi qu’une meilleure disponibilité de l’application. De plus, BEA s’interface bien mieux avec notre plate-forme de supervision HP OpenView.”
Des développements aisés
Autre avantage d’une plate-forme J2EE, les temps de développements : “Six mois. Nous avons été agréablement surpris par la rapidité du développement et de la mise en production de notre application”, souligne Guillaume Pauchet, responsable informatique de GreenGroom, qui utilise OC4J (ex-Orion), le serveur d’applications J2EE 1.3 intégré à Oracle9i. Celui-ci permet à GreenGroom d’offrir à ses clients un suivi de conformité de leurs installations industrielles face aux normes environnementales. “Tout est standardisé dans J2EE, les fonctions sont bien décrites et cela nous a permis de nous concentrer sur notre métier, notamment les écrans utilisateurs”, poursuit Guillaume Pauchet.Par contre, développer une application conforme J2EE à 100 % est contraignant. “Il faut s’attendre à un temps de développement plus long que dans le cas d’un développement propriétaire, estime Philippe Lagente. J2EE oblige aussi à abandonner certains mécanismes bien pratiques : chaque éditeur livre des classes Java destinées à faciliter les développements. Seul problème, elles disparaissent en cas de transfert de l’application vers un autre serveur. J2EE demande donc une certaine discipline de la part du développeur qui doit renoncer à ses habitudes de travail.”“Nous avons choisi J2EE car nous voulions des technologies homogènes, fiables et capables d’évoluer sans tout reprogrammer, reprend Guillaume Pauchet. Nous avons eu quelques problèmes de connexion à la base de données par JDBC, mais, dans l’ensemble, tout s’est bien passé. J2EE demande des connaissances très pointues, nous avons donc eu recours aux services de PixelPark, une SSII spécialisée en Java.” Du côté de Scoot, Xavier Laurent avoue n’avoir pas eu de mauvaises surprises, excepté celle de la compatibilité entre différentes versions de Java. “Nous avons eu en effet quelques soucis à concilier notre application avec la version 2.1 du langage et les fichiers de déploiement du serveur, conçus avec la 2.2”, détaille Xavier Laurent. Lors de la programmation d’une application, il est également nécessaire de bien cerner ses besoins. Par exemple, pour Philippe Lagente, les EJB ne s’imposent pas forcément pour accéder à une base de données : “Les EJB nécessitent des temps de développement longs et leurs temps de réponse sont assez importants. Excepté pour des pools de transactions, il vaut mieux, en général, utiliser un pilote JDBC pour accéder à une base de données et garder les EJB pour réaliser la communication entre applications. Les EJB Sessions sont, dans ce cas, utilisées comme moyen d’encapsulation transparent d’IIOP, le protocole de communication de Corba, afin d’exposer les méthodes d’une application.”
Attention à l’administration
Une fois l’application Java mise en production, il faut l’administrer. Ici tous les serveurs ne sont pas égaux devant la tâche. Pour Xavier Laurent, il est important, lorsque l’on possède plusieurs serveurs d’un même éditeur, de disposer d’une console d’administration commune.“Cela permet une gestion centralisée. Seul inconvénient, si l’on fait une erreur, elle s’applique à l’ensemble des serveurs.” Attention également aux paramètres présentés par la console d’administration. “Au minimum, vous devez pouvoir consulter l’occupation mémoire, celle de l’unité centrale, ou les processus en cours, estime Philippe Lagente. Si un composant occupe toute la mémoire, cela prouve qu’il est mal développé.” Avec une console graphique, cela simplifie encore les choses : “Si OC4J est fiable, son administration s’effectue en ligne de commandes, regrette Guillaume Pauchet. Nous sommes obligés de repasser par le système d’exploitation, en l’occurrence la distribution Linux de SuSe, pour voir les charges du serveur.” La qualité du service après-vente reste indispensable, comme le résume bien Xavier Laurent : “La vraie question, c’est de savoir quel sera le comportement de l’éditeur en cas de panne un samedi à 2 heures du matin !”
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
