Accueil > Veille > Notre blog de veille > Serveurs d’applications JEE : quel avenir pour les éditeurs ?

Serveurs d’applications JEE : quel avenir pour les éditeurs ?

Jean Goffinet 6 février 2008
8 commentaires

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.

 

8 commentaires

  • Waddle
    7/02/2008 - 11:46

    Bonjour,

    Je trouve votre billet pas très clair. Vous mélangez un peu de tout mais vous dites surtout de belles contre-vérités.

    Reprenons dans l’ordre :

    • Les serveurs open source sont à maturité depuis très longtemps. Tomcat est utilisé en production sur de nombreux site sérieux. JBoss sera selon Gartner le serveur JEE le plus utilisé en 2008 (devant WebSphere et WebLogic). WebSphere est basé sur Geronimo et WebLogic se meurt. Je dirai donc plutôt que seuls les serveurs open source sont mûrs aujourd’hui !
    • JBoss n’est pas basé sur Tomcat, il réutilise simplement sont conteneur de servlet. Ceci n’est qu’une des briques de JBoss AS. Je doute que l’implémentation des EJB 3, de JMS, et toutes les autres briques JEE soit basée sur Tomcat de prêt ou de loin.
    • Persistance, data layer, base de données vous mélangez tout. En fait, le data layer est la couche se chargeant de persister les données. La persistance est l’action de persister les objets et la base de données stock l’information. Ne mélangez pas tout sous prétexte de mettre de beaux mots un peu partout. De plus, vous parlez de JDBC mais jamais d’ORM. Plus aucun projet sérieux en Java n’est réalisé en pur JDBC. Comment occulté un tel élément. Surtout que seul le monde open source propose de bons ORM et que justement le meilleur est propriété de JBoss (Hibernate).
    • Pour finir, vous parlez d’EJB et de Spring. Et là, une question m’interpelle : avez-vous jamais utilisé Spring ? J’en doute. De quelle partie de Spring parlez-vous au juste pour le comparer aux EJB 3.0 ? Spring ne sait pas faire de persistance et les EJB ne font d’AOP... Soyez un peu plus précis.

    Pour ce qui est des EJB 3.0, laissez-moi donc vous suggérer quelque chose. Elles finiront comme leurs ainées. Elles sont inutiles, complexes et n’apportent aucune valeur ajoutée par rapport aux frameworks existants et utilisés couramment. Comme les EJB 2, il s’agit simplement d’un coup marketing, que tous les intégrateurs et éditeurs ignorants intègreront parce que "c’est la mode" (comme vous ?). Je laisserai les DSI se rendre compte de leurs erreurs et de revenir au final vers des SSII sérieuses.

    Pour finir, je dirais que votre article est technique mais il l’est trop ou pas assez. Il manque clairement d’intérêt car il représente une vision du marché tel qu’il était il y a 5 ans.

    Cordialement,

  • Jean Goffinet
    7/02/2008 - 17:53

    Bonjour,

    Merci pour vos commentaires et les précisions que vous apportez. En complément, j’ajouterai que JBoss ne repose pas nécessairement sur Tomcat, mais il peut l’utiliser comme moteur de servlet (cela n’est absolument pas obligatoire).

    Hibernate est effectivement aujourd’hui un framework incontournable pour assurer la persitance des données ; il n’a pas été cité dans l’article car il ne fait pas partie du serveur d’applications à proprement parler (il s’agit plutôt d’un framework, tout comme Spring au passage).

    Bien cordialement,

  • josuatree
    12/02/2008 - 01:28

    Mais quelle est la solution globale que vous suggérez alors ?
    JBoss/Tomcat/Hibernate sans EJB ?

    A quoi sert encore JBoss si l’on n’utilise pas les EJB ?

    Je sais je suis quelque peu novice, mais Waddle dites-en plus svp.

  • Waddle
    25/02/2008 - 21:13

    Pour tout dire, je ne pense pas qu’une "solution globale" fasse autoritée. Chaque besoin à sa solution. Toutefois, les EJB ne répondent à aucun besoin technique que d’autres frameworks plus légers peuvent atteindre.
    Pour répondre plus directement à votre intérogation, JBoss est utile sans les EJB puisqu’il s’agit d’un serveur J2EE et qu’à ce titre il ne se limite pas à un conteneur de Servlets supportant les EJB, il intègre une implémentation complète de J2EE.
    Pour vous donner toutefois quelques pistes, Hibernate est en effet incontournable pour la persistence. La couche MVC peut être confiée à Struts 2 (fusion de Struts et Webwork).
    Spring est incontournable aujourd’hui pour assurer une modularité aisée. Tout du moins Spring IoD (Injection de dépendances). Spring MVC est évidemment inutle si Struts est présent. Pour Spring AOP, je ne le recommande que si les personnes en charge des développements sont d’un haut niveau technique. En effet, l’AOP n’est pas enseigné et ses concepts demandent de déjà maitriser son sujet.
    Comme je l’ai dis plus haut, tout besoin requiert une solution adaptée. Ceci ne sont que de simples pistes, des briques élementaires à tout projet réussi aujourd’hui comme le sont devenus Maven, Ant ou JUnit

  • Medo
    5/05/2008 - 00:57

    J’apporte de l’eau au moulin de waddle, WebSphere n’est absolument pas basé sur Geronimo. Il existe bien un WebSphere Community Edition basé sur Geronimo mais qui n’a rien a avoir avec WebSphere Application server, IBM sont très claire sur la question

  • Davdou
    7/05/2008 - 08:39

    Bonjour,

    Personnellement, j’ai testé ces technologies dans deux projets.
    Projet 1 : Struts (MVC) + Spring (injection de dépendances) + Hibernate (Persistance) sous Tomcat.

    Projet 2 : JSF + EJB3 (Entités et Sessions) sous Jboss 4.2.

    Mon retour : Pas trop de difficultés pour appréhender Struts, par contre travaillant uniquement avec du gratuit sous Eclipse, je n’ai pas trouvé d’outils efficace pour configurer les différents fichiers xml. Bon, c’était il y a deux ans. Cela a peut -être changé.

    Concernant JSF et les EJB3 avec Eclipse Europa, Génial. Les annotations facilitent grandement le développement, et JSF est très facile à apprendre.
    Il y a même une annotation @EJB pour faire de l’injection. Malheureusement, @EJB ne fonctionne pas sous Jboss 4.2.

    J’ai aussi réalisé qq tests de webservice.
    Un point noir : Si je défini une relation entre deux Beans Entités avec un type Lazy (Ex : client et commande), le web service, lors de sérialisation xml va tout de même chercher à charger tout l’arbre des objets. Bref, il se moque de mes annotations.
    Exemple : Je demande un client au service web et il essaye de me retourner le client et ses commandes.

  • Christophe Bonche
    9/05/2008 - 11:00

    Bonjour,

    Lorsque l’on expose un bean à un outil de sérialisation, l’outil sérialise (par défaut) la totalité des propriétés du bean. Sinon il est toujours possible de gérer manuellement ou configurer (annotation, fichier xml...) les propriétés à sérialiser.
    En général lors de la création d’un webservice il est plus judicieux (et évolutif) d’utiliser des beans dédiés à ce dernier (relatif au contrat du service).
    Spring Webservice, permet de sélectionner l’api de sérialisation à utiliser et ainsi d’avoir la main sur le mapping Objet / Xml : spring ws.

    Ci dessous une liste de Plugins eclipse :

  • Sam
    22/06/2013 - 22:15

    Super article !