Java Enterprise Edition EJB3 / Troisième partie. Matthieu EXBRAYAT Master 2 RIA Université Louis Pasteur

Transcription

1 Java Enterprise Edition EJB3 / Troisième partie Matthieu EXBRAYAT Master 2 RIA Université Louis Pasteur 1

2 Plan Cycle de vie et callbacks Intercepteurs Transactions et sécurité Timers 2

3 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

4 Cycle de vie : Session Stateless Does not Class.newInstance() Injections pool Méthode métier 4

5 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

6 Organisation d un 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

7 Callbacks du Session Initialisation du bean, ne relevant pas du «new», ni des ressources injectables Exemple : socket, accès fichier, Permet essentiellement de nettoyer ce qui a été ouvert dans le PostConstruct

8 Pooling : exécution de méthode Stub Objet EJB Contexte Client Instances du bean Pool

9 Pooling : invocation terminée Stub Objet EJB Client Pool

10 Cycle de vie : Session stateful Does not exist Exception système Class.newInstance() timeout @PostActivate Passivé Méthode métier

11 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

12 Etat conversationnel Contexte Transaction EM et EMFactory Références aux ressources et EJB (Attributs)

13 Etat prêt Stub Objet EJB Contexte Client Instance du bean

14 Etat passivé Stub Objet EJB Client État conversationnel (et attributs)

15 Timeout et exceptions système Timeout déclarés au déploiement Dépend du serveur d application Pas de timeout en cours de pas obligatoire Exceptions système Pas

16 Cycle de vie : entity En EJB3, lié aux interactions avec @PostLoad (chargement

17 Cycle de vie : MDB Does not Class.newInstance() Injections pool Méthode métier 17

18 Plan Cycle de vie et callbacks Intercepteurs Transactions et sécurité Timers 18

19 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?

20 Intercepteurs Ils peuvent être définis dans des classes «classe2» }) Invocation dans cet («classe1») Ou directement dans la Exécution de la méthode : proceed

21 public class CalculatorBean implements Calculator { / / Bean methods that are to be intercepted by "log()" / 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);

22 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"); } } }

23 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 }

24 Entity Listeners Pas d'intercepteurs pour entities. Classes listeners associées aux callbacks Méthodes void avec entity en

25 Exemple (listener) public class Logger void postinsert(object entity) { System.out.println(«Entity inséré :»+entity.getclass().getname(); } }

26 public class MaClasse void afterinsert() {... } }

27 Plan Cycle de vie et callbacks Intercepteurs Transactions et sécurité Timers 27

28 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

29 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

30 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

31 Les Transactions JTA / Interface UserTransaction

32 Les Transactions / Interface Status

33 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

34 Les Transactions / Transaction par programmation

35 BMT SessionContext ejbcontext; ejbcontext.getusertransaction(); ut.begin() / commit() / rollback() Stateless : dans une méthode Statefull : peut être sur plusieurs (attribut)

36 Les Transactions / Transaction déclarative

37 Transaction initialisée par le client

38 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)

39 Concrètement... Quand commence une transaction? Quand se finit-elle? Commit ou rollback? Annotation Par classe et/ou par méthode

40 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

41 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

42 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

43 Attributs autorisés suivant type d EJB

44 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)

45 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é.

46 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).

47 Annotations Mode de contrôle des rôles Exemple : other = users.properties + Liste des rôles utilisés dans

48 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)

49 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

50 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

51 Exemple de fichiers simples d authentification users.properties user1=passwd1 user2=passwd2 roles.properties user1=admin user2=guest

52 Plan Cycle de vie et callbacks Intercepteurs Transactions et sécurité Timers

53 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?