JEE : Introduction aux serveurs d’application et aux plateformes Java d’entreprise

Emmanuel BRUNO
emmanuel.bruno@univ-tln.fr

Université de Toulon

LIS UMR CNRS 7020

2026-11-07

Objectifs

À la fin de cette leçon, vous serez capable de :

  • Décrire le rôle d’un serveur d’application et les services techniques qu’il met à disposition de la logique métier.
  • Expliquer le modèle de conteneur : cycle de vie des composants, puis JNDI, classloading et packaging (JAR / WAR / EAR) — concepts des serveurs d’application classiques, à titre de culture générale, non utilisés par notre stack Quarkus qui produit un JAR unique.
  • Distinguer un conteneur de servlets, un serveur d’application complet et un framework cloud-native.
  • Situer les grandes familles de plateformes Java d’entreprise en 2026 : serveurs certifiés Jakarta EE, famille Spring et solutions cloud-native (Quarkus).
  • Justifier le choix de la stack pratique du cours (Quarkus) et lire l’arc pédagogique qui suit.

Des applications complexes à la plateforme

Les applications d’entreprise doivent répondre à des exigences qui dépassent largement le simple code métier : gestion de ressources partagées, fiabilité, distribution, sécurité. C’est précisément ce terrain que couvrent les plateformes Java d’entreprise.

  • Gestion des ressources :
    • Bases de données, systèmes de fichiers, services externes, etc.
    • Utilisation efficace et gestion des connexions, des pools de connexions, etc.
  • Accès distant et services :
    • Technologies modernes : REST, WebSocket, gRPC (sur TCP/IP)
    • RMI, solution historique, est aujourd’hui marginal
    • Communication entre services et intégration de systèmes distribués
  • Transactions :
    • Gestion des transactions, y compris les transactions applicatives
    • Assurer l’intégrité des données et la cohérence des opérations
  • Gestion et répartition de la charge :
    • Clustering et équilibrage de charge pour la disponibilité et la performance
    • Répartition des requêtes et gestion des sessions
  • Mise à jour sans interruption :
    • Mettre à jour ou redémarrer les serveurs sans interrompre le service
    • Déploiements continus et mises à jour en direct
  • Sécurité :
    • Authentification, autorisation, chiffrement des données
    • Protection contre les attaques et les vulnérabilités

Qu’est-ce qu’un serveur d’application ?

Un serveur d’application est une couche de middleware qui héberge les composants d’une application et leur fournit des services techniques, afin que les développeurs se concentrent sur la logique métier plutôt que sur les aspects d’infrastructure (transactions, sécurité, connexions, messagerie, déploiement).

Le modèle de conteneur. Le concept central n’est pas de « lancer un programme », mais d’héberger des composants dans des conteneurs. Chaque conteneur :

  • gère le cycle de vie des composants (création, mise en service, mise à jour, destruction) ;
  • expose un accès aux services techniques (transactions, sécurité, pools de connexions, messagerie) ;
  • permet de retrouver des ressources par nom grâce au JNDI (Java Naming and Directory Interface, l’annuaire logique du serveur) ;
  • charge les classes via un mécanisme de classloading structuré : chaque module dispose de son propre classloader, ce qui isole les applications déployées sur le même serveur.

Le parcours d’une requête

Modèle mental d’une requête (le fil à retenir) :

  1. Une requête HTTP arrive sur le port d’écoute du serveur.
  2. Le conteneur identifie la ressource concernée (routage) et prépare le contexte.
  3. Les services techniques interviennent : sécurité (authentification / autorisation), transaction, obtention d’une connexion au pool.
  4. La logique métier du composant est exécutée.
  5. La réponse est produite ; la transaction est validée ou annulée, la connexion est rendue au pool.

Les trois familles de runtime

Trois familles de runtime.

  • Conteneur de servlets (ex. Apache Tomcat) : héberge la partie web — servlets, ressources REST, WebSocket. C’est un sous-ensemble d’un serveur d’application.
  • Serveur d’application complet (ex. WildFly, Payara, Open Liberty) : conteneur de servlets plus les conteneurs métier (composants EJB, JMS, JTA, …). C’est la plateforme d’entreprise classique, déployée comme une infrastructure à part entière.
  • Framework cloud-native (ex. Quarkus, Spring Boot) : un serveur embarqué et une optimisation au build-time, pensés pour les conteneurs et le cloud. Le code s’exécute dans un JAR autonome, sans serveur d’application à installer séparément.

Quarkus est lui-même un conteneur (de type cloud-native) : les « services techniques » de l’étape 3 y sont assurés par CDI (injection de dépendances), Jakarta Persistence (JPA) et @Transactional.

Déploiement, packaging & runtime

Le code est regroupé en briques de packaging :

  • JAR : une bibliothèque ou un module Java ; en cloud-native, un JAR exécutable autonome.
  • WAR : une application web (composants web + configuration).
  • EAR : un regroupement de plusieurs modules (web + métier) déployé d’un seul tenant sur un serveur.

Deux modèles d’exécution :

  • Déploiement sur un serveur (WildFly, Payara) : on dépose un WAR ou un EAR ; le serveur fournit le runtime et les services.
  • Runtime embarqué (Quarkus, Spring Boot) : le serveur HTTP est intégré au JAR ; un quarkus build puis java -jar suffit, et le résultat est immédiatement prêt pour Docker / Kubernetes.

Dev vs prod : en développement, un dev mode avec hot-reload raccourcit le cycle ; en production, on vise un démarrage rapide, une empreinte mémoire réduite et un packaging conteneurisé.

Le paysage Java d’entreprise en 2026

Trois familles coexistent ; elles se distinguent par leur rapport aux standards et par leur cible d’exécution.

Serveurs certifiés Jakarta EE. Un serveur certifié garantit qu’il implémente la plateforme Jakarta EE (ou un profil) validée par la certification de compatibilité. État de la certification pour Jakarta EE 11 :

Serveur Éditeur Certification Jakarta EE 11
Open Liberty IBM Plateforme, Web, Core Profile
Payara Payara Community Plateforme, Web Profile
GlassFish Eclipse Plateforme, Web Profile (implémentation de référence)
WildFly Red Hat Core Profile uniquement (build preview)
Apache TomEE Apache Non certifié pour EE 11

Spring Framework et Spring Boot

La famille Spring. Spring est aujourd’hui le plus largement utilisé dans l’industrie. C’est un écosystème complet et mature, structuré autour de :

  • Spring Framework : le socle (inversion de contrôle, conteneur IoC).
  • Spring Boot : la « convention over configuration », avec serveur embarqué et applications autonomes.
  • Spring Data : la persistance (JPA, repositories).
  • Spring Security : l’authentification et l’autorisation.
  • Spring MVC / WebFlux : le web (requête / réponse, ou réactif).

Spring n’est pas une spécification Jakarta EE : il fournit ses propres API, bien que certaines restent compatibles avec les standards.

Cloud-native.

  • Quarkus (Red Hat) + MicroProfile : une approche cloud-first qui combine les spécifications Jakarta EE et MicroProfile, avec un démarrage quasi instantané et une compilation native. C’est notre stack pratique pour les TP de ce cours.
  • Micronaut : un autre framework cloud-native, orienté microservices, avec une injection de dépendances résolue au build-time.

Architecture et tiers

L’architecture en couches (multi-tiers) structure les responsabilités de l’application, depuis le client jusqu’aux données.

  • Tier Client
    • Navigateurs web (HTML5/JS), applications mobiles, clients Java SE, clients REST
  • Tier Web
    • Présentation : Jakarta Faces, Jakarta Pages
    • Contrôleurs : Jakarta Servlet, Jakarta REST (JAX-RS), Jakarta WebSocket
  • Tier Entreprise (métier)
    • Services métier : Enterprise JavaBeans (EJB), Jakarta CDI, Jakarta Transactions (JTA)
    • Messagerie : Jakarta Messaging (JMS)
  • Tier Données
    • Persistance : Jakarta Persistence (JPA)
    • Transactions : Jakarta Transactions (JTA)

Jakarta EE : l’umbrella de standards

Jakarta EE est une plateforme parapluie : un ensemble de spécifications standardisées qui définissent des API communes. L’idée est d’écrire du code contre ces API standard, et de le rendre ainsi portable d’un serveur certifié à l’autre.

  • Portabilité : le même code, fondé sur les API Jakarta, fonctionne sur tout serveur certifié Jakarta EE.
  • Gouvernance : la plateforme est gérée par la Fondation Eclipse depuis 2017 ; les spécifications sont ouvertes et communautaires, et les serveurs passent une certification de compatibilité.
  • Version actuelle : la dernière version de la plateforme est Jakarta EE 11 (2025).

Les spécifications utiles au cours

Les spécifications au cœur de notre arc (liste volontairement resserrée) :

  • Jakarta Servlet — le conteneur web et la gestion HTTP.
  • Jakarta REST (JAX-RS) — les services web REST. Rappel : étudié l’année dernière.
  • Jakarta Persistence (JPA) — le mapping objet-relationnel. Rappel : étudié l’année dernière.
  • Jakarta CDI — l’injection de dépendances et la gestion des contextes (au centre du cours).
  • Jakarta Transactions (JTA) — la gestion des transactions distribuées.
  • Jakarta Security — l’authentification et l’autorisation.
  • Enterprise JavaBeans (EJB) — spécification mature, toujours présente dans la Plateforme Jakarta EE complète, en mode maintenance ; non implémentée par Quarkus (qui utilise CDI). Citée pour complétude, pas comme une compétence à acquérir.
  • MicroProfile — un ensemble de spécifications qui complète Jakarta EE pour les microservices (health, metrics, config, fault tolerance, OpenAPI, …).

Documentation : les spécifications Jakarta EE sont publiées sur le site officiel jakarta.ee.

Évolution historique & virage cloud-native

Ère J2EE (1999–2006)

  • 1999 : J2EE — première plateforme d’entreprise (EJB, Servlet, JSP)
  • Complexité critique : XML verbeux, EJB difficiles
  • 2004 : Spring Framework émerge comme alternative légère

Ère Java EE (2006–2017)

  • 2006 : Java EE 5 — simplification (annotations, JPA)
  • 2009 : Java EE 6 — CDI et Web Profile
  • 2017 : Java EE 8 — dernière version sous Oracle

Ère Jakarta EE (2017–présent)

  • 2017 : transfert à la Fondation Eclipse
  • 2020 : Jakarta EE 9 — changement de namespace (javax.* → jakarta.*)
  • 2022 : Jakarta EE 10 — virage cloud-native
  • 2025 : Jakarta EE 11 (26 juin 2025) — consolidation cloud-native

L’émergence cloud-native (2015–2020)

  • Problème : les serveurs traditionnels sont peu adaptés au cloud
  • 2018 : Quarkus (Red Hat) — compilation native GraalVM
  • 2021 : Spring Native — réponse à Quarkus
  • Résultat : innovation accélérée, choix multiples

Fil conducteur : d’une J2EE lourde, vers une Spring Framework simple, puis une Jakarta EE modernisée, et enfin Quarkus et le cloud-native.

Choisir sa stack

Le choix d’une stack dépend de la cible, de l’écosystème existant et des contraintes (cloud, conteneurs, certification).

Comparaison des familles

Famille Spring

  • Forces
    • Écosystème le plus riche et le plus mature
    • Le plus largement utilisé dans l’industrie
    • Documentation abondante
    • Convention over configuration
  • Philosophie
    • Framework « opinionné »
    • Serveur embarqué (Tomcat/Jetty), JAR autonome

Quarkus (Jakarta EE + MicroProfile)

  • Forces
    • S’appuie sur les spécifications Jakarta EE
    • Démarrage quasi instantané, empreinte mémoire réduite
    • Optimisé conteneurs / cloud, compilation native
  • Philosophie
    • Standards + MicroProfile
    • Optimisation au build-time

Tableau comparatif

Critère Spring Boot Quarkus Jakarta EE (Liberty/Payara)
Standards API propriétaires Spring Spécifications Jakarta EE + MicroProfile Plateforme Jakarta EE complète
Certification Non certifiée Non certifiée (specs individuelles) Certifiée Jakarta EE
Injection Spring IoC CDI (Jakarta) CDI (Jakarta)
Web / REST Spring MVC / WebFlux JAX-RS JAX-RS
Persistance Spring Data / JPA JPA (Hibernate Panache) JPA
Conteneur Embarqué (Tomcat/Jetty) Embarqué Serveur à part entière
Packaging JAR exécutable JAR / binaire natif WAR / EAR
Démarrage (indicatif) ~3–5 s < 1 s en JVM, quasi instantané en natif ~8–10 s
Mémoire (indicatif) ~100–150 Mo ~20 Mo natif / ~70 Mo JVM ~150–200 Mo
Use cases Tout type, monolithes Microservices, cloud, conteneurs Enterprise traditionnelle

Chiffres indicatifs : les valeurs de démarrage et de mémoire sont des ordres de grandeur typiques, pas des garanties ; elles varient selon l’application, le système et le mode d’exécution (JVM vs natif).

Quel framework choisir ?

  • Spring Boot : projets dans un écosystème Spring existant, équipes Spring, monolithes.
  • Quarkus : ✅ notre choix pour ce cours — cloud-native, microservices, conteneurs, performance. Il s’appuie sur les spécifications Jakarta EE (sans certification complète de la plateforme).
  • Liberty/Payara (Jakarta EE) : besoins de certification Jakarta EE complète, systèmes enterprise classiques, migrations legacy.

Transférabilité : les concepts (injection de dépendances, REST, JPA) se transfèrent entre Spring et Jakarta EE.

Premier contact avec Quarkus

Quarkus est notre stack pratique. En termes conceptuels, il offre :

  • Un Dev Mode avec hot-reload et une Dev UI interactive.
  • Un positionnement standards-based (Jakarta EE + MicroProfile).
  • Un démarrage rapide et une empreinte mémoire réduite, y compris en compilation native.

Baseline du cours : Java 21 (LTS). Jakarta EE 11 elle-même se contente de Java SE 17 ; c’est le choix de Quarkus, qui requiert Java 21 ou supérieur, qui fixe notre baseline à Java 21.

Un premier contact minimal — créer un projet et exposer une ressource REST :

quarkus create app com.example:hello --extension=rest-jackson
@Path("/hello")
public class HelloResource {
    @GET
    public String hello() {
        return "Bonjour, Jakarta EE !";
    }
}

Goutte minimale : ce brouillon n’expose qu’une ressource brute ; le TP le complète avec la réponse JSON (Jackson) et la persistance JPA (Panache).

TP : la construction de bout en bout d’une première application (projet, entité JPA, repository, ressource REST, base H2, tests) fait l’objet du TP dédié : « Première application Quarkus — TP » (01_java_jee_P_first-quarkus-app.qmd).

Où nous allons

Vous avez déjà étudié JPA et JAX-RS l’année dernière ; ils servent ici de socle. L’arc de ce cours :

  1. Introduction (ici) — serveurs d’application, plateformes, choix de stack.
  2. CDI — l’injection de dépendances et les contextes.
  3. Transactions — la gestion transactionnelle.
  4. MicroProfile — les API cloud-native pour microservices.
  5. Sécurité — authentification et autorisation.
  6. Tests — tester les applications.

À retenir

  • Un serveur d’application fournit des services techniques (transactions, sécurité, connexions, messagerie) et gère le cycle de vie des composants via le modèle de conteneur.
  • On distingue un conteneur de servlets, un serveur d’application complet et un framework cloud-native (runtime embarqué).
  • Le code se package en JAR / WAR / EAR — WAR et EAR relevant des serveurs d’application classiques, à titre de culture générale ; notre stack Quarkus produit un JAR unique. Il s’exécute soit sur un serveur, soit dans un runtime embarqué (Quarkus, Spring Boot) prêt pour les conteneurs.
  • Trois familles de plateformes coexistent : serveurs certifiés Jakarta EE, la famille Spring, et le cloud-native (Quarkus + MicroProfile).
  • Quarkus est notre stack pratique ; les concepts Jakarta EE restent portables et transférables vers Spring.