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 2
Cycle de vie Les EJB sont gérés par le containers Création, destruction, etc. Quels sont les états possibles? Quelle prise a-t-on sur les transitions? 3
Cycle de vie : Session Stateless Does not exist @PreDestroy Class.newInstance() Injections Method-ready @PostConstruct 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 Does not exist Exception système Class.newInstance() timeout timeout @PreDestroy Injections @PostConstruct Method-ready @PrePassivate @PostActivate Passivé Méthode métier
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 @PreDestroy Class.newInstance() Injections Method-ready @PostConstruct pool Méthode métier 17
Plan Cycle de vie et callbacks Intercepteurs Transactions et sécurité 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(); // La méthode interceptée (reflection) public Object [] getparameters(); // Les paramètres de la méthode public void setparameters(object [] params); // Modif des paramètres public EJBContext getejbcontext (); public java.util.map getcontextdata(); // Contexte de l EJB // 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 Transactions et sécurité 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 RequiresNew Supports Mandatory 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 : @TransactionAttribute(TYPE) Par 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 distinct
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 java.rmi.remoteexception, sinon il exécute la méthode hors transaction
Attributs autorisés suivant type d EJB
Sécurité sous J2EE Trois niveaux de sécurité pour 1 appli : Authentification Pas spécifié, mais faisable Contrôle d accès 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 Transactions et sécurité 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?