ICAR’03

École d’été sur les Intergiciels et

sur la Construction d’Applications Réparties

L’environnement J2EE : principes,

fonctions, utilisation

P. Déchamboux
 Sommaire

■ Présentation basée essentiellement sur J2EE 1.3

(sécurité non traitée ici !!)

■ Introduction

■ Approche à composants

■ Modèles de programmation

■ Packaging & Déploiement

© 2003, P. Déchamboux ICAR’03 2

 Introduction

© 2003, P. Déchamboux ICAR’03 3

 J2EE pour quoi faire ?

■ Infrastructure « serveur » pour le support

d’applications d’entreprise
■ Architecture multi-tiers
◆ Architecture client léger (architecture Web basée « browser »)
◆ Architecture client lourd
◆ Architecture orientée service (application répartie sans
présentation)

■ Support de QoS : transaction, sécurité

■ Connexion standard à des systèmes d’information
externes (accès au « legacy »)

© 2003, P. Déchamboux ICAR’03 4

 Architectures usuelles

Navigateur
Application Tiers Terminal
Web
Cliente Client Client
(Pages HTML)

Composants
de Tiers
présentation : Web
Servlet HTTP
+ Pages JSP
Serveur
J2EE
Composants Composants
d’entreprises : d’entreprises :
EJB (logique EJB (logique Tiers
métier + métier + Métier
données) données)

Tiers Serveur
Base de données Base de données « EIS » Base de données

© 2003, P. Déchamboux ICAR’03 5

 J2EE sous l’œil de Darwin !

■ Standard en évoluation/maturation depuis 1997/1998

(J2EE 1.0, …, 1.3, 1.4, etc)
■ Au départ support d’applications Web n-tiers
(architecture décentralisée)
◆ Présentation : ServLet (principalement HTTP)
◆ Logique métier : EJB
◆ Gestion de données : JDBC
■ Vers une infrastructure de support standard pour EAI
◆ Facteurs de rationalisation majeur (JTA/JTS, JMS, JCA, WS)
◆ Découplage support technique / passerelles fonctionnelles
◆ Évolution de produits existants vers J2EE (WebMethods,
Peoplesoft, etc)

© 2003, P. Déchamboux ICAR’03 6

 Indépendance comme principe
directeur

■ Recherche d’une
indépendance maximale du
code applicatif
COMPOSANT
◆ Pas de liaison statique entre APPLICATIF
modules de code applicatif
(composants)

…
CONTAINER
◆ Pas de liaison statique entre
modules de code applicatif et
services plate-forme
SERVICE 1
◆ Eviter l’utilisation de code SERVICE…2
« technique » dans le code
SERVICE N
applicatif
■ Pas important vers du code
applicatif plus réutilisable !!

© 2003, P. Déchamboux ICAR’03 7

 Ce que définit J2EE

■ Spécification de la plate-forme
◆ Containers (programmation, déploiement)
◆ Serveur et services (exécution)

■ Implantation de référence opérationnelle

■ Suite de tests de compatibilité
◆ Certification Sun
◆ Accès au processus de certification payant (cher !!)
◆ Incompatibilité avec l’ « open source »

■ Conseils de mise en œuvre

◆ Application Pet Store (J2EE Blueprints)

© 2003, P. Déchamboux ICAR’03 8

 Vue générale de l’architecture J2EE

Application J2EE

RMI
Container
WS Container Web Containers EJB Connecteurs
Container Client Container J2EE Serveur
CLIENT LOURD
Serveur de noms

Web (moteur de

Sécurité (JAAS)
Mail (JavaMail)

Administration
SGBD (JDBC)
MOM (JMS)
Servlet, JSP)

Connecteurs
Transaction
ORB (RMI)

(JTA, JTS)
(JNDI)

(JMX)

(JCA)
HTTP

RMI

SERVEUR J2EE
CLIENT LEGER
Bases de Données
(Oracle, …)
© 2003, P. Déchamboux ICAR’03 9
 Configurations possibles d’un
serveur J2EE : clients lourds

Application Application
Cliente Cliente
Application J2EE :
Architecture centralisée Services (jdbc, EJB
mail, jca, etc)
Services (jdbc,
mail, jca, etc)

SERVEUR J2EE

Application Application
Cliente Cliente

Application J2EE : EJB EJB EJB

Architecture client/serveur
Services (jdbc, Services (jdbc, Services (jdbc,
mail, jca, etc) mail, jca, etc) mail, jca, etc)

© 2003, P. Déchamboux ICAR’03 10

 Configurations possibles d’un
serveur J2EE : clients Web

Navigateurs Navigateurs
(HTML, WML) (HTML, WML)

Application J2EE : Servlet Servlet

Architecture Web
/ Services (jdbc, EJB
Serveur centralisé mail, jca, etc)
Services (jdbc,
mail, jca, etc)
SERVEUR J2EE
Navigateurs Navigateurs
(HTML, WML) (HTML, WML)
Application J2EE :
Architecture Web Servlet Servlet
/
Serveur réparti
EJB EJB EJB

Services (jdbc, Services (jdbc, Services (jdbc,

mail, jca, etc) mail, jca, etc) mail, jca, etc)

© 2003, P. Déchamboux ICAR’03 11

 Offre importante

■ Offre commerciale
◆ IBM / WebSphere (n° 1)
◆ BEA / WebLogic
◆ Sun One
◆ Oracle 9i Application Server
◆ Et aussi Borland Entreprise Server, Macromedia / Jrun, SAP Web
Application Server, Iona / Orbix E2A

■ Offre « open source »

◆ JBoss (n° 1)
◆ JOnAS
◆ EJB : OpenEJB, EJBean

© 2003, P. Déchamboux ICAR’03 12

 Les fonctions couvertes par J2EE - 1
(standards connexes)

■ Java Servlets
■ JavaServer Pages (JSP)
■ Enterprise JavaBeans
■ Java Message Service (JMS)
■ JDBC
■ Transactions
◆ JTA
◆ JTS
■ J2EE Connector Architecture (JCA)
■ Corba (Java IDL)
■ JavaMail

© 2003, P. Déchamboux ICAR’03 13

 Les fonctions couvertes par J2EE - 2
(standards connexes)

■ XML/SOAP
◆ Java API for XML Processing (JAXP)
◆ Java API for XML Registries (JAXR)
◆ Java API for XML-Based Remote Procedure Call (JAX-RPC)
◆ SOAP with Attachments API for Java (SAAJ)

■ J2EE Deployment Specification (JSR-88)

■ J2EE Management Specification (JSR-77)

© 2003, P. Déchamboux ICAR’03 14

 Plus d’information…

■ http://java.sun.com/
■ http://www.theserverside.com/
■ http://developer.java.sun.com/developer/technicalArti
cles/J2EE/
■ http://developer.java.sun.com/developer/onlineTrainin
g/J2EE/
■ http://www.triveratech.com/
■ http://jonas.objectweb.org/

© 2003, P. Déchamboux ICAR’03 15

 Approche à composants

© 2003, P. Déchamboux ICAR’03 16

 Composants J2EE

■ Modules de code réutilisable qu’on peut assembler

■ Vision ad hoc non systématique
■ Définition (code Java + descripteur XML)
◆ Interface d’accès aux instances
◆ Interface « home » : usine abstraite (« interface fournie »)
◆ Définition des dépendances (« interfaces requises »)
❖ Autres composants (EJB)
❖ Usines à connexion de gestionnaire de ressources (GR) :
JDBC, JMS, JCA, JavaMail, etc
❖ Ressources administrées : par exemple une destination JMS
❖ Cas particulier pour JTA : accès à UserTransaction
◆ Définition de propriétés paramétrables (attribut, type, valeur)

© 2003, P. Déchamboux ICAR’03 17

 Description d’un composant (1)

■ Définition d’un composant

<session>
<ejb-name>Inscription</ejb-name>
<home>org.icar.api.InscriptionHome</home>
<remote>org.icar.api.Inscription</remote>
<ejb-class>org.icar.lib.InscriptionBean</ejb-class>
<env-entry>
<description>Nombre maximum de participants</description>
<env-entry-name>maxParticipants</env-entry-name>
<env-entry-type>java.lang.Integer</env-entry-type>
</env-entry-value>120</env-entry-value>
</env-entry>
<!–- dépendances (xxx-ref) -->
</session>

© 2003, P. Déchamboux ICAR’03 18

 Description d’un composant (2)

■ Dépendance vers un EJB

<ejb-ref>
<description>Support « donnée » d’un participant</description>
<ejb-ref-name>ejb/Participant</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>org.icar.api.ParticipantHome</home>
<remote>org.icar.api.Participant</remote>
</ejb-ref>

■ Conventions de nommage des références

◆ Conventions sur le format des noms
❖ Nom de propriété Ù nom de variables de classe Java
❖ Nom de ressource (ex : ejb) Ù nom de classe Java
◆ Noms préfixés par le type de ressources référencées (ex : ejb, jms,
jdbc, mail, url, …)

© 2003, P. Déchamboux ICAR’03 19

 Description d’un composant (3)

■ Dépendance vers une usine à connexions de GR

<resource-ref>
<description>BD pour ICAR</description>
<res-ref-name>jdbc/BdIcar</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

■ Dépendance vers une ressource

<resource-env-ref>
<description>Queue pour processus d’inscription</description>
<resource-env-ref-name>jms/QueueProcInscr
</resource-env-ref-name>
<resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
</resource-env-ref>

© 2003, P. Déchamboux ICAR’03 20

 Assemblage de composants

<ejb-ref>

■ Phase 1 : description de l’assemblage ...

<ejb-ref-name>
◆ Pour les composants EJB : ejb-link ejb/Participant
</ejb-ref-name>
◆ Non standardisé pour les autres liaisons ...
<ejb-link>
■ Phase 2 : mise en liaison effective Participant
</ejb-link>
◆ Récupération à l’exécution des </ejb-ref>

◆ Programmatique : à travers JNDI

◆ Espace de nommage privé (java:comp/env)
Context ctxtComp = new InitialContext().lookup("java:comp/env");
Integer maxParticipants = ctxtComp.lookup("maxParticipants");
ParticipantHome partHome = (ParticipantHome)
PortableRemoteObject.narrow(ctxtComp.lookup("ejb/Participant"), ParticipantHome.class);
DataSource bdIcar = (DataSource) ctxtComp.lookup("jdbc/BdIcar");
Queue qProcInscr = (Queue) ctxtComp.lookup("jms/QueueProcInscr");
UserTransaction utx = new InitialContext().lookup("java:comp/UserTransaction");

© 2003, P. Déchamboux ICAR’03 21

 Liaisons à base d’ ejb-link

■ Liens entre contexte privé d’un composant et contexte du

package déployé
■ Mis en œuvre par le support de déploiement du serveur J2EE
■ Offre de modularité : liaisons entre composants appartenant à
des packages différents
icar03.ear

Serveur J2EE processusInscription.jar

ejb:
Composant Inscription :
Environnement privé java:comp/env name: Inscription
ejb-ref:
name: ejb/Participant
maxParticipants link: donneesIcar.jar#Participant
ejb/Participant
jms/QueueProcInscr
jdbc/BdIcar donneesIcar.jar
…
ejb:
name: Participant

© 2003, P. Déchamboux ICAR’03 22

 Modèles de programmation

© 2003, P. Déchamboux ICAR’03 23

 Différents types de composants J2EE

■ Clients
◆ Applet
◆ Midlet
◆ Application autonome (container J2EE client)

■ ServLets (container Servlet)

■ EJBs
◆ Session (container Session Bean)
◆ Entité (container Entity Bean)
◆ Orienté message (container Message Driven Bean)

■ Connecteurs

© 2003, P. Déchamboux ICAR’03 24

 Programmation des « Servlets »

© 2003, P. Déchamboux ICAR’03 25

 Composants « Servlet »

-> doGet
service(requête, réponse) -> doPost
■ Composants protocolaires de
-> doHead
J2EE (principalement utilisé
pour présentation Web) Decodeur Réponse
JspServlet
-> Requête -> encodeur
■ Traitement d’interactions
réseau de type
« requête/réponse » Decodeur
-> Requête
Réponse
-> encodeur
HttpServlet
■ Architecture de gestion d’une
pile protocolaire Decodeur Réponse
GenericServlet
-> Requête -> encodeur
■ Encapsulation des flux
entrant/sortant par un appel
procédural (service)

Flux sortant
Flux entrant
Communications
■ Hypothèse de base = réseau orientées
IP « stream »
■ Composition de protocole par
héritage
Réseau IP

© 2003, P. Déchamboux ICAR’03 26

 Cycle de vie d’une « Servlet »

N’existe pas

1. Charge la classe 1. Appel de

de la servlet destroy
2. Création de la 2. Rammassage de
servlet la servlet
3. Appel de init

Prêt

ATTENTION :
Appel a priori réentrant !!
1. Appel de
service

© 2003, P. Déchamboux ICAR’03 27

 Service offert par le Container Web

■ Gestion de HttpServlet
◆ Equivalent des « cgi » mais en Java
◆ Activation de « thread » plutôt que de « process »
◆ Génération de contenu Web dynamique
■ JSP (JavaServer Pages)
◆ Mélange de HTML et de code java
◆ Pré-compilation en Servlet au déploiement de web-app (ensemble
de Servlet)
■ Autres technologies de production de contenu Web dynamique
dynamique
◆ Pages « Enhydra/XMLC » : pas de mélange HTML / Java !!
◆ Templates « Velocity »

© 2003, P. Déchamboux ICAR’03 28

 Déploiement d’application Web
(web-app)

■ web-app
◆ ensemble de Servlet
◆ packagés dans un fichier « jar » (e.g., webapp.war)
◆ décrits par un fichier « web.xml »
■ Définition des propriétés (env-entry) et des
dépendances (resource-ref, resource-env-ref,
ejb-ref) au niveau de la web-app
-> pas au niveau de la Servlet !!!
■ Accès à l’environnement dans le code de la Servlet
par "java:comp/env/…"

© 2003, P. Déchamboux ICAR’03 29

 « Servlet » en action

■ Page Web (traitement par ■ Classe ServletInfos

doPost ou doGet selon la
méthode)
<form method="get" action="infos">
<input type="text"
name="nom"/>
<input type="submit"/>
</form>
<a href="infos?nom=Dupont">
Mr Dupont</a>
■ Descripteur web.xml
<servlet>
<servlet-name>s_infos</…>
<servlet-class>ServletInfos</…>
</servlet>
doGet(HttpServletRequest rq,
HttpServletResponse rs) {
String nom =
rq.getParameter("nom");
rs.setContentType("text/html");
PrintWriter pr = rs.getWriter();
pr.println("html");
...
<servlet-mapping>
<servlet-name>s_infos</…>
<url-pattern>/infos</…>
</servlet-mapping>

© 2003, P. Déchamboux ICAR’03 30

 Gestion de sessions

■ Identifier un utilisateur
◆ Géré par le client
◆ Transmission de l ’identité à chaque requête

■ Les méthodes
◆ Cookies (méthode par défaut)
◆ Réécriture d ’URL et champs HIDDEN
■ Classe javax.servlet.http.HttpSession
HttpSession getSession(boolean create)
dans HttpServletRequest

© 2003, P. Déchamboux ICAR’03 31

 Classe HttpSession

■ Lire et mémoriser des données

Object getAttribute(String nom)
void setAttribute(String nom, Object val)
■ Timeout d ’inactivité
int getMaxInactiveInterval()
void setMaxInactiveInterval(int sec)
■ Gestion par réécriture d ’URL (sans cookie)
String getRequestedSessionId()
dans HttpServletRequest
String encodeURL(String url)
dans HttpServletResponse

© 2003, P. Déchamboux ICAR’03 32

 Utilisation de « Cookies »

■ Cookie = {attribut}
◆ Obligatoires : Name, Value
◆ Optionnels : Domain, Path, MaxAge (sec), Secure (si transmis par
SSL)

■ Transport par HTTP ou HTTPS

◆ Dans les requêtes et les réponses
◆ {(nom,valeur)} dans l ’en-tête

■ Mémorisé par le navigateur de façon permanente

■ Renvoyé par le navigateur

© 2003, P. Déchamboux ICAR’03 33

 Utilisation des « Cookies »

■ Classe javax.servlet.http.Cookie
■ Envoyer un « Cookie »
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws
ServletException {
Cookie c = new Cookie("icar", "Dupond03");
c.setMaxAge(365*24*60*60); // valable un an
response.addCookie(c);
// ...
■ Lire les « Cookies » d’une requête
public Cookie[] getCookies() dans HttpServletRequest

© 2003, P. Déchamboux ICAR’03 34

 Programmation des clients J2EE

© 2003, P. Déchamboux ICAR’03 35

 Composants « client »

■ Correspondent au 1er tiers (plus haut niveau)

◆ Accès local
◆ Accès réparti à travers RMI

■ Classes Java ayant accès à tous les services J2EE

■ « Container » client J2EE
◆ Donne accès aux ressources J2EE
◆ Accès à travers JNDI (java:comp/env/… et
java:comp/UserTransaction)
◆ Gestion de la sécurité

© 2003, P. Déchamboux ICAR’03 36

 Programmation des EJB

© 2003, P. Déchamboux ICAR’03 37

 Composants EJB

■ Composants applicatifs de J2EE (code métier)

■ Potentiellement répartis et transactionnels
■ Trois profils
◆ Session : instances dédiées à un contexte d’interaction client
particulier
◆ Entité : instances partagées représentant les données de l’entreprise
◆ Orienté message : instances neutres réagissant à l’arrivée de
messages asynchrones

■ Gérés par un « container » (mécanisme d’interposition)

■ Pas d’accès direct au niveau programmatique (explicite
dans le modèle)

© 2003, P. Déchamboux ICAR’03 38

 Le rôle du « container »

■ Gestion du cycle de vie des CONTAINER

instances de composants
Cycle de vie
◆ Lié au profil
◆ « callbacks » applicatifs

CODE APPLICATIF
Interface
■ Contexte d’instance

d’interception
« local »
Instance

Objets
◆ Accès au méta-niveau
de
(retrouver les interfaces) composant
Interface
◆ Accès au contexte du « remote »
composant (assemblage /
propriétés) Contexte de
l’instance
■ Interception des appels
applicatifs (session et entité) JNDI :
◆ Support contrats techniques Pour session et entité - propriétés
- liens de composition

© 2003, P. Déchamboux ICAR’03 39

 Interfaces d’accès réparti

■ Applicables à deux profils de composants

◆ Session
◆ Entité

■ Accès réparti à travers RMI

◆ Modèle de programmation répartie en Java
◆ Support de différents protocoles de transport (JRMP, IIOP, autres)

■ Définition de deux interfaces par composant

◆ Interface d’instances « remote » : étend javax.ejb.EJBObject
◆ Interface d’usine « remote home » : étend javax.ejb.EJBHome
◆ Étendent indirectement java.rmi.Remote => méthodes génèrent
java.rmi.RemoteException

© 2003, P. Déchamboux ICAR’03 40

 Interfaces d’accès local

■ Applicables à deux profils de composants

◆ Session
◆ Entité

■ Accès local dans la JVM

◆ Même ClassLoader

■ Définition de deux interfaces par composant

◆ Interface d’instances « local » : étend
javax.ejb.EJBLocalObject
◆ Interface d’usine « local home » : étend javax.ejb.EJBLocalHome

© 2003, P. Déchamboux ICAR’03 41

 Contraintes de programmation avec
accès interceptés

■ Ne pas faire d’appel this.methode pour des

méthodes d’interfaces d’instances « local » ou
« remote »
■ Ne jamais diffuser this en paramètre de méthodes (à
moins d’en avoir pleinement conscience !!)
■ Accès aux interfaces depuis l’instance
◆ Solution cas local : this.ejbContext.getEJBLocalObject()
◆ Solution cas distant : this.ejbContext.getEJBObject()

■ Système de prévention des EJB

◆ Référence de composant qu’à travers des interfaces
◆ Une instance n’implante pas les interfaces « local » ou « remote » !!

© 2003, P. Déchamboux ICAR’03 42

 Mise en œuvre des transactions

■ Applicables aux trois profils de composants

◆ Session
◆ Orienté message

■ Gestion explicite des transactions

◆ Utilisation de javax.transaction.UserTransaction
◆ Contrôle de la transaction (timeout, « rollbackonly »)

UserTransaction utx = (UserTransaction) new

InitalContext().lookup("java:comp/UserTransaction");
utx.begin();
…
utx.commit(); // ou utx.rollback();

© 2003, P. Déchamboux ICAR’03 43

 Gestion déclarative des transactions
(« container-managed »)

■ Comportements associés aux méthodes

(démarcation = appel de méthode)
■ Spécifiés dans le descripteur de déploiement
■ Comportements possibles (défaut = « »)
◆ « NotSupported » : si transaction courante, elle est suspendue
◆ « Required » : si pas de transaction, nouvelle transaction
◆ « RequiresNew » : nouvelle transaction (si tx courante, suspendue)
◆ « Mandatory » : exception si pas de transaction courante
◆ « Supports » : si transaction courante, l ’utiliser
◆ « Never » : exception si transaction courante
■ Seuls « Required » et « NotSupported » valables pour
les composants « orienté message »

© 2003, P. Déchamboux ICAR’03 44

 Gestion des événements
transactionnels

■ Contexte d’application
◆ Composants session
◆ Comportements : « Required », « RequiresNew », « Mandatory »
■ Interception par un composant EJB des événements
transactionnels (produits par le « container »)
◆ Implantation de javax.ejb.SessionSynchronization
◆ Evénements
❖ afterBegin : appelé après exécution de
UserTransaction.begin par le container
❖ beforeCompletion : appelé avant exécution de commit par
le container
❖ afterCompletion : appelé après exécution de commit ou
rollback par le container

© 2003, P. Déchamboux ICAR’03 45

 Implantation d’un composant EJB

■ Implante l’interface du profil concerné

◆ Session : javax.ejb.SessionBean
◆ Entité : javax.ejb.EntityBean
◆ Orienté message : javax.ejb.MessageDrivenBean
■ Implante les méthodes des interfaces « local » et
« remote » (pas les interfaces elles-mêmes !!)
■ Implante une version renomée des méthodes des
interfaces « local home » et « remote home »
interface localHome implantation Bean
localInterface create(int p1) void ejbCreate(int p1)

■ Implante un constructeur public sans paramètre

© 2003, P. Déchamboux ICAR’03 46

 Composants EJB « session »

■ Manipulation par méthodes « métier »

◆ Accès local (interfaces « local » et « local home »)
◆ Accès distant à travers RMI (interfaces « remote » et « remote
home »)

■ Comportement transactionnel
◆ Spécifique à chaque méthode
◆ Pour les méthodes des interfaces « local » et « remote »

■ Associés de façon unique à un contexte d’exécution

« client » particulier
■ Non réentrant

© 2003, P. Déchamboux ICAR’03 47

 Cycle de vie d’un « session » sans
état

N’existe pas A l’initiative :

-de l’utilisateur
-du container
1. create (timeout)
2. newInstance 1. remove
3. setSessionContext 2. ejbRemove
4. ejbCreate

Opération sur « Home »

Prêt
Opération sur instance

ATTENTION :
Appel non réentrant !!
1. methode

© 2003, P. Déchamboux ICAR’03 48

 Cycle de vie d’un « session » avec
état (session longue)

N’existe pas A l’initiative :

-de l’utilisateur
-du container
1. create (timeout)
2. newInstance 1. remove
3. setSessionContext 2. ejbRemove
4. ejbCreate

A l’initiative
du container
1. ejbPassivate
Opération sur « Home »
Passif Prêt
Opération sur instance

1. ejbActivate

ATTENTION :
Équivalent au SWAP Appel non réentrant !!
mémoire virtuelle 1. methode

© 2003, P. Déchamboux ICAR’03 49

 Exemple d’un composant session :
« Inscription »
interface Inscription extends EJBObject {
void enregistre(InfoParticpant ip)
throws RemoteException;
InfoParticipant infos(String nom)
throws RemoteException;
}
interface InscriptionHome extends EJBHome {
Inscription create()
throws CreateException,
RemoteException;
} sbc.lookup("ejb/Particpant")); }
class InfoParticipant {
public String nom;
public String coordonnees;
...
}
© 2003, P. Déchamboux
class InscriptionBean
implements SessionBean {
private Context sbc;
private ParticipantHome partH;
void ejbActivate() {}
void ejbPassivate() {}
void ejbRemove() {}
void setSessionContext(SessionContext c) {
myCtxt = new InitialContext()
.lookup("java:comp/env"); }
void ejbCreate() {
partH = PortableRemoteObject.narrow(
void enregistre(InfoParticipant ip) {
Particpant p = partH.create(ip.nom,
ip.coordonnees); }
InfoParticipant infos(String nom) {
ip = new InfoParticipant();
Participant p = partH.findByPK(nom);
p.setInfoParticipant(ip);
return ip; }
}
ICAR’03 50
 Description du composant session
« Inscription »

<?xml version="1.0" encoding="ISO-8859-1"?> | | | | <ejb-ref-name>ejb/Participant

<!DOCTYPE ejb-jar PUBLIC | | | | </ejb-ref-name>
"-//Sun Microsystems, Inc.//DTD Enterprise | | | | <ejb-ref-type>Entity</ejb-ref-type>
JavaBeans 2.0//EN“ | | | | <home>org.icar.api.ParticipantHome
"http://java.sun.com/dtd/ejb-jar_2_0.dtd"> | | | | </home>
<ejb-jar> | | | | <remote>org.icar.api.Participant
| <description>Sessions ICAR</description> | | | | </remote>
| <display-name>Sessions ICAR</display-name> | | | | <ejb-link>donneesIcar.jar#Participant
| <enterprise-beans> | | | | </ejb-link>
| | <session> | | | </ejb-ref>
| | | <ejb-name>Inscription</ejb-name> | | </session>
| | | <home>org.icar.api.InscriptionHome | </enterprise-beans>
| | | </home> | <assembly-descriptor>
| | | <remote>org.icar.api.Inscription | | <container-transaction>
| | | </remote> | | | <method>
| | | <ejb-class>org.icar.lib.InscriptionBean | | | | <ejb-name>Inscription</ejb-name>
| | | </ejb-class> | | | | <method-name>enregistre</method-name>
| | | <session-type>Stateful</session-type> | | | </method>
| | | <transaction-type>Container | | | <trans-attribute>Required</trans-attribute>
| | | </transaction-type> | | </container-transaction>
| | | <ejb-ref> | </assembly-descriptor>
| | | | <description>Entité </ejb-jar>
| | | | Participant</description>

© 2003, P. Déchamboux ICAR’03 51

 Composants EJB « entité »

■ Manipulation par méthodes « métier »

◆ Accès local (interfaces « local » et « local home »)
◆ Accès distant à travers RMI (interfaces « remote » et « remote home »)

■ Composants représentant des données des bases

d’informations de l’entreprise
◆ Partagés
◆ Réentrant ou non (spécifiée au déploiement)

■ Propriété de persistance
◆ Gérée par l’application (BMP)
◆ Gérée par le « container » (CMP 1.1 ou 2.0)

© 2003, P. Déchamboux ICAR’03 52

 Cycle de vie d’un « entité »

N’existe pas

1. newInstance 1. unsetEntityContext
2. setEntityContext

1. create
A l’initiative 2. ejbCreate
du container /
1. ejbActivate
Opération sur « Home »
Prêt Tamponné
Opération sur instance
1. remove
2. ejbRemove
/
1. ejbPassivate Équivalent d’un cache BD
1. methode 1. find… (SWAP possible sur la BD)
/ 2. ejbFind…
A l’initiative
1. ejbLoad /
du container
/ 1. methode home
1. ejbStore

© 2003, P. Déchamboux ICAR’03 53

 Modèle de persistance des EJB entité

■ Notion de « clé primaire » Serveur J2EE

◆ Nom persistant
Instance de
◆ Désignation de l’instance BD composant
◆ Définie par une classe
❖ De base (String, Integer, …)
❖ Composite = {champs de
l’instance} ejbCreate
■ Notion de « finder » ejbRemove Clé Primaire ejbLoad
ejbStore
◆ Définit par une interface « home »
◆ Retourne une instance ou une
collection d’instances Base de
◆ BMP => ejbFinder (retourne une Données
instance ou une collection Instance BD
d’instances de clé primaire)

© 2003, P. Déchamboux ICAR’03 54

 Spécificités du modèle de
persistance « CMP 2.0 » (1)

■ Modèle non transparent

■ Accès aux champs persistants
◆ Différent par rapport aux champs standards
◆ Utilisation du patron « accesseur »
◆ Accès à champ => méthodes getChamp / setChamp abstraites
(implantées par le container)

■ Pas de persistance par rattachement (cf. JDO)

■ « finders » définit par requêtes EJBQL
◆ Langage proche d’OQL (cf. ODMG)
◆ Bientôt toute la puissance de SQL !!

© 2003, P. Déchamboux ICAR’03 55

 Spécificités du modèle de
persistance « CMP 2.0 » (2)

■ Définition de relations entre instances de

composants persistants
◆ Navigation transparente à travers « accesseurs »
◆ Cardinalité 1-1 ou 1-n
◆ Uni-directionnelle ou bi-directionnelle

■ Possibilité de détruire de façon transitive (« cascade

delete »)

© 2003, P. Déchamboux ICAR’03 56

 Exemple d’un composant entité :
« Participant » (interfaces)

interface Participant extends EJBLocalObject {

void setInfoParticipant(InfoParticipant ip);
}

interface ParticipantHome extends EJBLocalHome {

Participant create(String nom, String coord) throws CreateException;
Participant findByPrimaryKey(String nom) throws FinderException;
java.util.Collection findSomeParticipants(int statut) throws FinderException;
}

© 2003, P. Déchamboux ICAR’03 57

 Exemple d’un composant entité :
« Participant » (implantation - 1)

abstract class ParticipantBean implements EntityBean {

void setEntityContext(EntityContext c) {}
void ejbActivate() {}
void ejbPassivate() {}
void ejbLoad() {}
void ejbStore() {}
void ejbRemove() {}
abstract String getNom();
abstract void setNom(String val);
abstract String getCoordonnees(); Définition de l’état
abstract void setCoordonnees(String val); abstrait => champs nom,
abstract int getStatut(); coordonnees, statut
abstract void setStatut(int val);
static final int PREINSCRIT = 1;
static final int FACTURE = 2;
static final int INSCRIT = 3;

© 2003, P. Déchamboux ICAR’03 58

 Exemple d’un composant entité :
« Participant » (implantation - 2)

void ejbCreate(String nom, String coord) {

setNom(nom);
setCoordonnees(coord); Implantation des méthodes
setStatut(PREINSCRIT); de « local home »
}
void ejbPostCreate(String nom) {}
void setInfoParticipant(InfoParticipant ip) {
ip.nom = getNom();
ip.coordonnees = getCoordonnees();
switch (getStatut()) {
case :
Implantation
ip.statut = "Participant pré-inscrit"; break; des
case : méthodes de
ip.statut = "Participant facturé"; break; « local »
case :
ip.statut = "Participant inscrit"; break;
}
}
}

© 2003, P. Déchamboux ICAR’03 59

 Description du composant entité
« Participant »

<ejb-jar> | | | <cmp-field>
| <description>Entites ICAR</description> | | | | <field-name>coordonnees</field-name>
| <display-name>Entites ICAR</display-name> | | | </cmp-field>
| <enterprise-beans> | | | <cmp-field>
| | | | <field-name>statut</field-name>
| | <entity>
| | | </cmp-field>
| | | <ejb-name>Participant</ejb-name>
| | | <primkey-field>nom</primkey-field>
| | | <local-home>org.icar.api.ParticipantHome
| | | <query>
| | | </local-home>
| | | | <query-method>
| | | <local>org.icar.api.Participant | | | | | <method-name>findSomeParticipants
| | | </local> | | | | | </method-name>
| | | <ejb-class>org.icar.lib.ParticipantBean | | | | | <method-params>
| | | </ejb-class> | | | | | | <method-param>int
| | | <persistence-type>Container | | | | | | </method-param>
| | | </persistence-type> | | | | | </method-params>
| | | <primary-key-class>java.lang.String | | | | </query-method>
| | | </primary-key-class> | | | | <ejb-ql>SELECT OBJECT(p)
| | | | FROM participantsIcar p
| | | <reentrant>True<reentrant>
| | | | WHERE p.statut = ?1
| | | <cmp-version>2.x<cmp-version>
| | | | </ejb-ql>
| | | <abstract-schema-name>participantsIcar
| | | </query>
| | | </abstract-schema-name>
| | </entity>
| | | <cmp-field> | </enterprise-beans>
| | | | <field-name>nom</field-name> </ejb-jar>
| | | </cmp-field>

© 2003, P. Déchamboux ICAR’03 60

 Composants EJB « orientés
message »

■ Manipulation par le « container »

◆ Réaction sur réception de message
◆ Manipulation purement locale

■ Composants anonymes
■ Non réentrants
■ Réaction transactionnelle ou non
■ Lien avec une destination JMS
◆ Agissent comme des MessageListener
❖ Pour une Queue
❖ Pour un Topic

© 2003, P. Déchamboux ICAR’03 61

 Cycle de vie d’un « orienté
message »

N’existe pas A l’initiative du

container

1. newInstance
2. setMessageDrivenContext 1. ejbRemove
3. ejbCreate

Prêt
Opération sur instance

ATTENTION :
Appel non réentrant !!
1. onMessage(msg)

© 2003, P. Déchamboux ICAR’03 62

 Exemple d’un composant orienté
message : « ProcessusInscription »

class ProcInscrBean implements MessageDrivenBean, MessageListener {

private InternetAddress[] adrSecretariatICAR;
private javax.mail.Session mailSession;
void setMessageDrivenContext(MessageDrivenContext c) {}
void ejbRemove() {}
void onMessage(Message msg) {
javax.mail.Message message = new MimeMessage(mailSession);
message.setRecipients(Message.RecipientType.TO, adrSecretariatICAR);
message.setSubject("EffectuerInscription");
message.setContent(((TextMessage) msg).getText(), "text/plain");
javax.mail.Transport.send(message);
}
void ejbCreate() {
mailSession = (Session)initialContext.lookup("java:comp/env/mail/MailSession");
String adr = (String)initialContext.lookup("java:comp/env/AdrSecretariat");
adrSecretariatICAR = new InternetAddress[] {new InternetAddress(adr)};
}
}

© 2003, P. Déchamboux ICAR’03 63

 Description du composant orienté
message « ProcessusInscription »

<ejb-jar>
| <description>Sessions ICAR</description>
| <display-name>Sessions ICAR</display-name>
| <enterprise-beans>
| | <message-driven>
| | | <ejb-name>ProcessInscription</ejb-name>
| | | <ejb-class>org.icar.lib.ProcInscrBean
| | | </ejb-class>
| | | <session-type>Stateful</session-type>
| | | <transaction-type>Container
| | | </transaction-type>
| | | <acknowledge-mode>Auto-acknoledge
| | | </acknowledge-mode>
| | | <message-driven-destination>
| | | | <subscription-durability>NonDurable
| | | | </subscription-durability>
| | | | <destination-type>javax.jms.Queue
| | | | </destination-type>
| | | </message-driven-destination>
| | | <env-entry>
| | | | <env-entry-name>adrSecretariat
| | | | </env-entry-name>
| | | | <env-entry-type>java.lang.String
| | | | </env-entry-type>
| | | | <env-entry-value>icar03@inrialpes.fr
| | | | </env-entry-value>
| | | </env-entry>
| | | <resource-ref>
| | | | <resource-ref-name>mail/MailSession
| | | | </resource-ref-name>
| | | | <res-type>javax.mail.Session
| | | | </res-type>
| | | | <res-auth>Container</res-auth>
| | | </resource-ref>
| | </message-driven>
| </enterprise-beans>
| <assembly-descriptor>
| | <container-transaction>
| | | <method>
| | | | <ejb-name>ProcessInscription</ejb-name>
| | | | <method-name>*</method-name>
| | | </method>
| | | <trans-attribute>Required</trans-attribute>
| | </container-transaction>
| </assembly-descriptor>
</ejb-jar>

© 2003, P. Déchamboux ICAR’03 64

 Packaging & Déploiement

© 2003, P. Déchamboux ICAR’03 65

 Formats de packaging

■ Application J2EE (agrégation de différents tiers)

◆ Fichier « *.ear » + descripteur « application.xml »
■ Tiers client
◆ Web : fichier « *.war » + descripteur « web.xml »
◆ Application client : fichier « *.jar » + descripteur « application-
client.xml » (lancement du main de la classe spécifiée dans le
« manifest » (attribut « Main-Class »))
■ Tiers EJB
◆ Fichier « *.jar » + descripteur « ejb-jar.xml »
■ Tiers « EIS » (connecteurs)
◆ Fichier « *.rar » + descripteur « rar.xml »

© 2003, P. Déchamboux ICAR’03 66

 Déploiement de packages

■ Déploiement d’application
ClassLoader serveur J2EE
◆ De packages de tiers
ClassLoader EAR
uniquement (application Web
uniquement, EJB uniquement, ClassLoader EJB
etc) ClassLoader Web
◆ De packages « ear »
■ Chargement dans un
ClassLoader spécifique (par
application déployée)
■ Hiérarchisation des
ClassLoader lors du
déploiement d’un « ear »

© 2003, P. Déchamboux ICAR’03 67

 Conclusion

■ Vers une stabilisation des spécifications

◆ Capitalisation importante sur Corba
◆ Support XML / Web Services (J2EE 1.4 = 1000 pages de « tutorial »)
◆ Quelques extensions aux EJB : QL et échéancier (« batchs »)

■ Problèmes de maturité
◆ Persistance (co-existance avec JDO)
◆ Modèle de composants (manque d’homogénéité, problème avec
gestion de l’héritage)

■ La solution industrielle la plus aboutie

◆ Niveaux d’indépendance (HW, OS, SGBD, DTP, etc)
◆ Spectre fonctionnel très large

© 2003, P. Déchamboux ICAR’03 68