Les Enterprise Java Beans 3.0

Les Enterprise Java Beans 3.0
Introduction
Les chalenges du développement d’applications pour l’entreprise
• Le développement d’une application pour l’entreprise pose des problèmes :
• faire face à la diversité des technologies et des modèles de programmation ;
• développer des applications pour différents types de clients ;
• nécessité d’avoir des mécanismes efficaces de gestions des ressources (base
de données, …) et des services (transaction, … ) ;
• faire face à une recrudescence d’utilisateurs :
• gérer le balancement de charges ;
• pouvoir changer de serveur ;
• interagir avec un système existant ;
• maintenir la sécurité en intégrant des systèmes disparates ;
• ...
Benoît Charroux - Introduction - Juillet 07 - 3
Le modèle de Java pour l’entreprise
La plate-forme Java Enterprise Edition 5 : un serveur d’applications
client
Enterprise Bean
Conteneur EJB
Systèmes
d’informations de
l’entreprise
Intranet
/
Extranet
client
Servlets,
JSP,
HTML,
XML
Conteneur WEB
Tiers client
Tiers du milieur (n-tiers) :
serveur d’applications
Benoît Charroux - Introduction - Juillet 07 - 5
Tiers du système
de l’entreprise
Les serveurs d’applications Enterprise Java Beans
• Un serveur d’application est une plate-forme d’exécution pour composants logiciels ;
• un composant EJB est un élément logiciel réutilisable qui n'implémente que la partie
métier d'une application ;
• le serveur d'EJB offre des services qui ne sont plus à la charge du développeur :
• la concurrence d'accès ;
• les transactions ;
• la persistance ;
• les objets distribués ;
• le nommage ;
• la sécurité.
client
Réseau
Serveur
d’applications
Base de données
Benoît Charroux - Introduction - Juillet 07 - 6
JEE coté client
navigateur
client
Servlets,
JSP,
HTML,
XML
Système
d’information de
l’entreprise
Conteneur WEB
serveur
Pour faire interagir une application JEE avec un client :
• Servlets : petits serveurs autonomes utilisés principalement pour générer
dynamiquement des informations pour le WEB ;
• Java Server Pages : page WEB combinant HTML (ou XML) et Java Beans.
Benoît Charroux - Introduction - Juillet 07 - 7
JEE coté entreprise
Enterprise Bean
client
Conteneur EJB
Systèmes
d’informations de
l’entreprise
Pour faire interagir une application JEE avec un système existant :
• Java Persistence API ;
• Java Transaction API (interface standard pour gérer des transactions) /
Java Transaction Service (implémentation) ;
• Java Naming and Directory Interface pour accéder à un service de nommage
(LDAP, …) ;
• Java Message Service pour interagir avec des systèmes orientés messages ;
• Java Mail.
Benoît Charroux - Introduction - Juillet 07 - 8
L’architecture des
Enterprise Java Beans
L’architecture des Enterprise Beans
client
Enterprise Bean
Conteneur EJB
Systèmes
d’informations de
l’entreprise
Intranet
/
Extranet
client
Servlets,
JSP,
HTML,
XML
Conteneur WEB
Tiers client
Tiers du milieur (n-tiers) :
serveur d’applications
Benoît Charroux - Introduction - Juillet 07 - 10
Tiers du système
de l’entreprise
Entity / Session bean / Message-Driven bean
Les types de Beans
• Session Bean : réalise une tâche pour un client (le seul type d'Enterprise Bean à
pouvoir implémenter un service WEB) ;
• Message-Driven Bean : est à l'écoute des messages tels ceux fournis par la Java
Message Service API ;
• Entity : objet élément de la logique métier léger et persistant.
View
Logique applicative
Model
(logique métier)
Session bean
Entity
Services :
- persistance ;
- transactions ;
...
Benoît Charroux - Introduction - Juillet 07 - 12
Les Entity
• Un entity est un objet métier léger et persistant ;
• Exemple de la gestion d’une médiathèque : Adhérent, Œuvre, Exemplaire
Nom Prénom
Adresse
Durand Paul 15 impasse nul part
Dupond Albert 2 allée Tataouine
Persistance
Base de données
Benoît Charroux - Introduction - Juillet 07 - 13
Les Session Beans
• Les session beans
• ne sont pas persistant ;
• Un statefull session bean :
• représente un flot de contrôle en faisant interagir des beans pour accomplir
une tâche particulière ;
• n’a qu’un seul client ;
• Un stateless session bean :
• permet d’implémenter des services particuliers (par exemple obtenir une liste
de données par accès direct à une base de données) ;
• est un ensemble de méthodes qui utilisent leurs seuls paramètres pour
produire un résultat (ils peuvent aussi utiliser leurs SessionContexts) ;
• peut être utilisé par plusieurs clients => à utiliser pour les applications
nécessitant de nombreux clients ;
• est plus performant qu’un bean avec état car il n’est pas sérialisé dans une
base de données.
Benoît Charroux - Introduction - Juillet 07 - 14
Des interfaces distantes pour accéder à un session bean
• Un client n’a accès qu’aux méthodes définies dans une interface ;
• l’implémentation, les accès à la base de données, etc, sont masqués.
stub
interface
client
interface
Bean
Conteneur EJB
Serveur EJB
Exemple d’une interface :
@Remote
public interface Mediatheque{
public List<String> String getListAdherents();
public boolean emprunter( String nomAdherent, String titreOeuvre );
}
Benoît Charroux - Introduction - Juillet 07 - 15
Des interfaces locales pour accéder à un session bean
• Accéder à un composant distant via une interface remote a un coût (on passe par un
stub et un squelette ) ;
• pourquoi avoir un tel coût si les clients sont locaux (dans la même machine virtuelle
que le serveur) ?
• Exemple de deux beans qui communiquent :
Bean
@Local
public interface Mediatheque{
Local interface
public List<String> String getListAdherents();
...
}
Bean
Conteneur EJB
Serveur EJB
Benoît Charroux - Introduction - Juillet 07 - 16
Les Message-Driven Beans
• Intérêt des Message-Driven beans :
• comment un bean peut-il être activé quand un événement se produit ?
• mauvaise solution : mettre en attente de l'événement un session bean =>
problème : consommation de ressources ;
• bonne solution : utiliser un message-driven bean.
• Principe des message-driven beans :
• les événements émis (appelés des messages) sont conservés dans un MOM
(Middleware Orienté Message ou middleware asynchrone) ;
• l'émetteur est débloqué dès que le message est reçu par le MOM ;
• le MOM se charge d'envoyer le message au destinaire (le message-driven bean)
;
Benoît Charroux - Introduction - Juillet 07 - 17
Les Message-Driven Beans
• L'émetteur d'un message peut-être :
• n'importe quel composant JEE (un enterprise bean ou un composant WEB) ;
• une application cliente JEE ;
• une application cliente non JEE.
• Les messages sont du type :
• Java Messaging Services ;
• d'un autre types (binaire, ...).
Benoît Charroux - Introduction - Juillet 07 - 18
Les services
Les services
• Les serveurs EJB assurent les 6 principaux services suivants :
• la concurrence ;
• les transactions ;
• la persistance ;
• les objets distribués ;
• le nommage ;
• la sécurité.
Benoît Charroux - Introduction - Juillet 07 - 20
Paramètres des
méthodes d'un bean
Les paramètres des méthodes
• Isolation :
• quand un client distant transmet des paramètres à un bean => le bean reçoit
des copies de ces paramètres ;
• quand un client local transmet des paramètres à un bean => passage par
référence => client et bean manipulent les mêmes objets via des références.
• Granularité des paramètres :
• comme les appels de méthodes distantes sont plus long que les appels locaux,
il faut transmettre plus d'informations à chaque appel => les objets transmis en
paramètre ne doivent pas avoir une granularité trop fine.
Benoît Charroux - Introduction - Juillet 07 - 22
Conventions de nomage
Les noms de composants
• Soit X le nom que l'on souhaite donner à un composant :
• X doit être le nom de l'interface ;
• Xbean doit être le nom de l'Enterprise Bean (de l'implémentation de
l'interface X).
Benoît Charroux - Introduction - Juillet 07 - 24
Le cycle de vie des
session beans
Le cycle de vie des statefull session beans
Inexistant
1. appel à remove
ou time out
Appel des méthodes
de post-construction
Time out
2. Appel des
méthodes de prédestruction
Appel des méthodes
de pré-désactivation
Prêt
Passif
Appel des méthodes
de post-activation
Benoît Charroux - Introduction - Juillet 07 - 26
Le cycle de vie des stateless session beans
Inexistant
Appel des méthodes
de post-construction
Appel des méthodes
de pré-destruction
Prêt
• Un session bean n'est jamais désactivé car son état n'est pas conservé entre deux
appels de méthode.
Benoît Charroux - Introduction - Juillet 07 - 27
Les callback methods
@Statefull
public class MonComposantBean implements MonComposant{
... contenu;
@PostContruct // ou @PostDestroy ou @PostActivate ou @PrePassivate
public void ...(){
}
@Remove
public voir remove(){
contenu = null;
}
}
Benoît Charroux - Introduction - Juillet 07 - 28