La plateforme Java EE

Plan du cours
Problématique - Pourquoi une nouvelle norme J2EE ?
• Limitations des technologies existantes sur le marché :
 C/C++, .net, php, VB
 Uniformisation des langages de développement de bout en bout pour couvrir
l’ensemble des exigences (métier, techniques, sécurité …)
• Périmètre plus globale :
 Périmètre incluant les parties Client et Serveur
 Au delà d’un langage de programmation, c’est toute une architecture
• Besoins évolutifs :
 Un client finale de plus en plus exigent
 Time To Market (TTM)
 Norme évolutive
• Contraintes plus exigeantes:
 Haute disponibilité
 Résilience des solutions
 La présentation de J2EE (1/3)
• J2EE est une plate-forme fortement orientée serveur pour le développement et
l'exécution d'applications distribuées. Elle est composée de deux parties
essentielles :

➢ un ensemble de spécifications pour une infrastructure dans laquelle

s'exécutent les composants écrits en Java : un tel environnement se nomme
serveur d'applications.

➢ un ensemble d'API qui peuvent être obtenues et utilisées séparément. Pour

être utilisées, certaines nécessitent une implémentation de la part d'un
fournisseur tiers.

▪ Une API signifie Application Programming Interface. C’est un ensemble normalisé de classes, de
méthodes, de fonctions qui sert de façade par laquelle on offre des fonctionnalités prête à l’emploi sans
devoir les développer à nouveau et se concentrer ainsi sur les développements métiers à forte valeur
ajoutée.
▪ Exemple : JDBC est une API java d’accès aux données d’une base de données relationnelles.
La présentation de J2EE (3/3)
J2EE permet une grande flexibilité dans le choix de l'architecture de l'application en
combinant les différents composants. Ce choix dépend des besoins auxquels doit répondre
l'application mais aussi des compétences dans les différentes API de J2EE. L'architecture d'une
application se découpe idéalement en au moins trois tiers :
➢ la partie cliente (couche Présentation) : c'est la partie qui permet le dialogue avec
l'utilisateur. Elle peut être composée d'une application standalone, d'une application web
ou d'applets.
➢ la partie métier (couche Métier ou Service) : c'est la partie qui encapsule les
traitements (dans des EJB ou des JavaBeans)
➢ la partie données (couche DAO) : c'est la partie qui stocke les données
Les API de J2EE
Les API de J2EE
Les API de J2EE

Exemple : fichier XML

Les API de J2EE

Exemple : Java Transaction API (JTA)

Exemple : fichiers XML, géré par JAXB/JAXP

Les API de J2EE
version de l'API dans
API
1.2 1.3 1.4 5 6 7
Entreprise Java Bean (EJB) 1.1 2.0 2.1 3.0 3.1 3.2
Remote Method Invocation (RMI) et RMI-IIOP 1.0
Java Naming and Directory Interface (JNDI) 1.2 1.2 1.2.1
Java Database Connectivity (JDBC) 2.0 2.0 3.0
Java Transaction API (JTA) 1.0 1.0 1.0 1.1 1.1 1.2
Java Transaction Service (JTS)
Java Messaging service (JMS) 1.0 1.0 1.1 1.1 1.1 2.0
Servlets 2.2 2.3 2.4 2.5 3.0 3.1
Java Server Pages (JSP) 1.1 1.2 2.0 2.1 2.2 2.2
Java Server Faces (JSF) 1.2 2.0 2.2
Expression Language (EL) 2.2 3.0

Java Server Pages Standard Tag Libray (JSTL) 1.2 1.2 1.2

version de l'API dans

API
1.2 1.3 1.4 5 6 7
JavaMail 1.1 1.2 1.3 1.4 1.4 1.4
J2EE Connector Architecture (JCA) 1.0 1.5 1.5 1.6 1.6
Java API for XML Parsing (JAXP) 1.1 1.2
Java Authentication and Authorization Service
1.0
(JAAS)
JavaBeans Activation Framework 1.0.2 1.0.2
Java API for XML-based RPC (JAXP-RPC) 1.1 1.1 1.1 1.1
SOAP with Attachments API for Java (SAAJ) 1.2 1.3
Java API for XML Registries (JAXR) 1.0 1.0 1.0 1.0
Java Management Extensions (JMX) 1.2
Java Authorization Service Provider Contract
1.0 1.1 1.4 1.4
for Containers (JACC)
Java API for XML-Based Web Services (JAX-
2.0 2.2 2.2
WS)
Les API de J2EE
version de l'API dans
API
1.2 1.3 1.4 5 6 7
Java Architecture for XML Binding (JAXB) 2.0 2.2
Streaming API for XML (StAX) 1.0
Java Persistence API (JPA) 1.0 2.0 2.1

Java API for RESTful Web Services (JAX-RS) 1.1 2.0

Web Services 1.2 1.3 1.3

Web Services Metadata for the Java Platform 2.1 2.1
Java APIs for XML Messaging (JAXM) 1.3
Context and Dependency Injection (CDI) 1.0 1.1
Dependancy Injection (DI) 1.0
Bean Validation 1.0 1.1
Managed beans 1.0 1.0
version de l'API dans
API
1.2 1.3 1.4 5 6 7
Interceptors 1.1 1.1
Common Annotations 1.1 1.1
Java API for WebSocket 1.0
Java API for JSON 1.0
Concurrency Utilities for Java EE 1.0
Batch Applications for the Java Platform 1.0

▪ Ces API peuvent être regroupées en trois grandes catégories :

➢ les composants : Servlet, JSP, JSF, EJB
➢ les services : JDBC, JTA/JTS, JNDI, JCA, JAAS
➢ la communication : RMI-IIOP, JMS, Java Mail
 Diagramme des composants Java SE (Standard Edition)

NB : Java SE est différent de Java EE

 Java SE (Standard Edition) vs Java EE (Entreprise Edition)

• Différences clés entre Java standard Edition et Java Enterprise Edition

1. Java SE est le langage de programmation Java de base, cependant, la plate-forme Java

EE est construite sur la plate-forme SE.

2. SE définit tout, depuis les types de base et les objets du langage de programmation

Java, et il fournit toutes les fonctionnalités de base. La plate-forme Java EE fournit une API

et un environnement d'exécution pour développer et exécuter des applications à grande

échelle ( applications Web, distribuée, hautement disponible, tolérante aux pannes…)

3. La plate-forme Java SE se compose d'une machine virtuelle, d'outils de développement,

de technologies de déploiement et d'autres bibliothèques couramment utilisées en Java.

Java EE se compose des EJB,JSP, Servlets, JSF, JMS, JTA,JCA, JAX-WS …..
Zoom sur l’API « JCA » : JavaTM EE Connector Architecture

▪ Java EE Connector Architecture (JCA) définit une architecture standard pour l’accès aux
systèmes externes hétérogènes Enterprise Information Systems (EIS).
▪ Exemples de systèmes EISs : (ERP), transaction central de traitement (TP), bases de
données et systèmes de messagerie. On appelle ça Legacy Applications.

• JCA fournit des fonctionnalités de gestion :Connexions; transactions; Sécurité ; cycle de vie ;

▪ COMMON CLIENT INTERFACE (CCI) : L'interface client commune (CCI) JCA est un
ensemble d'interfaces fournissant un cadre pour l'interaction de base avec un adaptateur de
ressources. Un adaptateur prenant en charge CCI fournira des classes concrètes qui
implémentent ces interfaces. La conception et l'utilisation de CCI ressemblent beaucoup à
celles de JDBC.
Zoom sur l’API « JCA » : JavaTM EE Connector Architecture
Serveur
d’Application
J2EE

EIS : Systèmes externes hétérogènes : SAP, COBOL, C, C++

▪ Similitudes entre JCA et JDBC

Communication par message: Synchrone vs. Asynchrone
1. Synchrone / bloquante : L’émetteur reste bloqué jusqu’à ce que le destinataire acquitte la
réception du message (« Acknowledgement »)

2. Asynchrone / non-bloquante (Fire and Forget) :

▪ L’émetteur continue de s’exécuter après avoir soumis le message pour la transmission
Besoins d’un couplage faible
▪ Le développeur veut éviter qu’un composant
dépende de l’interface des autres composants
ou même de « connaître » les autres composants
(Références directes)
Zoom sur l’API « JMS » : architecture des échanges

▪ Basée sur deux types d’objets : Queue et Topic

▪ Le Messaging Server est un MOM : Message Oriented Middleware
▪ Plusieurs MOM ou JMS provider existent sur le marché : Active MQ, Rabbit MQ …
Zoom sur l’API « JMS » : mode (1) Point To Point message

▪ Les messages de type P2P sont destinés a un seul destinataire

▪ Dans ce mode on utilise l’objet Queue
▪ La file d'attente (Queue) est chargée de retenir le message jusqu'à ce que le destinataire soit prêt
▪ Pas de dépendance temporelle entre émetteur et destinataire du message
▪ Le destinataire peut acquitter les messages reçus
Zoom sur l’API « JMS » : mode (1) Point To Point message

Exemple : envoie d'un message dans une queue

Fichier de paramétrage « jndi.properties »

 Zoom sur l’API « JMS » : mode (2) Publish/Subscriber message

▪ Les messages de type P/S sont destinés a un plusieurs destinataires

▪ Dans ce mode on utilise l’objet Topic
▪ Dépendance temporelle : Un client ne peut lire un message qu’après s’être abonné à un topic
▪ Un client abonné à un topic doit continuer à être actif pour recevoir les message du topic.
Zoom sur l’API « JMS » : mode (2) Publish/Subscriber message
Grâce à la version 1.1 de JMS,
pour envoyer un message
dans le topic1, il suffit
simplement le remplacer le
nom JNDI de la destination

destination = (Destination)
context.lookup("topic1");

Exemple : envoie d'un message dans une Topic

Exemple : lecture d'un message dans une file d'attente

 Web Services SOAP/REST
▪ Un service web est un protocole d'interface de la famille des technologies web permettant la
communication et l'échange de données entre applications et systèmes hétérogènes dans des
environnements distribués.
▪ il s'agit donc d'un ensemble de fonctionnalités exposées sur internet ou sur un intranet, par et
pour des applications ou machines, sans intervention humaine, de manière synchrone ou
asynchrone.
▪ Le protocole de communication est défini dans le cadre de la norme SOAP avec la signature
du service exposé (WSDL).
▪ Le concept a été précisé et mis en œuvre dans le cadre de Web Services du consortium W3C,
particulièrement avec le protocole SOAP.
▪ Associé avec les échanges de données informatisés (EDI), il a été utilisé pour automatiser des
échanges de données entre entreprises.
▪ Cependant le concept s'enrichit avec l'approfondissement des notions de ressource et d'état,
dans le cadre du modèle REST.
 Web Services SOAP/REST
▪ Avantage des Web Services :
▪ Granularité variable : fonctions, composants, applications, processus métier,
▪ Interopérabilité des applications (intra- ou inter-entreprises) et dialogue à distance via
Internet,
▪ Indépendant des plates-formes et système d’exploitation,
▪ Indépendant du langage de programmation,
▪ Utilisant un système standard d’échange (XML ou JSON), ces messages sont
généralement transportés par des protocoles internet connus HTTP
▪ Pouvant communiquer avec d’autres WS.
▪ Deux principales technologies de Web Service:
1. SOAP: Simple Object Access Protocol (SOAP) est un protocole d’échange d’information
structurée dans l’implémentation de services web basé sur XML (big Service).
L’implémentation par défaut est Metro
2. RESTFul : REST (representational state transfer) est un style d’architecture logicielle
définissant un ensemble de contraintes à utiliser pour créer des services web (light Service).
 Web Service SOAP : Architecture des échanges

Requête SOAP

▪ <Header> : peut contenir des

informations concernant les
transactions, la sécurité, le routage,
etc ...
End Point Service : Implémentation

HTTP/HTTPS

Réponse SOAP
End Point Interface

SOAP Client SOAP Server

▪ La gestion d'erreurs optionnelle (Fault)

contenue dans le corps
▪ Les pièces jointes optionnelles
(attachment) contenues dans le corps
<Body> AttachmentPart
 Web Service SOAP : Architecture des échanges

Requête SOAP

HTTP/HTTPS

SOAP SOAP Server

SOAP Client

Réponse SOAP
 Web Service SOAP :WSDL
▪ Le WSDL (Web Services Description Language) est une grammaire XML permettant de
décrire un service web, et standardisé par W3C en 2007.
▪ Le WSDL décrit une interface publique d'accès à un service web, notamment dans le cadre
d'architectures de type SOA (Service Oriented Architecture). C'est une description fondée sur
le XML qui indique « comment communiquer pour utiliser le service ».
▪ Le WSDL sert à décrire :
▪ le protocole de communication (SOAP RPC ou SOAP orienté message)
▪ le format de messages requis pour communiquer avec ce service
▪ les méthodes que le client peut invoquer
▪ la localisation du service.
▪ Granularité variable : fonctions, composants,
▪ Interopérabilité des applications
(intra- ou inter-entreprises)
Web Service SOAP :WSDL
 Web Service SOAP :API JAX-WS

▪ JAX-WS (Java API for XML based Web Services) est une API qui propose un modèle de

programmation pour produire (côté serveur) ou consommer (côté client) des services web qui

communiquent par des messages XML de type SOAP.

▪ Elle a pour but de faciliter et simplifier le développement des services web notamment grâce à

l'utilisation des annotations.

▪ Le développement d'un service web en Java avec JAX-WS débute par la création d'une classe

annotée avec @WebService du package javax.jws. La classe ainsi annotée définit le Endpoint

du service web.

▪ Le service Endpoint interface (SEI) est une interface qui décrit les méthodes du service :

celles-ci correspondent aux opérations invocables par un client.

▪ JAX-WS contient l’implémentation par défaut est Metro

 Web Service SOAP :API JAX-WS
▪ Le développement d'un service web avec JAX-WS requiert plusieurs étapes :
1.coder la classe qui encapsule le service
2.compiler la classe
3.utiliser la commande wsgen pour générer les fichiers requis pour le déploiement
(schémas, WSDL, classes, ...)
4.packager le service dans un fichier.war
5.déployer le war dans un conteneur
▪ Pour définir un Endpoint avec JAX-WS, il a plusieurs conditions :
1.la classe qui encapsule le endpoint doit être public, non static,
non final, non abstract et être annotée avec @WebService
2.elle doit avoir un constructeur par défaut (sans paramètre)
3.les méthodes exposées par le service web doivent être public,
non static, non final et être annotées avec @WebMethod
 Web Service SOAP :API JAX-WS
▪ Exemple d’un Web Service qui échange des objets de type « Personne »
▪ Nom du WS : « Saluer »
▪ Nom du paramètre du WS : Objet « personne »
▪ Le résultat du WS est Bonjour Nom Prénom
 Web Service SOAP :API JAX-WS

▪ Le WSDL généré par wsgen pour le Web Service PersonneWS :

 Web Service SOAP :Framework AXIS

▪ Axis 2 (Apache eXtensible Interaction System) est un projet open-source du groupe Apache

diffusé sous la licence Apache 2.0 qui propose une implémentation d'un moteur de service web

implémentant le protocole SOAP : il permet de créer, déployer et consommer des WS.

▪ Son but est de proposer un ensemble d'outils pour faciliter le développement, le déploiement

et l'utilisation des services web écrits en java.

▪ Axis propose de simplifier au maximum les tâches pour la création et l'utilisation des services

web. Il permet notamment de générer automatiquement le fichier WSDL à partir d'une classe

Java et le code nécessaire à l'appel du service web.

▪ TCPMonitor : Cet outil agit comme un proxy qui permet de visualiser les requêtes et réponses

HTTP échangées entre un client et un serveur SOAP. Une sorte de sniffer !

▪ Le site officiel est à l'url https://axis.apache.org/axis2/java/core/index.html

 Web Service : API REST JAX-RS
▪ JAX-RS est l’API conçue pour implémenter des API Web Services RESTful.

▪ JAX-RS est donc une API de programmation pour implémenter rapidement des applications

basées sur HTTP.

▪ JAX-RS 2.x est défini par la JSR 339. Comme pour tous les services et toutes API Java EE, il

existe plusieurs implémentations de cette spécification : Jersey (l’implémentation de

référence), RestEasy (intégré dans le serveur Wildfly), Apache CXF.

▪ La notion de ressource : Dans le Web et selon le protocole HTTP , ce qui est désigné par une

URI (Uniform Resource Locator) est appelé une ressource.

▪ Une ressource offre une interface uniforme qui est définie dans HTTP par l’ensemble des

méthodes : GET, HEAD, POST, PUT, DELETE, OPTIONS…

▪ Un client HTTP positionne dans sa requête une méthode pour indiquer le type d’opération que

le serveur doit effectuer sur la ressource.

 Web Service : API REST JAX-RS / Rappel de HTTP

▪ Les méthodes HTTP usuellement utilisées :

▪ GET : Demande au serveur une représentation de la ressource cible.
▪ PUT : Crée ou met à jour l’état d’une ressource identifiée par l’URI.
▪ DELETE : Détruit l’association de l’URI avec l’état de la ressource.
▪ POST :
▪ Le client souhaite que le serveur effectue un traitement sur la ressource
▪ Le client souhaite modifier partiellement une ressource sur la ressource
▪ Les fonctionnalités de base de HTTP sont :
▪ HTTP fonctionne selon le mode non connecté (connectionless).
▪ HTTP est indépendant du support, ce qui signifie que tout type de données peut être
envoyé via http.
▪ HTTP est sans état (stateless), ni le serveur ni le client ne gardent une trace de la
dernière requête.
 Web Service : API REST JAX-RS / Rappel de HTTP
▪ L'en-tête (Header) HTTP contient les métadonnées et les informations sur la méthode HTTP,
tandis que le corps HTTP (Body) contient les données que vous voulez envoyer au serveur.
▪ Pour vérifier les requêtes HTTP lorsque vous naviguez sur Internet: Si vous utilisez le
navigateur Chrome, appuyez sur F12 sous Windows et Commande + Option + I sous Mac OS
pour ouvrir l'outil de développement. Sous l'onglet Réseau, vous pouvez voir la requête HTTP
effectuée et la réponse reçue avec les en-têtes.
 Web Service : API REST JAX-RS
▪ Configurer une application Web pour JAX-RS:
▪ Le conteneur web Tomcat ne fournit pas d’implémentation de JAX-RS par défaut. Pour un
projet géré avec Maven, il faut donc ajouter dans l’application les dépendances nécessaires.
▪ Dans notre cas, on va utiliser Jersey qui est l’implémentation de référence pour l’API JAX-RS.
▪ Dans le fichier pom.xml, il faut donc ajouter
les dépendances suivantes
▪ Dans le fichier web.xml de l’application,
il faut ensuite déclarer la Servlet fournie par
Jersey :

pom.xml

web.xml
 Web Service : API REST JAX-RS
▪ Implémenter des ressources avec JAX-RS
▪ JAX-RS permet d’implémenter des ressources sous la forme de composants Java EE. Une
classe représentant une ressource est identifiée grâce à l’annotation @Path.
▪ @Path : L’annotation @javax.ws.rs.Path indique le chemin d’URI qui identifie la ressource.
Cette annotation est utilisable sur une classe et sur les méthodes.
▪ Utilisée sur une classe, cette annotation permet d’identifier la classe comme une ressource
racine qui devient dès lors un composant géré par le serveur d’application.

▪ Pour l’exemple ci-dessus, la ressource sera identifiée par l’URI : http://[hôte]/[contexte

racine]/[mapping servlet]/user
▪ Utilisée sur une méthode, cette annotation permet de spécifier une sous-chemin dans la
ressource. Si cette méthode retourne une classe utilisant des annotations JAX-RS, on parle
alors de sous-ressource.
 Web Service : API REST JAX-RS

▪ Implémenter des ressources avec JAX-RS

▪ Pour l’exemple ci-après, l’instance de la classe GeoLocation retournée par la méthode est

accessible par l’URI : http://[hôte]/[contexte racine]/[mapping servlet]/user/geo

▪ Si la classe GeoLocation utilise elle-même des annotations JAX-RS alors on dit qu’il s’agit

d’une sous-ressource. Il devient possible de créer des arborescences de ressources en Java

basées sur le chemin de l’URI.

 Web Service : API REST JAX-RS
▪ Les annotations de méthodes
▪ JAX-RS fournit une annotation pour presque toutes les méthodes HTTP :
• @javax.ws.rs.GET
• @javax.ws.rs.POST
• @javax.ws.rs.PUT
• @javax.ws.rs.DELETE
▪ Elles permettent d’indiquer quelle méthode Java
doit être appelée pour traiter la méthode de la
requête HTTP entrante.
▪ Si aucune méthode Java n’est déclarée pour traiter
la méthode HTTP de la requête entrante, alors le
serveur répondra le code erreur 405(Method not allowed)
▪ On déclare des paramètres de chemin entre
accolades et on utilise l’annotation
javax.ws.rs.PathParam pour récupérer leur
valeur dans les paramètres des méthodes
 Web Service : API REST JAX-RS
▪ @Consumes / @Produces :
▪ Lorsqu’un client soumet une requête pour transmettre des informations au serveur (comme des données de
formulaire) et quand un serveur retourne du contenu à un client, il est nécessaire de préciser le type de
contenu. On utilise pour cela l’en-tête HTTP Content-type avec comme valeur le type MIME.
▪ Une liste (non exhaustive) des types MIME les plus courants est :

▪ La classe et/ou les méthodes d’une Ressource JAX-RS peuvent utiliser les
annotations @Consumes et @Produces pour indiquer respectivement le type de contenu attendu dans la
requête et le type de contenu de la réponse.
 Web Service : API REST JAX-RS
▪ @Consumes / @Produces :
Plutôt que d’écrire : @Produces("application/json")
Il est recommandé d’utiliser les constantes déclarées dans la classe javax.ws.rs.core.MediaType
@Produces(MediaType.APPLICATION_JSON)
 Web Service : API REST JAX-RS
▪ DATA Binding
▪ Lorsqu’une méthode d’une ressource retourne une instance d’un objet Java, JAX-RS va tenter
de créer une réponse au format souhaité en fonction de l’annotation @Produces. Il existe un
ensemble de règles par défaut permettant de passer d’un objet Java à un document XML ou
JSON. On appelle l’ensemble de ces règle le DATA binding.
▪ Si la réponse attendue est au format JSON alors JAX-RS va construire une réponse en se
basant sur les accesseurs (les getters) de la classe.
▪ Si on définit une ressource de la façon suivante :

Alors un appel HTTP

à cette ressource
génèrera un document
JSON de la forme :
 Web Services : Différences clés entre SOAP et REST
▪ Ci-après quelques différences clés entre SOAP et REST

SOAP: Simple Object Access Protocol REST: Representational State Transfer

SOAP est un protocole ou un ensemble de REST est un style d'architecture logicielle

normes
SOAP ne peut pas utiliser REST car il est lui- REST peut utiliser SOAP car il s'agit d'un concept
même un protocole et peut utiliser n'importe quel protocole comme
HTTP, SOAP, etc

SOAP utilise l'interface de service pour REST utilise l'URI pour exposer la logique métier.
exposer la logique métier Mais comme REST fonctionne sur la base du type
de requête HTTP, le même URI peut donc
fonctionner pour plusieurs types d'opérations

SOAP définit des normes à suivre strictement. REST ne définit pas trop de standards. REST est
SOAP est exigent assez flexible
SOAP définit sa propre couche de sécurité REST hérite des mesures de sécurité des
protocoles de transport sous-jacents
SOAP ne fonctionne qu'avec le format XML REST accepte différents formats de données tels
que Texte brut, HTML, JSON, XML, etc
L'environnement d'exécution des applications J2EE
▪ J2EE propose des spécifications pour une infrastructure dans laquelle
s'exécutent les composants. Ces spécifications décrivent les rôles de chaque
élément et précisent un ensemble d'interfaces pour permettre à chacun de ces
éléments de communiquer. Exp: les spécifications JEE v7 font ~4000 pages

▪ Ceci permet de séparer les applications et l'environnement dans lequel elles

s'exécutent. Les spécifications précisent à l'aide des API un certain nombre de
fonctionnalités que doit implémenter l'environnement d'exécution. Ces
fonctionnalités permettent aux développeurs de se concentrer sur la logique
métier.

▪ Pour exécuter ces composants de natures différentes, J2EE définit des

conteneurs pour chacun d'eux. Il définit pour chaque composant des interfaces
qui leur permettront de dialoguer avec les composants lors de leur exécution.

▪ Les conteneurs permettent aux applications d'accéder aux ressources et aux

services en utilisant les API.
Les conteneurs (1/2)

▪ Il existe trois (03) conteneurs définis par J2EE:

1. Conteneur Web : pour exécuter les servlets, les JSP et les JSF.
2. Conteneur d'EJB : pour exécuter les EJB.
3. Conteneur Client : pour exécuter des applications standalone/Desktop sur les
postes qui utilisent des composants J2EE.

▪ Pour déployer une application dans un conteneur, il faut lui fournir deux éléments :
➢ l'application avec tous les composants (classes compilées, ressources ...)
regroupées dans une archive ou module. Chaque conteneur possède son
propre format d'archive.
➢ un fichier descripteur de déploiement contenu dans le module qui précise au
conteneur des options pour exécuter l'application.
Les conteneurs (2/2)
▪ Il existe trois types d'archives :

Archive / module Contenu Extension Descripteur de déploiement

bibliothèque Regroupe des classes jar (Java

ARchive)
application client Regroupe les ressources nécessaires à leur jar application-client.xml
exécution (classes, bibliothèques, images, ...)

web Regroupe les Servlets, les JSP et les JSF War (Web web.xml
ainsi que les ressources nécessaires à leur ARchive)
exécution (classes, bibliothèques de balises,
images, ...)
EJB Regroupe les EJB et leurs composants jar ejb-jar.xml
(classes)
Application J2EE ear (Entreprise application.xml
Regroupe un ou plusieurs modules ARchive)
Les conteneurs (2/2)
▪ Composition d’une Application J2EE :
Les conteneurs : Synthèse

Diagramme D’architecture J2EE

Le conteneur web : Exemple de Cycle de vie des servlets
▪ Le conteneur Web gère le cycle de vie des servlets : la création, l’initialisation et la
destruction.
▪ À chacune de ces étapes, une instance de servlet est informée par un appel à une
méthode déclarée dans l’interface Servlet et qui peut être redéfinie pour chaque
servlet.

▪ De plus la servlet sera prévenue de sa création par un appel à son constructeur.

Cela a une conséquence importante pour l’implémentation d’une servlet : une
servlet doit obligatoirement avoir un constructeur sans paramètre.
Les API de J2EE : Historique

La fondation Eclipse a pris en

charge J2EE 8 qui est devenu
par la suite JAKARTA EE
depuis 2018
J2EE historique
J2EE 1.4 (Diffusée en novembre 2003)
• Le support des services web (nouveau)
• J2EE deployment API 1.1 (nouveau)
• J2EE management API 1.0 (nouveau)
• Java ACC : Java Authorization Contract for Container (nouveau)
• EJB 2.1 (update)

Java EE 5.0 (Diffusée en 2007)

• Les annotations
• JSF
• JPA
• EJB 3.0
• Le support des dernières versions des API concernant les services web et permettant une mise
en œuvre d'une architecture de type SOA.

Java EE 6.0 (Diffusée en décembre 2009)

• Plus riche : de nouvelles spécifications sont ajoutées et les spécifications majeures sont
enrichies
• Plus facile : généralisation de l'utilisation des POJO et des annotations notamment dans le tiers
web
• Plus légère : création de la notion de profiles et de pruning, EJB Lite
• Toujours aussi robuste après 10 ans d'existence.
• L'implémentation de référence est le projet open source GlassFish version 3.
La notion de Profile
▪ Java EE 6 définit la notion de profile qui est un sous-ensemble et/ou un sur-ensemble
de Java EE 6 pour des besoins particuliers.

▪ Les profiles sont conçus pour proposer une solution technique particulière pour des
besoins spécifiques. Cela permet à un fournisseur de n'avoir à proposer que le support
des technologies incluses dans le profile plutôt que d'avoir à implémenter toutes celles
de la plate-forme Java EE.

▪ Java EE 6 définit un premier profile : le web profile qui se concentre sur le

développement d'applications de type web. Il doit pouvoir être exécuté dans un simple
conteneur web car le packaging se fait dans une archive de type war.
La notion de Pruning (1/2)
▪ La plate-forme Java EE est devenue au fil des versions imposante en terme de
nombre de spécifications, de fonctionnalités et d'API.
▪ Aucunes des précédentes versions n'a supprimé de fonctionnalités même si
certaines sont obsolètes car remplacées, rarement adoptées ou utilisées. Cela
pose plusieurs problèmes :
➢ Pour le développeur : la taille du SDK augmente avec le nombre d'API
➢ Pour les fournisseurs de serveurs d'applications : l'obligation de support pour
ces fonctionnalités avec un accroissement de la taille des serveurs, de leur
consommation en ressources et de leur temps de démarrage.
▪ Java EE 6 entame donc une cure d'amaigrissement de la plate-forme en
définissant un ensemble d'API déclarées comme pruned.
La notion de Pruning (2/2)
▪ Les fonctionnalités déclarées pruned dans Java EE 6 sont :

▪ Elles doivent toujours être disponibles dans une implémentation de Java EE 6

mais elles seront amenées à disparaître dans les prochaines versions de la
plate-forme Java EE et leur support ne sera plus obligatoire dans les
implémentations des serveurs d'applications.

▪ Le concept de pruned est plus fort que le concept de deprecated de la plate-

forme Java SE.
Java EE 7.0 (1/5)
▪ Les spécifications de Java EE 7 sont définies dans la JSR ( Java Service
Request) 342. Cette spécification liste l’ensemble des API qui sont incluses dans
la plate-forme et comment celles-ci interagissent entre-elles.

▪ Elle définit aussi des éléments précis de la plate-forme comme les transactions,
la sécurité, l'assemblage, le déploiement, ...

▪ Java EE 7 a plusieurs objectifs :

➢ poursuivre l'amélioration de la productivité et la simplification de l'utilisation
de la plate-forme.
➢ le support de HTML 5 (WebSocket, Json, HTML5 forms, ...).
➢ l'ajout de nouvelles fonctionnalités : Batch API (modèle de programmation
pour les applications batch) et Concurrency Utilities API (exécution de
traitements asynchrones sans avoir à utiliser JMS).

▪ Les spécifications de Java EE 7 furent officiellement diffusées en juin 2013.

Java EE 7.0 (2/5)

MEETING
DEVELOPER
ENTERPRISE
PRODUCTIVITY
DEMANDS

Java EE 7

▪ More annotated POJOs ▪ Batch

▪ Less boilerplate code ▪ Concurrency
▪ Cohesive integrated ▪ WebSockets
▪ Simplified JMS
platform ▪ JSON
▪ Servlet 3.1 NIO
▪ REST
Java EE 7.0 (3/5)
▪ Java EE 7 inclut plusieurs nouvelles API :
➢ Java API for JSON Processing 1.0 (JSR 353)
➢ Java API for WebSocket 1.0 (JSR 356)
➢ Batch Applications for the Java Platform 1.0 (JSR 352)
➢ Concurrency utilities for Java EE 1.0 (JSR 236)

▪ Java EE 7 inclut des API ayant une mise à jour majeure :

➢ Java Message Service 2.0 (JSR 343)
➢ Expression Language 3.0 (JSR 341)
➢ JAX-RS : Java API for Restful Web Services 2.0 (JSR 339)

▪ Java EE 7 inclut des API mises à jour :

➢ JPA 2.1 (JSR 338)
➢ EJB 3.2 (JSR 345)
➢ Servlet 3.1 (JSR 340)
➢ Java Server Faces 2.2 (JSR 344)
➢ Contexts and Dependency Injection for Java EE 1.1 (JSR 346)
➢ Bean Validation 1.1 (JSR 349)
➢ Interceptors 1.2 (JSR 318)
➢ Java EE Connector Architecture 1.7 (JSR 322)
Java EE 7.0 (4/5)
▪ Les JSR mises à jour (Maintenance Release) sont :
➢ Web Services for Java EE 1.4 (JSR 109)
➢ Java Authorization Service Provider Contract for Containers 1.5 (JACC 1.5) (JSR 115)
➢ Java Authentication Service Provider Interface for Containers 1.1 (JASPIC 1.1) (JSR 196)
➢ JavaServer Pages 2.3 (JSR 245)
➢ Common Annotations for the Java Platform 1.2 (JSR 250)
➢ Java Transaction API 1.2 (JSR 907)
➢ JavaMail 1.5 (JSR 919)

▪ Initialement Java EE 7 devait intégrer la spécification Java Temporary Caching API 1.0 (JSR 107)
et des fonctionnalités relatives au Cloud (par exemple State Management (JSR 350)) mais elles
sont repoussées dans la prochaine version de Java EE.
Java EE 7.0 (5/5)
▪ Java EE 7 poursuit la simplification de l'utilisation de la plate-forme entamée
depuis Java EE 5 notamment :
➢ la nouvelle version 2.0 de l'API JMS
➢ des changements dans la configuration : ressources de type fabrique de
connexions par défaut pour la base de données et le broker JMS,
amélioration dans la déclaration des permissions de sécurité, ...
➢ les technologies déclarées pruned dans Java EE 6 sont optionnelles dans
Java EE 7 : EJB Entity Beans, JAX-RPC 1.1, JAXR 1.0 et la JSR-88

▪ JAX-RS 2.0 est ajoutée dans le Web Profile.

▪ L'implémentation de référence de JEE 7 est la version 4.0 du serveur

d'applications Glassfish.
Java EE 7 : Zoom sur l’API WebSocket
▪ WebSocket est un standard du Web désignant un protocole réseau de la couche application et
une interface de programmation du World Wide Web visant à créer des canaux de communication full-
duplex par-dessus une connexion TCP pour les navigateurs. Le protocole a été normalisé par en 2011.
▪ Cela est possible en agissant sur le paramètre TTL (Time-To-Live) de la requête HTTP.
▪ L'API Java WebSocket définie dans JEE 7 (JSR 356) est un protocole d'application qui permet d'ouvrir une
session de communication interactive bidirectionnelle entre le navigateur de l'utilisateur et un serveur.
▪ Avec cette API, il est possible d’envoyer des messages à un serveur et recevoir des réponses basées sur
des événements (event-driven responses) sans avoir à interroger le serveur pour obtenir une réponse : La
notification au client d'un changement d'état du serveur.
▪ Permet une communication bidirectionnelle sur une seule connexion établie par une négociation HTTP
initiale et une demande de mise à niveau.
▪ L'envoi de données en mode Push du serveur vers le client,
▪ sans que ce dernier ait à effectuer une requête.
▪ Le package javax.websocket.server contient des annotations,
des classes et des interfaces pour créer et configurer
des points de terminaison de serveur.
Java EE 7 : Zoom sur l’API WebSocket
▪ Le gestion du cycle de vie est basée sur les annotation ci-dessous : Event-driven responses

▪ L'exemple montre comment utiliser la

méthode getOpenSessions pour
transférer les messages texte entrants à
tous les pairs connectés dans une
application de chat.
Java EE 7 : Zoom sur l’API BATCH

• Les applications par lots (BATCH) fournissent un modèle de programmation pour les applications par

lots/étapes et un environnement d'exécution pour la planification et l'exécution des tâches.

• L'API Java BATCH définie dans JEE 7 (JSR 352) a pour vocation de permettre l'exécution de jobs (ou

traitements batch) dans le contexte d'une application JEE et donc d'un serveur d'application (Glassfish,

JBOSS,…)

• Elle permet entre autres de définir des checkpoints, de supporter les transactions, elle permet aussi de

morceler et paralléliser les traitements.

• Elle s'intègre à JEE et peut profiter, par exemple, des fonctionnalités des serveurs d'application : injection

de dépendances (CDI), gestion des transactions (JTA)…

Java EE 7 : Zoom sur l’API BATCH/ Architecture générale d'un batch
▪ Un Job définit des étapes (Step), qui peuvent suivre le modèle ItemReader/ ItemProcessor/ ItemWriter.
▪ L'instance de JobOperator propose une manière d'interagir avec un batch Job (il peut l'arrêter, le démarrer,
le redémarrer, etc.)
▪ Chacun des éléments JobOperator, Job et Step sont associés à un unique JobRepository qui contient les
métadonnées associées à l'exécution courante.
▪ La configuration se fait de façon déclarative dans un fichier XML (couramment appelés « job.xml »).
▪ Le package javax.batch contient les classes et interfaces nécessaires
Java EE 7 : Zoom sur l’API BATCH/ Exécution d'un job
▪ Dans le diagramme ci-dessus, pour chaque élément (Item) de l'étape (des lignes d'un fichier par exemple),
le Step invoque n fois le couple read()/process(). Une fois la liste d'éléments constituée, l'opération write est
appelée sur ces éléments pour, par exemple, les stocker en base, les enregistrer dans un fichier, les
envoyer vers un flux de sortie, etc.
▪ Nous présenterons ainsi les éléments step (batchlet et chunck), nous présenterons également les points de
sauvegarde (checkpoints), nous préciserons finalement comment l'API gère les erreurs lors de l'exécution
des traitements.
Java EE 7 JSRs
JSF 2.2,
Web JAX-RS 2.0, WebSocket
JSP 2.3, JSON 1.0
Fragments JAX-WS 2.2 1.0
CDI EL 3.0
Extensions

Bean Validation 1.1

Servlet 3.1

Interceptors Common
CDI 1.1 Concurrency 1.0
1.2, JTA 1.2 Annotations 1.1

Managed Beans 1.0 EJB 3.2

JPA 2.1 JMS 2.0 JCA 1.7 Batch 1.0

▪ Les spécifications (JSR) sont disponibles moyennant le lien suivant :

https://java.net/projects/javaee-spec/pages/Home
Java EE 7.0

9,000,000
JAVA DEVELOPERS
DEPLOYING TO 18 COMPLIANT APPLICATION SERVERS

http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html
Java EE 7.0 : les serveurs
Java EE 7.0 Web Profile : les serveurs

RAPPEL
Apache Tomcat : c’est un Conteneur Web. Il permet d’exécuter uniquement les JSP/Servlet et
JSF. Apache Tomcat contient un serveur Web Apache. On l’appel le serveur web intégré.
Apache : C’est un Serveur Web qui répond aux requêtes HTTP/HTTPS et sert des ressources
statiques (html,js,jpg,css….). Pour que Apache sert des ressources dynamiques on lui ajoute la
notion de Plugin ( Plugin php, plugin ajp Apache Java Protocole pour servir des jsp/Servlet ….)
Java en chiffres Developer Ecosystem Survey 2020

Utilisation des langages de programmation

par les développeurs professionnels
Utilisation Secteurs où Java est utilisé

Industrie Développement logiciel en Java

Annexe : Exemple d’Architecture distribuée hautement disponible et
Résiliente
Conteneur WEB Conteneur EJB

API-REST/JSON

REST over HTTP

API-SOAP/XML
Annexe : TP.1-1 et TP.1-2
• L’annotation @WebServlet("/servlet/TestServlet2") remplace la configuration contenue dans
le fichier « web.xml ». Ci-dessous un exemple :

web.xml

url d’appel de la servlet

 Annexe : TP.1-1 et TP.1-2 (Prérequis)
1. Eclipse mars : eclipse-jee-mars-2-win32-x86_64
2. Apache-tomcat-8.0.53-windows-x64
3. Jdk1.8.0_92
Ou bien télécharger :
1. eclipse-jee-2020-12-R-win32-x86_64:- Eclipse IDE for
Enterprise Java Developers
https://www.eclipse.org/downloads/packages/release/2020-12/r
2. apache-tomcat-8.5.8
https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.72/bin/
3. Jdk1.8.0_92

Ne pas copier dans « Bureau ». Copier les prérequis dans D:\J2EE par exemple