Le marché des logiciels libres professionnels continue de se développer à un rythme soutenu. Après avoir investi initialement les couches basses du système d’information (middleware), les solutions Open Source commencent maintenant à concurrencer sérieusement les produits propriétaires dans toute une gamme d’applications d’entreprise, et jusqu’aux logiciels grand public (suites bureautiques, outils internet…).
Clever Age vous propose une analyse de ce marché, à travers une série d’études menées dans les domaines les plus représentatifs de l’informatique d’entreprise. Chaque étude comprend un décryptage des principales tendances du marché, des retours d’expériences significatifs, une présentation d’architectures types, ainsi qu’une sélection de critères permettant de se poser les bonnes questions au moment de choisir une solution.
Le premier volet de la série est consacré au marché des serveurs d’applications JEE. A venir prochainement : les solutions de gestion de contenu.
Les tendances du marché
Le serveur d’applications est un composant central du système d’information. Les solutions des éditeurs d’infrastructure se sont imposées rapidement pour leur robustesse, leur outillage, mais aussi les offres de support qui les accompagnent. Les solutions Open Source ont fait leur apparition en même temps que les standards (principalement JEE) ; très utilisées pour les développements, elles n’arrivent vraiment à maturité que depuis peu et on observe enfin les premiers sérieux retours d’expérience en production.
A noter une exception pour le moteur de Servlets Tomcat, de la fondation Apache, qui est quasiment incontournable aujourd’hui (il est utilisé par bon nombre de serveurs JEE, Open Source ou propriétaires, comme par exemple JBoss ou Websphere). Mais n’étant pas à proprement parler un serveur JEE (il n’implémente qu’une partie de la norme, qui ne comprend ni les EJB, ni JMS entre autres), il est généralement utilisé pour des applications relativement peu connectées au système d’information. A l’inverse, un grand nombre d’applications déployées dans un serveur JEE tourneraient aussi bien dans un simple moteur de Servlets.
La véritable adoption des serveurs d’applications Open Source par les DSI va nécessiter quelques années, car remettre en question cette brique stratégique a des impacts assez importants en matière de coûts. Il faut bien souvent reprendre une à une toutes les applications et les adapter pour les faire tourner sur un nouveau type de serveur, ce malgré la standardisation. En effet, les éditeurs ont une fâcheuse tendance à s’écarter à la marge des standards, ce qui d’une part casse la compatibilité avec les autres serveurs d’applications, et d’autre part rend la montée de version au sein d’un même serveur d’applications longue et fastidieuse. Ce problème est moins fréquent avec les solutions Open Source, qui sont généralement plus respectueuses des standards.
Mais le mouvement actuel de ces mêmes éditeurs pour ouvrir le socle technique de leurs serveurs (Sun Application Server est aujourd’hui le nom « marketing » du serveur Open Source Glassfish ; IBM utilise le serveur Geronimo – de la fondation Apache – comme base de Websphere Application Server) pourrait bien accélérer le mouvement.
Aujourd’hui, les principales alternatives aux serveurs d’applications propriétaires sont :
– JBoss (un projet français à l’origine, qui a été racheté en 2006 par RedHat ; sans doute le plus déployé à ce jour des serveurs JEE Open Source) ;
– Glassfish (autre nom pour Sun AS) ;
– Geronimo (qui sert de socle à Websphere AS) ;
– JOnAS (du consortium d’origine française ObjectWeb).
|JEE ou J2EE ? On a pendant longtemps parlé de la « plateforme J2EE », mais qui se souvient encore de l’origine de ce « 2 » ? C’est Sun qui a décidé de rebaptiser son langage « Java 2 » à partir de la version 1.2 du Java Development Kit (JDK), nom qui est resté dans les versions suivantes. C’est ainsi que la plateforme entreprise de Java s’est au départ appelée « Java 2 Enterprise Edition ». Mais pour des raisons marketing, Sun a décidé de rebaptiser cette plateforme « Java Enterprise Edition » (en supprimant le 2) à compter de la version 1.5… qui a elle-même été changée en « 5 » ! On parle donc de J2EE 1.4, mais de JEE 5.|
Exemples de projets réussis
Une grande compagnie d’assurance fait confiance à Tomcat depuis 2003 pour sa plateforme e-commerce
Notre client est une compagnie d’assurance spécialisée dans la prise en charge individuelle (assurance annulation, rapatriement…). Pour s’intégrer avec ses partenaires, deux modes sont proposés :
– soit un site en marque blanche (le service est alors hébergé entièrement sur la plateforme de la compagnie d’assurance, avec la charte graphique du partenaire) ;
– soit sous la forme de Web Services (un premier service permet de faire le pricing, tandis qu’un second prend en charge la souscription d’un contrat).
La compagnie d’assurance a mis en place deux plateformes pour répondre à ce besoin :
– e-commerce gateway : il s’agit d’un Front Office proposant les services en lignes aux partenaires ;
– e-commerce connector : plateforme Back Office chargée de la facturation et à laquelle accèdent les différentes Business Units (géographiques ou dédiée à un partenaire).
Depuis l’ouverture du service en 2003, la compagnie d’assurance a choisi de faire confiance au couple Apache (serveur Web) / Tomcat (serveur d’applications), reliés entre eux par le connecteur mod_jk. En 2007, tous les serveurs ont été migrés de Linux RedHat vers SPARC / Solaris afin de gagner en performances (gain d’un facteur 2 à 10 suivant les applications) et surtout dans un souci d’homogénéisation du parc informatique, l’architecture applicative restant.
Un acteur majeur du luxe s’appuie sur JBoss pour le lancement de ses nouveaux sites
Afin de lancer sa nouvelle plateforme de sites Web début 2008, un acteur français majeur du luxe a mis en place une architecture haute disponibilité reposant principalement sur le serveur d’applications JBoss. Pour remplacer ses anciens serveurs ATG Dynamo (notamment pour des questions d’obsolescence et de coût), le choix s’est porté sur JBoss, en raison de retours d’expériences probants, de l’absence de coûts de licence et de la possibilité de mise en cluster (avec réplication des sessions pour une tolérance aux pannes optimisée).
De plus, l’outil de gestion de contenus retenu (Noheto, de l’éditeur français du même nom), s’appuie sur une infrastructure JMS pour partager les informations entre les différentes instances (expiration du cache notamment).
Autour de JBoss, on trouve une base de données MySQL, hébergée sur un serveur dédié, qui est répliquée à chaud pour assurer la haute disponibilité. Avec un serveur physique pour la saisie des contenus, et deux pour assurer leur diffusion, la plateforme est capable de servir plus de 50 pages par seconde.
Architectures types
Architecture JEE (vue logique)
Le schéma ci-dessous présente une architecture multi-tiers JEE classique.
L’utilisateur (via son navigateur) ou une application tierce (via des Web Service SOAP ou REST) se connecte sur le serveur Web (généralement un serveur Apache). Celui-ci est généralement chargé de servir directement les pages statiques (images, pièces jointes, feuilles de styles, etc.) et délègue la gestion des pages dynamiques au serveur d’applications (via le protocole AJP).
Le serveur d’applications a en charge d’une part la couche présentation (presentation layer), réalisée au moyen de Servlets ou de JSP (qui sont en réalité également des Servlets), et d’autre part la couche métier (business layer). Dans bien des cas, un conteneur de Servlets (de type Tomcat) suffit, puisqu’il est capable de gérer lui-même des Beans (que l’on peut faire persister). Mais pour gérer le cycle de vie complet de ces objets Java (instanciation, persistance, etc.), il peut être utile d’avoir recours à des EJB, qui s’exécutent au sein d’un conteneur d’EJB. Les appels aux EJB se font alors via le protocole RMI.
La persistance (couche données, ou data layer) est généralement assurée par une base de données relationnelle, les échanges entre le serveur d’applications et le serveur de base de données se faisant au moyen du protocole JDBC.
Enfin, le serveur d’applications JEE discute avec d’autres applications via un bus de services JMS. Les applications externes peuvent notamment se connecter au bus JMS via des connecteurs JCA.
|Spring ou EJB ? Les EJB ont longtemps souffert de problèmes de performances et de lourdeur de développement dus à des choix de conception peu appropriés. Un framework Open Source concurrent, Spring, ne nécessitant pas l’utilisation d’un serveur JEE mais pouvant se contenter d’un simple conteneur de Servlets, a fait alors son apparition (on parle à propos de Spring de « conteneur d’objets léger ») et a connu un grand succès. Spring est rapidement devenu une alternative crédible à l’utilisation des fonctionnalités natives des serveurs d’applications telles que la gestion de la sécurité, des pools de connexion, etc. Mais depuis la sortie de la norme 3.0 des EJB, ces derniers sont redevenus à la mode. Aujourd’hui, chaque technologie a ses supporteurs et ses détracteurs, et le choix de partir sur l’une ou l’autre dépend généralement de facteurs externes (L’architecture requiert-elle par ailleurs un serveur JEE complet ? Quelles sont les compétences des équipes de développement ? D’exploitation ? Etc.).|
Exemple d’architecture physique
L’architecture présentée ci-dessous correspond à un déploiement de la solution de gestion de contenu Noheto. Cette architecture est découpée en plusieurs couches :
– les instances de restitution (Front Office), qui servent les pages destinées à l’internet grâce à des serveurs Apache / JBoss load-balancés situés dans une DMZ ;
– un serveur de fichier (qui stocke toutes les pièces jointes, les images, les vidéos, etc.), accessible à la fois par le Front Office et le Back Office ;
– une base de données MySQL « esclave », qui est une réplication de la base de données « maîtresse » et n’est accessible qu’en consultation par les instances du Front Office ;
– une base de données MySQL « maîtresse », qui sert à la contribution depuis les instances de Back Office ;
– l’instance de contribution (Back Office), accessible uniquement depuis l’intranet (serveur JBoss) ;
– enfin, d’autres applications (CRM, SAP), dont certaines communiquent avec le Back Office au moyen de Web Services et / ou d’exports / imports XML.
Les critères de choix
Le choix d’un serveur d’applications repose sur des critères liés au serveur lui-même, mais aussi liés à l’outillage fourni autour du serveur. Parmi les critères techniques d’évaluation d’un serveur d’applications, on trouve :
– le respect des standards (en particulier, la version de JEE implémentée) et le niveau de certification (un serveur certifié est une garantie de pouvoir exécuter des applications standards) ;
– les fonctionnalités de répartition de charges (load-balancing) et de tolérance aux pannes (failover) ;
– la reprise sur incident au niveau applicatif (redémarrage automatique) et session (récupération des sessions en cours) ;
– le (re)déploiement à chaud (notamment dans le cas d’une ferme de serveurs) ;
– la richesse des API techniques (impressions, images, messagerie…) et des frameworks métier (personnalisation, portails…) ;
– la gestion de la sécurité (en particulier, la compatibilité avec les solutions d’authentification et de Single Sign On) ;
– la présence d’un conteneur OSGi (qui donne un cadre et facilite le déploiement d’applications Java)
– les performances brutes (temps de démarrage, de déploiement d’une application…) ; pour cela, il peut être utile de s’appuyer sur des comparatifs.
Les critères techniques liés aux outils complémentaires au serveur d’applications comprennent :
– l’intégration avec atelier de développement (Eclipse, Netbeans, RAD…) ;
– les fonctionnalités proposées par l’IDE (débogage, mise en forme HTML, tests unitaires…) ;
– la capacité de s’interfacer avec des outils tiers (modélisation, gestion de projets, reporting…) ;
– la console d’administration (richesse fonctionnelle, possibilités d’intégration…).
Mais le choix d’un serveur d’applications repose dans une large mesure sur l’existant : il sera certainement plus facile de migrer de Websphere vers Geronimo (étant donné la parenté qui existe entre les deux) que vers JBoss ou JOnAS.
