Web 06 Plateforme Java Ee

Plateforme Java EE

1. La plateforme Java Entreprise Edition

Java Platform, Enterprise Edition, Java EE ou Jakarta EE (anciennement Java 2 Platform, Enterprise Edition), est une spécification pour la plate-forme Java d’Oracle, destinée aux applications d’entreprise.

Duke, mascotte Java

La plate-forme étend Java Platform, Standard Edition (Java SE) en fournissant une API de mapping objet-relationnel, des architectures distribuées et multitiers, et des services web. La plate-forme se fonde principalement sur des composants modulaires exécutés sur un serveur d’applications.

Logo Jakarta EE

À Lire : Java EE is OFFICIALLY retired. It’s now called Jakarta EE. How did we get here?

Pour ce faire, Java EE définit les éléments suivants :

  • une plate-forme (Java EE Platform), pour héberger et exécuter les applications, incluant outre Java SE des bibliothèques logicielles additionnelles du Java Development Kit (JDK) ;
  • une suite de tests (Java EE Compatibility Test Suite) pour vérifier la compatibilité ;
  • une réalisation de référence (Java EE Reference Implementation), dénommée GlassFish ;
  • un catalogue de bonnes pratiques (Java EE BluePrints) ;
  • un code script.

À chaque version de Java EE correspond notamment, comme toutes les éditions Java :

  • les Java Specification Requests (JSR), constituant les spécifications de la version considérée ;
  • un Java Development Kit (JDK), contenant les bibliothèques logicielles ;
  • un Java Runtime Environment (JRE), contenant le seul environnement d’exécution (compris de base dans le JDK).

1.1. Positionnement de Java EE

Alors que Java SE constitue le framework de référence pour Java — avec des bibliothèques standards répondant à la plupart des besoins —, Java EE complète ce framework avec des bibliothèques logicielles additionnelles dédiées à des applications professionnelles, facilitant par exemple le développement d’applications pour architecture distribuée.

Les JDK spécifiques à Java EE sont conçus de façon à ce qu’une application réalisée avec Java EE fonctionne sur le même JRE qu’une application écrite avec Java SE ; toutefois elle nécessitera que les bibliothèques exploitées soient fournies par un conteneur Java lourd tel que Apache Tomcat, JBoss ou JOnAS, ou léger tel que Spring.

La première version des spécifications de Java EE fut publiée en 1999, la version 1.3 apparut en 2001, puis la version 1.4 en 2003 (support XML et services Web) et la version 1.5 (renommée Java EE 5) en 2007. La version en cours est Java EE 11.

En 2018, le projet est confié par Oracle à la Fondation Eclipse, et le nom Jakarta EE est choisi par la communauté des développeurs à la place de Java EE.

Source : Java EE

1.2. Java Community Process

Le Java Community Process (JCP) est une organisation créée par Sun en 1998. Son but est de coordonner l’évolution du langage Java et des technologies qui lui sont associées (voir la plateforme Java). Le JCP s’est doté d’un processus formalisé permettant aux différentes parties intéressées d’être impliquées dans la définition des futures versions et fonctionnalités de la plateforme Java.

Le JCP émet des Java Specification Requests (JSR), qui décrivent les spécifications et technologies proposées pour un ajout à la plateforme Java. Des revues publiques formelles des JSRs sont menées avant qu’une JSR ne devienne finale et qu’elle ne soit votée par le comité exécutif du JCP. Une JSR finale fournit une implémentation de référence qui offre :

  • une implémentation gratuite de la technologie sous la forme de code source,
  • un ensemble de tests - le Technology Compatibility Kit (TCK) - pour vérifier la compatibilité d’une implémentation avec la spécification.

Le JCP est composé d’entreprises du domaine Java, comme Sun, IBM, Oracle, Borland, BEA, Nokia, Sony, mais aussi de fondations du monde du logiciel libre, comme OW2, ainsi que des particuliers, pour lesquels l’adhésion est libre.

Source : Java Community Process

2. Composants Java EE

  • Servlet : Composant représentant le C (Controller) du paradigme MVC
  • Portlet : Conteneur Web (extension de l’API Servlet)
  • JavaServer Pages (JSP) : Framework Web
  • Java Standard Tag Library (JSTL) : bibliothèque de balises pour les JSP
  • JavaServer Faces (JSF) : Java Server Face, Framework Web
  • EJB : Composants distribués transactionnels
  • JNDI : API de connexion à des annuaires, notamment des annuaires LDAP, et espace de noms d’objet (ENC)
  • JDBC : API de connexion à des bases de données
  • Java Message Service (JMS) : API de communication asynchrone par message
  • JCA : API de connexion, notamment à des PGI
  • JavaMail : API de gestion des mails
  • JMX : Extension d’administration des applications
  • JPA : API de gestion de la persistance des données
  • JTA : API de gestion des transactions
  • Java API for XML Processing (JAXP) : API d’analyse XML
  • JAXM : API de communication asynchrone par XML
  • JAX-RPC / JAX-WS : API de communication synchrone par XML, par exemple à l’aide du protocole SOAP
  • JAXB : API de sérialisation par XML
  • JAXR : API de gestion des registres XML, permettant d’enregistrer des Web Services en ebXML
  • Java RMI : API de communication distante entre des objets Java
  • Java IDL : API de communication entre objets Java et objets non-Java, via le protocole CORBA

Source : Java EE

2.1. Servlets

Un servlet est une classe Java qui permet de créer dynamiquement des données au sein d’un serveur HTTP. Ces données sont le plus généralement présentées au format HTML, mais elles peuvent également l’être au format XML ou tout autre format destiné aux navigateurs web. Les servlets utilisent l’API Java Servlet (package javax.servlet).

Un servlet s’exécute dynamiquement sur le serveur web et permet l’extension des fonctions de ce dernier, par exemple : l’accès à des bases de données, transactions de commerce en ligne, etc. Un ou une servlet peut être chargé automatiquement lors du démarrage du serveur web ou lors de la première requête du client. Une fois chargés, les servlets restent actifs dans l’attente d’autres requêtes du client.

L’utilisation de servlets se fait par le biais d’un conteneur de servlets (framework) côté serveur. Celui-ci constitue l’environnement d’exécution de la servlet et lui permet de persister entre les requêtes des clients. L’API définit les relations entre le conteneur et le/la servlet. Le conteneur reçoit la requête du client, et sélectionne le/la servlet qui aura à la traiter. Le conteneur fournit également tout un ensemble de services standards pour simplifier la gestion des requêtes et des sessions.

Un ou une ou plusieurs servlets constituent les applications web Java, leur principe de fonctionnement (architecture, fonctionnalités, configuration, déploiement) est décrit suivant une spécification officielle, menée par Sun Microsystems et à laquelle toute personne peut contribuer par le biais des Java Specification Requests (Java Community Process). La version actuelle des spécifications servlet est la 4.0.

Il existe plusieurs conteneurs de servlets, dont Apache Tomcat ou encore Jetty. Le serveur d’application JBoss Application Server utilise Apache Tomcat.

Source : Servlet

Exemple de Servlet

Les servlets sont donc des classes Java qui servent les requêtes HTTP et implémentent l’interface javax.servlet.servlet.Servlet. Les développeurs d’applications Web écrivent généralement des servlets qui étendent javax.servlet.http.http.HttpServlet, une classe abstraite qui implémente l’interface Servlet et qui est spécialement conçue pour traiter les requêtes HTTP.

Soit le code /usr/ServletDevel/HelloWorld.java

// Import required java libraries
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

// Extend HttpServlet class
public class HelloWorld extends HttpServlet {

   private String message;

   public void init() throws ServletException {
      // Do required initialization
      message = "Hello World";
   }

   public void doGet(HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException {

      // Set response content type
      response.setContentType("text/html");

      // Actual logic goes here.
      PrintWriter out = response.getWriter();
      out.println("<h1>" + message + "</h1>");
   }

   public void destroy() {
      // do nothing.
   }
}
Compilation
javac HelloWorld.java
Déploiement de l’application avec Tomcat

Par défaut, une application de servlet est située dans le chemin d’accès <Tomcat-installation-indirectory>/webapps/ROOT et le fichier de classe se trouve dans <Tomcat-installation-indirectory>/webapps/ROOT/WEB-INF/classes.

Si vous avez un nom de classe complet com.myorg.MyServlet, alors cette classe de servlet doit être située dans WEB-INF/classes/com/myorg/MyServlet.class.

Copions HelloWorld.class dans <Tomcat-installation-indirectory>/webapps/ROOT/WEB-INF/classes et créons les entrées suivantes dans le fichier web.xml situé dans <Tomcat-installation-directory>/webapps/ROOT/WEB-INF/ :

<servlet>
   <servlet-name>HelloWorld</servlet-name>
   <servlet-class>HelloWorld</servlet-class>
</servlet>

<servlet-mapping>
   <servlet-name>HelloWorld</servlet-name>
   <url-pattern>/HelloWorld</url-pattern>
</servlet-mapping>

Les entrées ci-dessus doivent être créées dans les balises <web-app>...</web-app> disponibles dans le fichier web.xml. Il peut y avoir plusieurs entrées dans cette table déjà disponibles, mais peu importe.

Cela est presque terminé, démarrons le serveur tomcat avec <Tomcat-installation-indirectory>\bin\startup.bat (sous Windows) ou <Tomcat-installation-indirectory>/bin/startup.sh (sous Linux/Solaris etc.) et enfin tapons http://localhost:8080/HelloWorld dans le champ d’adresse du navigateur.

Source : Servlets - Examples

2.2. Java Server Pages JSP

Le JavaServer Pages ou JSP est une technique basée sur Java qui permet aux développeurs de créer dynamiquement du code HTML, XML ou tout autre type de page web. Cette technique permet au code Java et à certaines actions prédéfinies d’être ajoutés dans un contenu statique. Depuis la version 2.0 des spécifications, la syntaxe JSP est complètement conforme au standard XML.

La syntaxe du JSP ajoute des balises XML, appelées actions JSP, qui peuvent être utilisées pour appeler des fonctions. De plus, cette technique permet la création de bibliothèques de balises JSP (taglib) qui agissent comme des extensions au HTML ou au XML. Les bibliothèques de balises offrent une méthode indépendante de la plate-forme pour étendre les fonctionnalités d’un serveur HTTP. Il existe aussi un langage de script particulier, appelé Expression Language (EL) destiné à réduire l’injection de code java au sein des pages JSP ainsi qu’à étendre les possibilités des taglibs, tel que la JSTL.

Les JSP sont compilées par un compilateur JSP pour devenir des servlets Java. Un compilateur JSP peut créer une servlet Java en code source Java qui peut à son tour être compilé par le compilateur Java, ou peut créer le pseudo-code Java interprétable directement. Dans les deux cas, il est bon de comprendre comment le compilateur JSP transforme la page en servlet Java.

The JSP Model 2 architecture

Exemple de page JSP

Voici un exemple de code source JSP, suivi du code source de la Servlet Java qui pourrait être créée par un serveur (par exemple Apache Tomcat) et de la page HTML qui en résulterait. Le code Java et HTML de cette page est celui créé par Apache Tomcat 4.

Source
<%-- Ceci est un commentaire JSP --%>
<%@page contentType="text/html"%>
<%@page errorPage="erreur.jsp"%>
<%-- Importation d'un paquetage (package) --%>
<%@page import="java.util.*"%>
<html>
 <head><title>Page JSP</title></head>
 <body>
  <%-- Déclaration d'une variable globale à la classe --%>
  <%! int nombreVisites = 0; %>
  <%-- Définition de code Java --%>
  <% //Il est possible d'écrire du code Java ici
    Date date = new Date();
    // On peut incrémenter une variable globale pour compter le nombre
    // d'affichages, par exemple.
    nombreVisites++;
  %>
  <h1>Exemple de page JSP</h1>
  <%-- Impression de variables --%>
  <p>Au moment de l'exécution de ce script, nous sommes le <%= date %>.</p>
  <p>Cette page a été affichée <%= nombreVisites %> fois !</p>
 </body>
</html>
Servlet Java créée par le compilateur
package org.apache.jsp;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import org.apache.jasper.runtime.*;
import java.util.*;

public class example_jsp extends HttpJspBase {

 int nombreVisites = 0;
  private static java.util.Vector _jspx_includes;

  public java.util.List getIncludes() {
    return _jspx_includes;
  }

  public void _jspService(HttpServletRequest request, HttpServletResponse response)
        throws java.io.IOException, ServletException {

    JspFactory _jspxFactory = null;
    javax.servlet.jsp.PageContext pageContext = null;
    HttpSession session = null;
    ServletContext application = null;
    ServletConfig config = null;
    JspWriter out = null;
    Object page = this;
    JspWriter _jspx_out = null;

    try {
      _jspxFactory = JspFactory.getDefaultFactory();
      response.setContentType("text/html;charset=ISO-8859-1");
      pageContext = _jspxFactory.getPageContext(this, request, response,
      			"erreur.jsp", true, 8192, true);
      application = pageContext.getServletContext();
      config = pageContext.getServletConfig();
      session = pageContext.getSession();
      out = pageContext.getOut();
      _jspx_out = out;


      out.write("<body>\n\n");
      out.write("\n");
      out.write("\n\n");
      out.write("\n");
 //Il est possible d'écrire du code Java ici
    Date date = new Date();
    // On peut incrémenter une variable globale pour compter le nombre
    // d'affichages, par exemple.
    nombreVisites++;
      out.write("\n");
      out.write("<h1>Exemple de page JSP");
      out.write("</h1>\n");
      out.write("\n");
      out.write("<p>Au moment de l'exécution de ce script, nous sommes le ");
      out.print( date );
      out.write(".");
      out.write("</p>\n");
      out.write("<p>Cette page a été affichée ");
      out.print( nombreVisites );
      out.write(" fois !");
      out.write("</p>\n");
      out.write("</body>\n");
      out.write("</html>\n");
    } catch (Throwable t) {
      out = _jspx_out;
      if (out != null && out.getBufferSize() != 0)
        out.clearBuffer();
      if (pageContext != null) pageContext.handlePageException(t);
    } finally {
      if (_jspxFactory != null) _jspxFactory.releasePageContext(pageContext);
    }
  }
}
Code HTML créé par le serveur
<html>
<head><title>Page JSP</title></head>
<body>

<h1>Exemple de page JSP</h1>

<p>Au moment de l'exécution de ce script, nous sommes le Sat Mar 26 19:31:28 EST 2016.</p>
<p>Cette page a été affichée 5 fois !</p>
</body>
</html>

Source : JavaServer Pages

2.3. Entreprise Java Beans EJB

Enterprise JavaBeans (EJB) est une architecture de composants logiciels côté serveur pour la plateforme de développement Java EE.

Cette architecture propose un cadre pour créer des composants distribués (c’est-à-dire déployés sur des serveurs distants) écrit en langage de programmation Java hébergés au sein d’un serveur applicatif permettant de représenter des données (EJB dit entité), de proposer des services avec ou sans conservation d’état entre les appels (EJB dit session), ou encore d’accomplir des tâches de manière asynchrone (EJB dit message). Tous les EJB peuvent évoluer dans un contexte transactionnel.

De la version 1.0 à la version 2.1, un EJB était accompagné d’un ou plusieurs fichiers de déploiement écrits en XML qui permettait au serveur applicatif de déployer correctement l’objet au sein d’un conteneur. C’était notamment dans ces fichiers de déploiement que le développeur avait la possibilité de préciser le cadre transactionnel dans lequel l’objet allait s’exécuter. Depuis la version 3.0, le modèle EJB utilise le principe d’annotation java (meta-données) pour spécifier toute la configuration et les propriétés transactionnelles de l’objet. Le fichier de code source de l’EJB se suffit à lui-même.

C’est le serveur applicatif qui est chargé de la création, la destruction, la passivation ou l’activation de ses composants en fonction des besoins. Le client via un appel RMI (ou une de ses dérivées) va rechercher un EJB par son nom logique JNDI et appeler une ou plusieurs méthodes de cet objet.

Architecture EJB

… à compléter …

Les EJB session (Session Bean)

Les EJB sessions sont des objets proposant des services à leur appelant. Ils proposent un certain nombre de méthodes écrites par le développeur. Il y a deux types d’EJB session : les EJB sessions ne conservant pas leur état entre deux appels (EJB dit « stateless »), et ceux le conservant (EJB dit « stateful »). Il n’y a aucune garantie qu’entre deux appels au même EJB l’instance de l’objet soit la même.

Les EJB entité

Les EJB entité sont des beans ayant majoritairement pour vocation d’être persistants, c’est-à-dire pouvant être stockés sur un support physique entre deux sessions. Les EJB entité peuvent être de deux sortes : BMP (Bean Managed Persistence) ou CMP (Container Managed Persistence) (voir Java Persistence API).

Les EJB BMP sont des beans dont la persistance a dû être programmée par le développeur (ce dernier doit respecter un format pour la classe et les méthodes à implémenter sont imposées par la norme).

Les EJB CMP sont eux des beans dont la persistance est directement assurée par le conteneur d’EJB ; le mapping entre l’objet et son support de persistance est indiqué au conteneur via les fichiers descripteurs de déploiement. Le développeur, une fois le fichier de déploiement réalisé, n’a pas besoin d’écrire le code de persistance.

Depuis la version 3.0 de la spécification EJB, la notion de bean BMP/CMP n’existe plus : les EJB entité sont directement liés à la base de données via un mapping objet-relationnel. Ce mapping est défini soit dans un fichier de configuration XML, ou directement dans le code Java en utilisant des annotations.

Cette nouvelle interface de programmation des EJB entité est appelée Java Persistance API.

Les EJB message

Depuis la norme EJB 2.0 (2015) , cette architecture propose un troisième type de composant : les EJB message permettant de déclencher un processus côté serveur applicatif lors de la publication d’un message asynchrone. Pour ces composants, le client ne s’adresse pas directement aux composants mais publie un message sur un réceptacle JMS (queue ou topic) configuré sur le serveur applicatif qui va alors déclencher l’activation par ce serveur d’une instance de l’EJB concerné pour pouvoir traiter ce message.

Source : Enterprise JavaBeans

2.4. Service JDBC

JDBC (Java Database Connectivity) est une interface de programmation créée par Sun Microsystems (Oracle) pour les programmes utilisant la plateforme Java. Elle permet aux applications Java d’accéder par le biais d’une interface commune à des sources de données pour lesquelles il existe des pilotes JDBC. Normalement, il s’agit d’une base de données relationnelle, et des pilotes JDBC sont disponibles pour tous les systèmes connus de bases de données relationnelles.

API JDBC

2.5. Service JNDI

JNDI est une API Java de connexion à des annuaires, notamment des annuaires LDAP. JNDI signifie Java Naming and Directory Interface, cette API permet :

  • d’accéder à différents services de nommage ou de répertoire de façon uniforme ;
  • d’organiser et rechercher des informations ou des objets par nommage (java naming and directory interface) ;
  • de faire des opérations sur des annuaires (java naming and directory interface) tels que :
    • LDAP : un annuaire léger
    • X500 : normes d’annuaires lourdes à mettre en œuvre
    • NIS : annuaire obsolète

JNDI est très utilisée dans l’univers des serveurs d’applications Java et fait partie de l’ensemble des APIs Java EE où il permet de lier un nom (par exemple ‘base/sql/login’) à une information.

JNDI utilise principalement les packages :

  • javax.naming.*
  • javax.naming.directory.*

Un service de nommage permet d’associer un nom à un objet. Cette association est nommée binding. Un ensemble d’associations nom/objet est nommé un contexte.

Ce contexte est utilisé lors de l’accès à un élément contenu dans le service.

Il existe deux types de contexte :

  • Contexte racine
  • Sous contexte

Un sous-contexte est un contexte relatif à un contexte racine.

Par exemple, c:\ est un contexte racine dans un système de fichiers de type Windows. Le répertoire windows est un sous contexte du contexte racine (C:\windows) qui est dans ce cas nommé sous répertoire.

Dans DNS, com est un contexte racine et test est un sous contexte (test.com).

Source : Java Naming and Directory Interface

2.6. Service JMS

L’interface de programmation Java Message Service (JMS) permet d’envoyer et de recevoir des messages de manière asynchrone entre applications ou composants Java. JMS permet d’implémenter une architecture de type MOM (message oriented middleware). Un client peut également recevoir des messages de façon synchrone dans le mode de communication point à point.

L’API JMS permet aux applications Java de s’interfacer avec des intergiciels (middleware) à messages ou MOM. Les MOM permettent des interactions entre composants applicatifs dans un cadre faiblement couplé, asynchrone et fiable.

Modèles de publication

JMS permet l’échange de messages entre deux systèmes ou plus. Ce service supporte le modèle publication-abonnement (publish-subscribe) et le modèle point à point.

Dans le modèle publication-abonnement, des entités s’inscrivent sur un topic pour recevoir des messages. En effet, il ne s’agit plus d’envoyer des messages sur une file (queue) mais sur un topic. Celui qui publie les messages et ceux qui les reçoivent ne se connaissent pas.

Pour le modèle point à point, le producteur publie les messages dans une file (queue) et le consommateur lit les messages de la file. Dans ce cas le producteur connaît la destination des messages et poste les messages directement dans la file du consommateur. Pour utiliser ce modèle, le consommateur doit invoquer la méthode receive() qui est bloquante.

Fournisseurs de service JMS Open Source

  • Apache ActiveMQ (en)
  • OpenJMS
  • JBoss Messaging et HornetQ de JBoss
  • JORAM, de ObjectWeb maintenant OW2
  • Open Message Queue, de Sun Microsystems

Fournisseurs de service JMS propriétaires

  • Oracle WebLogic Server
  • Oracle AQ
  • SAP NetWeaver
  • SonicMQ
  • Tibco Software
  • webMethods Broker Server
  • webMethods Universal Messaging
  • WebSphere MQ
  • FioranoMQ de Fiorano

Tous les serveurs d’applications Java EE à partir de la version 1.4 doivent fournir un service JMS, ce service doit être accessible au travers de JCA (Java connector architecture).

Source : Java Message Service

2.7. Service JavaMail

JavaMail est l’API standard de gestion des courriers électroniques de Java EE.

2.8. Service JTA

Java Transaction (JTA) est une API présente dans la spécification Java EE.

JTA fournit des interfaces Java standards entre un gestionnaire de transaction et les différentes parties impliquées dans un système de transactions distribuées : le gestionnaire de ressources, le serveur d’application et les applications transactionnelles.

JTA est un protocole de commit à deux phases :

  • 1re phase : Chaque partie prenant part à la transaction distribuée s’engage à verrouiller les données concernées et à valider ces données une fois la transaction terminée
  • 2e phase : Chaque partie valide les changements des données. Cette phase est obligatoire, dès lors que les parties se sont engagées.

Ce protocole de commit à deux phases fonctionne plutôt bien sur les transactions courtes, mais est totalement inefficace en cas de transaction lente où le risque d’une déconnexion ou bien d’un crash entre les deux phases est élevé, car les verrous restent posés après la première phase et ne sont libérés qu’après la deuxième phase.

La spécification JTA a été développée par le Java Community Process sous la JSR 907.

Source : Java Transaction API

2.9. Service Java RMI

Remote method invocation, plus connu sous l’acronyme RMI est une interface de programmation (API) pour le langage Java qui permet d’appeler des méthodes distantes, sur le principe des ORB. L’utilisation de cette API nécessite l’emploi d’un registre RMI sur la machine distante hébergeant ces objets que l’on désire appeler au niveau duquel ils ont été enregistrés. Cette interface de programmation est très souvent utilisée en parallèle avec l’API d’annuaire JNDI ou encore avec la spécification de composants distribués transactionnels EJB du langage Java.

Cette bibliothèque, qui se trouve en standard dans Java SE, permet la communication via le protocole HTTP (ou IIOP, depuis la version 1.3 du JDK) entre des objets Java éloignés physiquement les uns des autres, autrement dit s’exécutant sur des machines virtuelles java distinctes. RMI facilite le développement des applications distribuées en masquant au développeur la communication client / serveur.

Cette bibliothèque entre en concurrence avec la norme CORBA maintenue par l’Object Management Group, et les produits qui la respectent, ou avec la technologie RPC dont l’un des acteurs est Microsoft.

Source : Remote method invocation

2.10. Service JCA

Les applications Java EE sont constituées de :

  • modules web ;
  • modules EJB ;
  • modules client d’application d’entreprise

Les systèmes d’informations d’entreprise (EIS) sont constitués de :

  • ERP ;
  • mainframes ;
  • SGBD ;
  • applications anciennes écrites en C, C++, COBOL, …

JCA est la solution de Java EE pour résoudre le problème d’intégration entre le monde Java EE et le système d’information d’entreprise (EIS).

Pour mettre en œuvre une telle intégration JCA propose une architecture basée sur les éléments suivants :

  • un Resource Adapter ;
  • des contrats applicatifs entre les modules Java EE et le Resource Adapter ;
  • des contrats système entre les serveurs d’applications Java EE (AS) et le Resource Adapter.

Un Resource Adapter est un pilote entre le serveur d’applications et le système d’information d’entreprise. Il est composé de :

  • jars permettant d’emmailloter l’accès aux ressources du système d’information ;
  • bibliothèques natives (.dll, .so) fournissant l’accès aux ressources du système d’information ;
  • un descripteur de déploiement ra.xml.

Les contrats systèmes définissent :

  • la connectivité du serveur d’applications vers l’EIS (dans la version 1.0 de JCA ) ;
  • la connectivité de l’EIS vers le serveur d’applications (dans la version 1.5 de JCA) ;
  • la gestion du cycle de vie du Resource Adapter (dans la version 1.5 de JCA) ;
  • la gestion des threads (dans la version 1.5 de JCA).

Parmi ces contrats on distingue donc :

  • contrat de gestion de connexions : définit comment obtenir une connexion à l’EIS depuis l’AS, le pooling des connexions est transparent pour l’application ;
  • contrat de gestion de transactions : permet à l’AS d’utiliser un gestionnaire de transactions supportant l’accès à divers gestionnaires de ressources de l’IES. Les invocations de services au sein de l’EIS sont enveloppées dans des transactions distribuées (XA Transaction définie par l’Open Group). Les transactions XA sont globales et peuvent contenir des appels à divers types de ressources de l’EIS ;
  • contrat de gestion de la sécurité : fournit des mécanismes permettant de gérer l’authentification, l’autorisation, les communications sécurisées entre le serveur Java EE et les ressources protégées de l’EIS ;
  • contrat de gestion de transactions inflow : permet de propager une transaction démarrée dans l’EIS vers le serveur d’application ;
  • contrat de gestion de messagerie inflow : permet à l’EIS de délivrer des messages à des composants du serveur d’application ;
  • contrat de gestion du cycle de vie : permet l’arrêt et le démarrage du Resource Adapter ;
  • contrat de gestion des threads : permet à l’EIS de soumettre des tâches à l’AS. Ainsi le Resource Adapter s’exonère de la gestion directe des threads.

Les contrats applicatifs sont définis par le Common Client Interface (CCI). Cette interface permet à des composants applicatifs Java EE, à des frameworks d’intégration d’applications d’entreprises de piloter les interactions entre des ressources hétérogènes de l’EIS via l’utilisation d’une API commune.

Architecture JCA

Source : Java connector architecture

2.11. Services XML

XML n’est pas une API de service Java EE mais on l’utilise pour décrire des fichiers de configuration et de plus en plus pour un nouveau modèle de communication entre les applications (différentes) : les Web Services.

Différentes API Java EE supportent XML.

3. Les applications Java EE

La plate-forme Java EE en plus de fournir un modèle de composants décrit l’assemblage de ces composants pour être installés sur un serveur Java EE.

  • Phase 1 : Développement des composants de l’application.
  • Phase 2 : Assemblage des composants en modules Web (Servlets et JSP), en modules EJB (contenant des EJBs) avec des fichiers de configuration.
  • Phase 3 : Assemblage des modules en applications dans une seule archive.
  • Phase 4 : Déploiement de l’application sur un serveur d’application.

3.1. Modèle MVC

Modèle-vue-contrôleur ou MVC est un motif d’architecture logicielle destiné aux interfaces graphiques lancé en 1978 et très populaire pour les applications web. Le motif est composé de trois types de modules ayant trois responsabilités différentes : les modèles, les vues et les contrôleurs.

Modèle MVC

Appliqué à Java EE, on retrouve les composants :

  • Un modèle (Model) contient les données à afficher : composants EJB.
  • Une vue (View) contient la présentation de l’interface graphique : JSP.
  • Un contrôleur (Controller) contient la logique concernant les actions effectuées par l’utilisateur: Servlets.

3.2. Modules Web Java EE

Dans l’architecture Java EE, les composants Web et les fichiers statiques de contenu Web tels que les images sont appelés ressources Web. Un module Web est la plus petite unité de ressources Web déployable et utilisable. Un module Web Java EE correspond à une application Web telle que définie dans la spécification Java Servlet.

En plus des composants Web et des ressources Web, un module Web peut contenir d’autres fichiers :

  • Des classes “Server-side” (database beans, shopping carts, etc). Souvent ces classes sont conformes à des composants d’architecture JavaBeans.
  • Des classes “Client-side” (applets et utility classes).

Structure d’un module Web

Un module Web a une structure spécifique. Le répertoire de niveau supérieur d’un module Web est la racine du document de l’application. La racine du document est l’endroit où sont stockées les pages JSP, les classes et les archives côté client, ainsi que les ressources Web statiques, comme les images.

La racine du document contient un sous-répertoire nommé WEB-INF qui contient les fichiers et répertoires suivants :

  • web.xml : Le descripteur de déploiement de l’application web
  • Fichiers Tag library descriptor
  • classes : Un répertoire qui contient les classes côté serveur : servlets, classes utilitaires et composants JavaBeans.
  • tags : Un répertoire qui contient des fichiers de balises, qui sont des implémentations de bibliothèques de balises
  • lib : Un répertoire qui contient les archives JAR des bibliothèques appelées par les classes côté serveur

Si votre module Web ne contient aucun servlet, filtre ou composant Listener, il n’a pas besoin d’un descripteur de déploiement d’application Web. En d’autres termes, si votre module Web ne contient que des pages JSP et des fichiers statiques, vous n’êtes pas obligé d’inclure un fichier web.xml.

Vous pouvez également créer des sous-répertoires spécifiques à l’application (c’est-à-dire des répertoires de paquetages) dans la racine du document ou dans le répertoire WEB-INF/classes/.

Un module Web peut être déployé sous la forme d’une structure de fichier décompactée ou peut être empaqueté dans un fichier JAR appelé fichier d’archives Web (WAR). Parce que le contenu et l’utilisation des fichiers WAR diffèrent de ceux des fichiers JAR, les noms de fichiers WAR utilisent une extension “.war”.

Pour déployer un WAR sur le serveur d’application, le fichier doit également contenir un descripteur de déploiement d’exécution. Le descripteur de déploiement d’exécution est un fichier XML qui contient des informations telles que la racine du contexte de l’application Web et le mappage des noms portables des ressources d’une application avec les ressources du serveur d’application. Le runtime du descripteur du serveur d’application Web s’appelle dans cet exemple sun-web.xml et se trouve dans le répertoire WEB-INF avec l’application Web.

Web Module Structure

Source : The Java EE 5 Tutorial, Web Modules

3.3. Modules EJB Java EE

Les Enterprise beans sont des composants Java EE qui implémentent la technologie Enterprise JavaBeans (EJB). Enterprise beans s’exécute dans un conteneur EJB, soit un environnement d’exécution dans un serveur d’application.

Pour développer un entreprise bean, vous devez fournir les fichiers suivants :

  • Classe Enterprise Bean : Implémente les méthodes définies dans l’interface métier et toutes les méthodes de rappel du cycle de vie.
  • Business Interfaces : L’interface métier définit les méthodes mises en œuvre par la classe de haricots d’entreprise.
  • Helper classes : Autres classes nécessaires à la classe bean entreprise, telles que les classes d’exception et utility.

Vous empaquetez les fichiers de la liste précédente dans un fichier EJB JAR, le module qui stocke le entreprise bean. Un fichier JAR EJB est portable et peut être utilisé pour différentes applications. Pour assembler une application Java EE, vous empaquetez un ou plusieurs modules (tels que les fichiers EJB JAR) dans un fichier EAR, le fichier archive qui contient l’application. Lorsque vous déployez le fichier EAR qui contient le fichier EJB JAR du bean, vous déployez également le bean sur le serveur d’application. Vous pouvez également déployer un JAR EJB qui n’est pas contenu dans un fichier EAR.

Structure of an Enterprise Bean JAR

Source : The Java EE 5 Tutorial, The Contents of an Enterprise Bean

4. Serveurs d’application Java EE

Un serveur d’application Java EE fournit l’environnement d’exécution des applications Java.

4.1. Rôles d’un serveur d’application Java EE

Un serveur d’application Java EE met en oeuvre des applications distribuées. Ces applications sont constituées de composants Java tels que des Servlet, des JSP et des EJB. Un autre but d’un serveur d’application Java EE est de rendre l’application accessible à travers à des clients Web (navigateur ou lourd). Le serveur d’application prend en charge l’interaction avec le client de manière fiable, sécurisée et robuste.

Il fournit des services tels que :

  • Service HTTP
  • Service de nommage
  • Service de transaction
  • Service de gestion de la disponibilité des applications
  • Service de sécurité (JAAS)
  • Service d’administration
  • Service d’accès aux données (JDBC et JCA)
  • Service de gestion de messages (JMS)

4.2. Architecture d’un serveur d’application Java EE

Un serveur d’application Java EE est constitué de différents environnements d’exécution propre à chaque composant Java EE de l’application. C’est ce qu’on appelle des conteneurs d’application Java EE. Un conteneur Java EE utilise une JVM.

Java EE Server and Containers

  • Serveur Java EE : La partie runtime d’un produit Java EE. Un serveur Java EE fournit des EJB et des conteneurs web.
  • Enterprise JavaBeans (EJB) : Gère l’exécution des Beans d’entreprise pour les applications Java EE. Les Beans d’entreprise et leur conteneur fonctionnent sur le serveur Java EE.
  • Web container : Gère l’exécution des composants des pages JSP et des servlets pour les applications Java EE. Les composants Web et leur conteneur fonctionnent sur le serveur Java EE.
  • Application client container : Gère l’exécution des composants client de l’application. Les clients d’application et leur conteneur s’exécutent sur le client.
  • Applet container : Gère l’exécution des applets. Se compose d’un navigateur Web et d’un plug-in Java s’exécutant sur le client ensemble.

Source : The Java EE 5 Tutorial, Java EE Containers

4.3. Marché des serveurs d’application Java EE

WEBSPHERE VS JBOSS VS WEBLOGIC VS TOMCAT

Source : WEBSPHERE VS JBOSS VS WEBLOGIC VS TOMCAT

4.4. Serveurs d’application Java EE en implémentation complète

Which Java application server is the most widely used in 2017?

Source de l’image : Most popular Java application servers: 2017 edition

Tous services conformes à une version Java EE.

  • Oracle GlassFish Server Open Source Edition
  • TmaxSoft TMAX JEUS
  • RedHat Wildfly
  • JBoss EAP
  • Oracle GlassFish Enterprise Server
  • Oracle WebLogic Server
  • Apache Geronimo
  • IBM WebSphere Application Server
  • IBM WebSphere Application Server Community Edition
  • Apache Geronimo

4.5. Apache Tomcat

Logo Apache Tomcat

Apache Tomcat est un conteneur web libre de servlets et JSP Java EE. Issu du projet Jakarta, c’est un des nombreux projets de l’Apache Software Foundation. Il implémente les spécifications des servlets et des JSP du Java Community Process, est paramétrable par des fichiers XML et des propriétés, et inclut des outils pour la configuration et la gestion. Il comporte également un serveur HTTP.

Bien qu’étant une implémentation de JEE moins complète que la plupart de ses concurrents, et même grâce à cette légèreté, Tomcat domine rapidement le marché des serveurs Java. Il représentait en 2014 la moitié des utilisations de tels serveurs, loin devant JBoss et Jetty. En 2016, son utilisation baisse à 42%.

Source : Apache Tomcat

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

À une époque, il aurait été facile de décrire la différence entre Websphere et Tomcat en disant que Websphere était un serveur d’application, alors que Tomcat était juste un conteneur de servlet. Prenons un moment pour définir ces termes d’un point de vue technique rigide avant d’examiner comment leurs définitions évoluent.

4.7. Qu’est-ce qu’un serveur d’application Java EE ?

Du point de vue technique Java, un serveur d’application Java est une implémentation de la spécification Java EE Application Server qui est entièrement conforme et prend en charge toutes les fonctionnalités Java EE. Ces fonctionnalités étendent la plate-forme Java standard pour une utilisation dans les transactions commerciales basées sur Internet et incluent des éléments tels que JTA, EJB, JMS, JSF et API Java EE pour la persistance de session, l’injection de dépendances, et plus encore.

Les serveurs Java EE déploient des applications au format EAR (Enterprise Archive), qui contiennent un ou plusieurs fichiers WAR, des EJBs associés, des pages JSP, des servlets et même des adaptateurs de ressources. Ce paquet est déployé dans un conteneur unique, de sorte que ses classes et ressources peuvent être chargées et gérées séparément.

De plus, la plupart des serveurs d’applications commerciaux (y compris Websphere et ses concurrents directs, tels que Weblogic) comprennent des outils de gestion et de surveillance complets, ainsi qu’une gamme de produits supplémentaires qui s’intègrent à eux et offrent des fonctionnalités supplémentaires moyennant des frais.

4.8. Qu’est-ce qu’un conteneur de servlets ?

En revanche, un conteneur de servlets n’a besoin que d’implémenter les spécifications Java Servlet et JSP, qui traitent du déploiement d’applications Web gérées par conteneurs, ainsi que des transactions associées.

La spécification de servlet, qui fait partie de la plate-forme Java EE, inclut l’utilisation de fichiers d’application WAR, de pages JSP, de connecteurs, de ressources JNDI, et plus encore, ce qui signifie qu’un conteneur de servlet peut faire beaucoup de choses identiques à un serveur web.

En fait, la spécification des servlets couvre tellement de technologies web importantes que les versions embarquées de Tomcat sont utilisées comme conteneur web et de servlets pour de nombreux serveurs d’applications commerciaux.

5. Frameworks de développement Web Java

Un framework web (WF) ou framework d’application web (WAF) est un cadre logiciel conçu pour soutenir le développement d’applications web incluant les services web, les ressources web et les API web. Les frameworks Web fournissent un moyen standard de créer et de déployer des applications Web sur le World Wide Web. Les frameworks Web visent à automatiser les frais généraux associés aux activités courantes exécutées dans le développement Web. Par exemple, de nombreux frameworks web fournissent des bibliothèques pour l’accès aux bases de données, les frameworks de modèles et la gestion des sessions, et ils favorisent souvent la réutilisation du code Bien qu’ils ciblent souvent le développement de sites web dynamiques, ils sont également applicables aux sites web statiques.

Source : Web framework

5.1. Liste des frameworks de développement Web Java

ProjectCurrent stable versionRelease dateLicense
Apache Click2.3.02011-03-27Apache 2.0
Apache OFBiz13.07.032016-04-04Apache 2.0
Apache Shale1.0.42007-12-19Apache
Apache Sling82015-10-16Apache 2.0
Apache Struts 22.5.202019-01-09Apache 2.0
Apache Tapestry5.4.32017-04-24Apache 2.0
Apache Wicket7.9.02017-09-19Apache 2.0
AppFuse3.5.02015-02-20Apache 2.0
Brutos Framework2.0-rc32018-08-14Apache 2.0
Eclipse RAP3.1 M42015-12-22Eclipse
FormEngine2.0.12012-05-08Proprietary
Grails3.3.92018-12-04Apache
Google Web Toolkit2.8.22017-10-19Apache 2.0
Hamlets1.7.12012-06-29BSD
ItsNat1.42015-09-18GNU LGPL, proprietary
JavaServer Faces (Mojarra)2.2.82016-05-30CDDL, GNU GPL 2, Apache 2.0
JBoss Seam3.1.0 final2012-01-13GNU LGPL
Jspx-bay2.12015-12-23Apache 2.0
JVx2.42015-12-23Apache 2.0
JWt3.3.102018-04-12GPL, Proprietary
Netty (software)4.1.312018-10-30Apache License 2.0
OpenLaszlo4.9.02010-10-21CPL
OpenXava5.52016-04-27GNU LGPL
Oracle ADF2.1.3.02014-06-26Oracle Technology Network Developer License
Play2.6.62017-10-05Apache 2.0
RIFE1.6.12007-07-14CDDL, GNU LGPL
Spark2.52016-05-03Apache
Spring5.0.42018-02-19Apache 2.0
Stripes1.6.02015-07-23Apache
Vaadin8.4.02018-04-26Apache 2.0
VRaptor4.2.0.Final2017-09-19Apache 2.0
Wavemaker8.22016-06-07Apache
WebObjects5.4.32008-09-15Proprietary
WebWork2.2.62007-07-21Apache
ztemplates2.4.02011-09-11Apache

Source : Comparison of web frameworks