Le serveur d’applications: quand l’unité centrale devient logicielle
Ce nouveau c?”ur du système s’enrichit de briques logicielles destinées à gérer le sans-fil, les sites d’e-commerce, le portail ou l’intégration d’applications.
Le serveur d’applications n’est plus à présenter. Tout simplement parce que cette brique d’infrastructure tend aujourd’hui à se banaliser. Elle est le fruit d’une longue quête de normalisation des architectures logicielles, entamée il y a longtemps. Après avoir planché des années sur la standardisation des interfaces programmatiques du système d’exploitation Unix, l’Open Group, fusion de l’X/Open et de l’OSF (The Open Software Foundation), insistait au milieu des années quatre-vingt-dix sur l’impératif de disposer d’environnements distribués ouverts et normalisés. Le middleware ?” domaine technologique ayant trait à la communication de deux briques applicatives distantes ?” focalisait alors toutes les attentions. D’autant plus que, après l’époque des systèmes centralisés et monolithiques chers aux grands systèmes, le client-serveur a conduit à une hétérogénéité galopante des pans du système d’information, dont il fallait gérer l’interopérabilité. Ce fut l’heure de gloire des moniteurs transactionnels propriétaires ?” Tuxedo, Encina, etc.L’explosion d’internet n’a fait qu’exacerber le modèle d’une informatique orientée réseaux par définition, répartie et basée sur une architecture à plusieurs niveaux ?” présentation, traitement et stockage des données. C’est en 1998, sur fond de confrontation farouche opposant les modèles objet distribués COM/DCOM (Microsoft) et Corba (OMG), que Sun a publié la première spécification de son propre modèle, baptisé Enterprise Javabeans (EJB). C’est à partir de cette date que l’on a commencé à parler de serveur d’applications, présenté comme le système d’exploitation internet. Pour le cabinet de conseil Owendo, il s’agit d’“un environnement de l’architecture qui fournit les briques techniques nécessaires à l’exécution d’applications transactionnelles web”. Une définition sous laquelle il est possible de ranger plusieurs types de plates-formes de déploiement logiciel : le quatuor Lamp (Linux, Apache, MySQL, PHP), .Net de Microsoft et J2EE (Java 2 Enterprise Edition), le nom de celle de Sun, loin désormais de se résumer aux seuls EJB. Cette dernière peut se prévaloir aujourd’hui d’un réel consensus. Comme l’observe Didier Girard, directeur technique de la société de services Improve, “les grands comptes ont, dans une large majorité, basculé vers une architecture Java”.
Polémique autour des Entity Beans
Le ralliement à J2EE n’est pas pour autant synonyme d’adoption de l’ensemble des services techniques offerts par cette plate-forme. Certes, “dans sa version 1.2, J2EE atteint un bon niveau de maturité, souligne Dominique Jocal, consultant chez Octo Technology. Ce qui permet d’utiliser le serveur d’applications de façon industrielle”. Reste que, dans l’hexagone et jusqu’au début 2001, les EJB brillaient par leur absence dans les projets de développement d’applications web.Dans un rapport de fin 2000, le Gartner Group prévoyait qu’en 2001, globalement, les EJB ne seraient utilisés que dans à peine 8 % des projets internet. Un taux d’utilisation qui, pour le duo formé par les composants Servlets et les pages JSP (Java Server Pages), s’élèverait cette année à plus de 60 %. Dans son rôle de prescripteur de technologies, certains pensent qu’IBM évitait d’encourager l’usage des EJB, son produit Websphere n’ayant supporté pendant longtemps que la version 1.0 ?” rudimentaire ?” des EJB. Pour une conformité aux EJB 1.2, il a fallu attendre la toute dernière version 4 du serveur d’applications de Big Blue. “IBM a constitué un frein à l’emploi des EJB, déclare sans ambages Bruno de Combiens, responsable marketing produits chez Borland France. Ces composants comportent indiscutablement des lacunes. Mais ce n’est pas une raison pour dire que cette voie n’est pas viable.” Les EJB ont en effet leur talon d’Achille. De quoi fournir une raison moins sujette à polémique à leur faible diffusion : la spécification des composants EJB dits Entity Beans, dont la fonction est d’assurer la persistance objet des données stockées dans des bases relationnelles, fut décriée par l’ensemble de l’industrie. Au point que Sun l’a entièrement réécrite dans la version 2.0 des EJB pour prendre enfin en compte la notion d’association entre objets. Cependant, “il faudra patienter jusqu’en 2002 avant d’oser mettre en production des Entity Beans”, affirme Dominique Jocal.Ce défaut n’a pas empêché, l’an dernier, les éditeurs de serveurs d’applications de se lancer dans une course effrénée à la certification J2EE. De six à la mi-2000, on est passé à onze produits marqués de l’estampille de Sun. Si J2EE mène à une banalisation de l’infrastructure applicative pour le web, se posait alors un sérieux problème pour ces fournisseurs : comment se différencier face à la concurrence ? La solution consiste à élargir le spectre fonctionnel de leur moteur de déploiement. C’est ainsi que sont apparus, au cours de l’année 2000, des frameworks dédiés à l’édification de sites de commerce électronique ?” chez BEA avec Weblogic Commerce Server, par exemple. Une extension à laquelle il convient d’associer les serveurs de personnalisation (Websphere Personalization Server ou Weblogic Personalization Server). Au vu de la nouvelle opportunité apportée par le commerce mobile, les serveurs J2EE se sont également enrichis de modules voués à la création d’applications sans fil déportées sur les terminaux légers (téléphones, assistants personnels, etc.). Quant aux dernières avancées des éditeurs, elles portent sur l’adjonction de frameworks dans le domaine des portails d’entreprise et de l’intégration d’applications dans un contexte d’échanges électroniques entre entreprises.
