Entreprise Java Beans

Transcription

Java Enterprise Edition
EJB3 / Troisième partie
Matthieu EXBRAYAT
Master 2 RIA
Université Louis Pasteur
1
Plan
Cycle
de vie et callbacks
Intercepteurs
Transactions et sécurité
Timers
EJB et Java EE – Matthieu EXBRAYAT – Master 2 RIA / ULP 2007
2
Cycle de vie
Les
EJB sont gérés par le containers
Création,
Quels
Quelle
destruction, etc.
sont les états possibles?
prise a-t-on sur les transitions ?
3
Cycle de vie : Session Stateless
Does not exist
Class.newInstance()
@PreDestroy
Injections
@PostConstruct
Method-ready
pool
Méthode métier
4
Notion de callback

Des opérations peuvent être nécessaires lors des
transitions


Dans les versions antérieures

Une méthode par type de transition

Imposée et souvent vide
Avec les EJB3 (grâce à Java 5)

Utilisation de tags

callback
Organisation d’un callback

@TypeCallBack
methodeDeCallBack() { …}

Le nom de la méthode est choisi par le développeur

Elle est de type void, et sans paramètre, ne lève
d’exceptions contrôlées (nécessitant un try/catch)

Invocation par le container lors du changement d’état
Callbacks du Session Stateless
 @PostConstruct
 Initialisation
du bean, ne relevant pas du « new », ni
des ressources injectables
 Exemple
: socket, accès fichier, etc.
 @PreDestroy
 Permet
essentiellement de nettoyer ce qui a été
ouvert dans le PostConstruct
Pooling : exécution de méthode
Stub
Objet EJB
Contexte
Client
Instances
du bean
Pool
Pooling : invocation terminée
Stub
Objet EJB
Client
Pool
Cycle de vie : Session stateful
Exception système
Does not exist
timeout
Class.newInstance()
@PreDestroy
timeout
Injections
@PostConstruct
@PrePassivate
Method-ready
Méthode métier
@PostActivate
Passivé
Passivation

Pooling impossible

Comment gérer les ressources ?

Solution : stocker en mémoire secondaire (LRU)

Passivation

Stocke l’état conversationnel en mémoire secondaire et déréférence
l’instance

Activation

Recrée l’instance (et ses attributs) et reconnecte à l’objet EJB
Etat conversationnel
Contexte
Transaction
EM
et EMFactory
Références
aux ressources et EJB
(Attributs)
Etat prêt
Stub
Objet EJB
Contexte
Client
Instance
du bean
Etat passivé
Stub
Objet EJB
Client
État conversationnel
(et attributs)
Timeout et exceptions système


Timeout

déclarés au déploiement

Dépend du serveur d’application

Pas de timeout en cours de transaction

@PreDestroy pas obligatoire
Exceptions système

Pas de @PreDestroy
Cycle de vie : entity

En EJB3, lié aux interactions avec l’EM

@PrePersist

@PostPersist

@PostLoad (chargement et refresh)

@PreUpdate

@PostUpdate

@PreRemove

@PostRemove
Cycle de vie : MDB
Does not exist
Class.newInstance()
@PreDestroy
Injections
@PostConstruct
Method-ready
pool
Méthode métier
17
Plan
Cycle
de vie et callbacks
Intercepteurs
Timers
18
Intercepteurs

Les intercepteurs permettent d’effectuer des actions lors de
l’appel de diverses méthodes.

Permettent d’enrichir la gestion des beans au niveau du
container

Appel global ou ciblé sur certaines méthodes

A quoi ça peut bien servir ? ...

Exemples ?
Intercepteurs


Ils peuvent être définis dans des classes séparées

@Interceptors({« classe1 », « classe2 »…})

Invocation dans cet ordre

@Interceptor (« classe1 »)
Ou directement dans la classe


@AroundInvoke
Exécution de la méthode : proceed
Exemple
@Stateful
public class CalculatorBean implements Calculator {
/ / Bean methods that are to be intercepted by "log()"
/ / ... ...
@AroundInvoke
public Object log (InvocationContext ctx)
throws Exception {
String className = ctx.getBean().getClass().getName();
String methodName = ctx.getMethod().getName();
String target = className + "." + methodName + "()";
long start = System.currentTimeMillis();
System.out.println ("Invoking " + target);
try {
return ctx.proceed();
} catch(Exception e) {
throw e;
} finally {
System.out.println("Exiting " + target);
cal.setTrace(cal.getTrace() + "Exiting " + target);
long time = System.currentTimeMillis() - start;
System.out.println("This method takes " + time + "ms to execute");
}
}
}
Méthodes du contexte d'invocation
public interface InvocationContext {
public Object getBean();
// Le bean qui est intercepté
public java.lang.reflect .Method getMethod();
public Object [] getParameters();
// La méthode interceptée (reflection)
// Les paramètres de la méthode
public void setParameters(Object [] params);
// Modif des paramètres
public EJBContext getEJBContext ();
// Contexte de l’EJB
public java.util.Map getContextData();
// permet de passer des infos
// entre méthodes d’interception (chaine d’interception)
public Object proceed() throws Exception;
// Exécution de la méthode interceptée
}
Entity Listeners
Pas
d'intercepteurs pour entities.
Classes
listeners associées aux callbacks
Méthodes
void avec entity en paramètre
@EntityListeners
Exemple (listener)
public class Logger {
@PostPersist void postInsert(Object entity) {
System.out.println(« Entity inséré : »+entity.getClass().getName();
}
}
Exemple (entity)
@Entity
@Listeners({Logger.class})
public class MaClasse {
...
@PostPersist void afterInsert() {
...
}
}
Plan
Cycle
de vie et callbacks
Intercepteurs
Timers
27
Les Transactions / Définition
 Une transaction est une série d’opération qui s’exécute dans une
même unité de travail
 Cette unité de travail respecte les principes suivants:
 Atomicité : toutes les ressources impliquées dans une transaction sont
« committées », ou aucune ne l’est
 Cohérence : soit la transaction réussit et les données sont valides à la fin, soit elle
échoue et les données retrouvent leur état – valide – initial
 Isolation : tout changement d’état dans une transaction non encore « committée »
est invisible de l’extérieur de la transaction
 Durabilité : les données « committées » le sont de telle façon que si le système
crashait, elles seraient restaurées au redémarrage
Les Transactions JTA
 Une transaction JTA (Java Transaction API) est gérée
par la plate-forme J2EE
 Elle peut inclure de multiples composants (servlets, JSP,
EJB, bases de données, etc) et propager le contexte
transactionnel de l’un à l’autre
 L’avantage est que cette propagation est complètement
transparente au programmeur
Les Transactions / JTA et JTS
 JTA est une API permettant l’accès à une gestion
transactionnel indépendamment de l’implémentation
 JTS spécifie l’implémentation de JTA et de l’OTS 1.1 de
l’OMG. Il propage les transactions via IIOP
 Les composants ne doivent pas interagir avec JTS mais
utiliser JTA et l’interface
javax.transaction.UserTransaction
Les Transactions JTA / Interface UserTransaction
Les Transactions / Interface Status
Les Transactions / Types de transactions
 Par programmation (bean managed)
C’est le développeur qui est responsable de la transaction
dans le bean (begin, commit, rollback…)
 Déclarative (Container-Managed Transaction)
C’est le container qui est responsable de la transaction
C’ est le mode obligatoire pour les Entity Bean
 Initialisée par le client
C’est le code client qui est responsable de la transaction
Les Transactions / Transaction par programmation
BMT

@TransactionManagement(TransactionManagerType.BEAN)

@Resource SessionContext ejbContext;

ejbContext.getUserTransaction();

ut.begin() / commit() / rollback()

Stateless : dans une méthode

Statefull : peut être sur plusieurs (attribut)
Les Transactions / Transaction déclarative
Transaction initialisée par le client
Container-Managed Transactions
 Pour chaque méthode métier du bean (ou pour la classe
entière), il faut spécifier un attribut de transaction
 Cet attribut précise le comportement transactionnel du bean
 Six valeurs possibles:
 Required
 Mandatory
RequiresNew
Supports
NotSupported
Never
 Cette spécification se fait par annotation (ou DD)
Concrètement...
Quand
commence une transaction ?
Quand
se finit-elle ?
Commit
ou rollback ?
Annotation
 Par
: @TransactionAttribute(TYPE)
classe et/ou par méthode
CMT

Required:
 Le bean s’exécute toujours dans une transaction
 Si une transaction est en cours, alors elle est utilisée, sinon une nouvelle
démarre
 Cet valeur d’attribut correspond à un fonctionnement logique dans la
plupart des cas
 RequiresNew
 Le container créé une nouvelle transaction à chaque fois que le bean est
appelé
 Si une transaction est en cours, alors le conteneur:
1. suspend cette transaction
2. en démarre une nouvelle
3. appelle la méthode
4. reprend la transaction originale après exécution
 Si aucune transaction n’est en cours, alors le conteneur en démarre une
nouvelle
 A utiliser si la méthode doit être exécutée dans un contexte transactionnel
EJB et Java EEdistinct
– Matthieu EXBRAYAT – Master 2 RIA / ULP 2007
CMT
 Supports:
 Si une transaction est en cours, alors le conteneur l’utilise, sinon exécute
l’appel sans en démarrer de nouvelle
 A utiliser avec précaution
 Mandatory
 Si une transaction est en cours, alors le conteneur l’utilise, sinon lance
une javax.ejb.TransactionRequiredException ou
javax.ejb.TransactionRequiredLocalException
 A utiliser si la méthode doit être exécutée dans le contexte transactionnel
du client
Container-Managed Transactions

NotSupported:
 Si une transaction est en cours, alors le conteneur la suspend, appelle la méthode
hors transaction et reprend la transaction du client
 Si aucune transaction n’est en cours, alors la méthode est exécutée hors
transaction
 A utiliser si la méthode n’a pas besoin de contexte transactionnel
 Peut augmenter les performances
 Never
 Si une transaction est en cours, alors le conteneur lance une
EJB et Java EE java.rmi.RemoteException,
– Matthieu EXBRAYAT – Master 2 RIA / ULPsinon
2007
il exécute la méthode hors transaction
Attributs autorisés suivant type d’EJB
Sécurité sous J2EE
 Trois

Authentification


Pas spécifié, mais faisable
Contrôle d’accès


niveaux de sécurité pour 1 appli :
Fourni par J2EE (identités, rôles…)
Communications sécurisées

Hors spéc, mais courant (ssl, https)
Identité de sécurité
 Un
client qui se connecte au serveur d’EJB est
associé à une identité de sécurité pour la durée
de la session.
 Une identité de sécurité = objet
java.security.Principal
 La gestion des identités incombe au serveur
d’application
 Rôle = groupe d’une ou plusieurs identités
 Accès aux ejb (et méthodes) suivant rôle de
sécurité.
Contrôle d’accès basé sur les rôles

Les droits d’accès sont gérés au niveau des annotations
(ou descripteurs de déploiement)

En entrée :security-role + method-permission : liste
des rôles reconnus et droits d’accès suivant ces rôles

En sortie : runAs : permet de redéfinir l’identité «
interne » de l’appelant (ou plus exactement de l’EJB).
Annotations bean
 @SecurityDomain
 Mode
de contrôle des rôles
 Exemple
: other = users.properties + roles.properties
 @RolesReferenced
 Liste
des rôles utilisés dans l'EJB
@RunAs
Comment le client s’identifie-t-il ?
 Client
« lourd » :

Identification lors du lookup

On transfère des propriétés : login et mot de passe
 Client

« léger »:
L’identification se fait lors de l’accès au servlet (par
exemple)

Spécifier ce qui est protégé (permet authentification), et qui
y a accès (permet contrôle)
Identification via jndi
Properties prop=new Properties();
prop.put(Context.SECURITY_PRINCIPAL,login);
prop.put(Context.SECURITY_CREDENTIALS,passwd);
javax.naming.Context jndiContext=new javax.naming.InitialContext(prop);
…jndiContext.lookup(« …. »);
Lors du lookup, les informations d’identification sont transférées
Identification depuis un client web
 On
définit les rôles et la méthode
d’authentification au niveau du descripteur de
déploiement web.xml
 Contrôle :

Dans jboss, plusieurs méthodes existent
Fichier login/password
 Base de données
 Annuaire ldap
…


Le plus simple (pour tester) :
Fichiers users.properties et roles.properties dans [/
…]/jboss…/server/…/conf
 Par exemple dans jboss…/server/default/conf

Exemple de fichiers simples d’authentification
 users.properties
 user1=passwd1
user2=passwd2
 roles.properties
 user1=admin
user2=guest
Plan
Cycle
de vie et callbacks
Intercepteurs
Timers
Timers... en bref
Il
existe un service Timer
Il
permet de définir une tâche à exécuter à
une date précise (timeOut)
Pour
en savoir plus : cf doc EJB3.0
Pour
des tâches répétitives ?

Entreprise Java Beans

Transcription

Documents pareils

Jonathan Weisberg

Formation perfectionnement

Développement J2EE

Rapport de projet

Offres d`emploi de Jobingé - Forum Entreprises JAVA DEVELOPER

Compte-Rendu sur les Enterprises Java Beans (EJB)

Biographie Matthieu de Boüard

EJB - Oxiane

Alice Champagne Ardenne FORUM JOBS 2004

Ingénieur d`étude et développement JAVA J2EE H/F