C’est quoi JEE ?

Introduction

Jakarta EE (anciennement Java 2 Platform, Enterprise Edition, ou J2EE, puis Java Platform, Enterprise Edition ou Java EE) est une spécification pour la plateforme Java permettant de passer du 3 tiers au multitiers. C’est un framework (cadre de travail qui aide le développeur a développer son application ) pour développer des applications d’entreprise en se concentrant sur les logiques métiers. Ces applications d’entreprise seront déployées et exécutées par un serveur d’applications, dont Glassfish est l’implémentation de référence. JEE propose des interfaces à implémenter par les constructeurs de serveur d’application pour assurer l’ensemble des préoccupation transversales et la plomberie (tout ce qui n’est pas métiers, donc). La gestion du cycle de vie des objets est géré par JEE, il ne faut donc pas instancier les composants soit même.

Afin de répondre aux problématiques des applications d’entreprise, il faut décomposer le problème en responsabilité :

  • Core concerns (préoccupations métiers) : logique métier = Ce pourquoi on doit faire un programme
  • Cross-cutting concerns (préoccupations transversales) : sécurité… Les opérations nécessaires secondaire pour permettre à l’application de s’exécuter correctement et efficacement.
  • Plumbing (préoccupations réseaux) : gestion protocole, connexion… 
Exemple de responsabilités

Les composants métiers – Enterprise Java Beans (EJB)

Un composant est un module logiciel autonome pouvant être installé sur plusieurs plateformes. Attention à ne pas confondre un composant avec un objet JAVA. Les EJB définissent l’architecture de composants logiciels côté serveur pour la plateforme de développement JEE. Ainsi, on ne touche plus à la base de données directement (plus besoin de SQL). Il faudra utiliser une API qui va déléguer les requêtes à la base de données à un serveur d’entreprise. Pour mettre en place des EJB, il faut utiliser EJB Entity et EntityManager qui proposent des méthodes pour interagir avec la base de données comme persist, merge, remove, find, refresh, flush…

Il existe trois types d’EJB :

  1. Les EJB Session qui fournissent un service aux clients. Ils représentent les points d’entrée de la couche métier et sont accessibles via le réseau (en passant par le protocole RMI) ou localement dans la JVM du client. Il existe deux types d’EJB sessions : les Bean Statefull (code métier + données de session) et les Bean Stateless (code métier uniquement, pas de données de session)
  2. Les EJB Entity qui représentent les données qui proviennent ou qui alimentent la base de données. Ils ne sont généralement pas accessibles directement au client. Ce dernier doit, traditionnellement, passer par un EJB session pour récupérer des EJB entités.
  3. Les EJB MessageDriven représentent une file de messages postés par le client et traités par le serveur (ou vice-versa). Nous ne les étudierons pas dans ce TP.

Les couches d’une application JEE

La couche entities

Elle contiendra l’ensemble de nos EJB Entity, représentant notre modèle de données persistant.

La couche repositories

Elle contiendra l’ensemble de nos EJB Facade d’entités, responsables de la manipulation du modèle de données persistant.

La couche business

Elle contiendra nos EJB Session métiers, responsables des traitements métiers de notre application (EJB qui manipulent les EJB Facade).

La couche services

Elle contiendra nos EJB Session exposant nos services métiers selon le rôle des utilisateurs (EJB qui manipulent nos EJB Session métiers).

Exemple de

Exemple de mise en place

Création de l’interface métier

Voici quelques détails concernant l’accessibilité d’un EJB :

REMOTELOCAL
Le client et le container d’EJB utilisent une JVM différente. Ainsi, l’appel de l’EJB dans le serveur d’application sera différent car le fichier EAR sera différent. Les appels aux EJB seront donc plus coûteux. Les EJB seront accessibles via le protocole RMI, pas par référence (car JVM différente justement !). Un exemple d’application est le client lourd.Le client et le container d’EJB utilisent la même JVM. Les appels des EJB sont effectués dans le même serveur d’application puisque c’est le même fichier EAR. De plus, les variables sont passées par référence puisque la JVM est la même. Les appels sont moins coûteux car il n’y a pas sérialisation des retours. Un exemple d’application est le site web.
import javax.ejb.Remote;

@Remote
public interface ToUpper {
   String toUpper(String data);
}
Implémentation

Voici quelques détails supplémentaires concernant les types d’EJB Session :

Statefull Stateless
Contient du code métier est des données de session. Possèdent un état qui reflète l’état de la discussion avec un client particulier. Il existe dans le serveur d’application autant d’instances que de clients connectés au serveur. Les instances d’un EJB Session Stateful sont donc spécifiques à un client. Ces EJB sont souvent utilisés pour représenter un utilisateur connecté.Contient uniquement du code métier, il n’y a pas de données de session et donc pas d’état. Il existe sur le serveur d’application une ou plusieurs instances de ces EJB qui sont utilisées par tous les clients de manière simultanée. Il n’existe pas de liens entre les instances côté serveur et les clients. Ces EJB sont souvent utilisés comme guichet unique d’une couche métier.
import javax.ejb.Stateless;
import monpkg.services.ToUpper;

@Stateless(name = "toUpper", description = "Un premier essai")
public class ToUpperImpl implements ToUpper {

   public String toUpper(String qui) {
      return qui.toUpperCase();
   }
}

Les principales interfaces JEE

  • JDBC : API de connection à des SGBDR, indépendante des SGBD
  • JPA : API de gestion de la persistence de données relationnelles
  • RMI : API de programmation haut niveau générique pour l’informatique distribuée ; permet la communication entre objets Java distants
  • Java IDL : API de communication entre objets Java et objets non-Java distant via le protocole CORBA
  • JTA : API de gestion des transactions
  • JNDI : API générique de connexion à des annuaires, pour rechercher des objets ou des données distants
  • JMS : API de communication asynchrone par message
  • EJB : Modèle de composant pour forger des unités de logique métier, dont les cross-cuting concerns seront assurés automatiquement (transaction, cache/pooling, cycle de vie…)

Les principales interfaces JEE Web

  • Servlets : Composant générique pour permettre d’étendre la fonctionnalité de n’importe quel serveur qui utilise un protocole C/S. Utilisées principalement par des serveurs web (concurrent de l’ASP ou des scripts CGI). Le « C » du pattern MVC
  • JSP (JavaServer Pages) : Framework Web, le « php » du Java ; permet de mélanger HTML et Java
  • JSF (JavaServer Faces) : Framework Web MVC pour séparer distinctement code HTML et code Java
  • JAX-RPC / JAX-WS : API de Web Service (SOA) ; communication synchrone par XML par exemple à l’aide du protocole SOAP
  • JAX-RS : API de Services REST ; communication synchrone orientée ressource

Sources

Leave a Comment