1 / 52

Les EJB session

Les EJB session. Marc Le Bihan. Plan. Objets métiers, persistance et services. Un serveur dédié aux services: le serveur d’application. L’EJB sans état (Stateless Bean). Le déploiement dans un serveur d’application. Le client d’un serveur d’application. L’EJB avec état (Stateful Bean).

jeneil
Download Presentation

Les EJB session

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Les EJB session Marc Le Bihan Les EJB session

  2. Plan • Objets métiers, persistance et services. • Un serveur dédié aux services: le serveur d’application. • L’EJB sans état (Stateless Bean). • Le déploiement dans un serveur d’application. • Le client d’un serveur d’application. • L’EJB avec état (Stateful Bean). • Les transactions. Les EJB session

  3. Les intervenants côté serveur • Les objets métiers. Notions métiers partageables par tous. • Les fournisseurs d’objets: DAO. Comment un objet se place sur un support. • Les services proposés par le serveur. Ce que nous annonçons (aux clients, aux autres serveurs) savoir faire, sous conditions. Les EJB session

  4. Les objets métiers • Représentent tous les éléments qu’un utilisateur a l’habitude de manipuler. dans le cadre des problèmes qu’il a résoudre. Ces éléments sont supposés représenter des éléments du monde réel. • N’existent qu’en mémoire vive. tant qu’un DAO ne les a pas placés sur un support physique. Les EJB session

  5. Les fournisseurs d’objets: DAO • Savent comment un objet se sérialise/désérialise sur un support physique. • Masquent la nature du support physique à ceux qui l’emploient. • Ne connaissent pas le problème métier. ils font ce qu’on leur dit de faire (en respectant des relations, des contraintes) sans savoir pourquoi ils le font. Les EJB session

  6. La restriction d’accès à des cas d’utilisation • Si on laissait un client disposer librement de DAOs, il pourrait virtuellement produire n’importe quoi. • Une restriction est donc faite à des cas d’utilisation. qui disent dans quels contextes un demandeur peut se voir servi. Ils représentent des situations métiers où un acteur est appelé à faire quelque-chose. Les EJB session

  7. Service, services, et cas d’utilisation • Dans une entreprise, on se rend au service du personnel pour demander son solde de congés, pour en poser.A un service (celui du personnel) on demande un des services qu’il sait rendre: double soldeConges(EmployeId id) void poserConges(EmployeId id, double nombre) throwsSoldeInsuffisantException On demande la résolution d’un cas d’utilisation. Les EJB session

  8. Un service Répond à un cas d’utilisation. Pour cela, il: • S’assure du respect de règles de gestion. conditions => assertions, exceptions métiers. Et met alors en œuvre son savoir faire, en: • faisant agir des fournisseurs d’objets (DAOs). • Faisant interagir des objets métiers. • Joignant d’autres services. Les EJB session

  9. Un serveur dédié aux services (1/3) • Aujourd’hui, un serveur RMI peut posséder des objets prenant en charge des cas d’utilisation, qu’il met à disposition de clients. • Mais:- Problème de gestion fine des droits d’accès.- Création d’objets et récupération de mémoire.- Répartition de charge entre serveurs. - Le serveur RMI est vide. Il faut le compléter avec toutes sortes d’API. Les EJB session

  10. Un serveur dédiéaux services (2/3) • Un autre type de serveur a été conçu, pour répondre ces problèmes. Le serveur d’application. Il se destine à recevoir l’implémentation des cas d’utilisation auxquels nous déclarons savoir répondre. Les EJB session

  11. Un serveur dédié aux services (3/3) • De la même façon qu’un serveur web est accompagné d’API supportant les servlets et les JSP • Le serveur d’application a les siennes. Il répond à la norme J2EE. JTA, Java mail, JDBC, XML… et également: servlets, JSP. Les EJB session

  12. Il ressemble à un serveur RMI (1/2) • Comme pour un obtenir un objet d’un serveur RMI, nous – client – allons joindre un annuaire. • L’objet obtenu nous sera présenté par son interface, comme ce serait le cas pour un serveur RMI. Les EJB session

  13. Il ressemble à un serveur RMI (2/2) Mais à l’inverse d’un serveur RMI, qui admet que tout objet soit placé sous sa garde, Le serveur d’application, n’admet que des objets de quatre types. Les EJB session

  14. Les EJB Ces objets admis dans le serveur portent le nom d’Enterprise Java Beans (EJB). • Stateless Bean: ne conserve pas d’état et est invoqué de façon synchrone. • Stateful Bean: conserve un état et est appelé de manière synchrone. • Message Bean: connecté à une file d’attente de messages, il est invoqué de manière asynchrone. • Entity Bean: … Représentation d’une sérialisation sur un support physique: entity, DTO. Les EJB session

  15. L’interface du service RMI Est transmise au client pour employer l’objet mis en partage. publicinterface ServiceDuPersonnelRemote extendsRemote { double soldeConges(EmployeId id) throws EmployeInexistantException, RemoteException; void poserConges(EmployeId id, double nombre) throws SoldeInsuffisantException, RemoteException; } Les EJB session

  16. L’interface du service EJB (1/2) Le client va s’en servir pour employer le fonctions proposées par notre service, De la même manière que pour RMI, elle reprend les prototypes des méthodes métier mises à disposition. Les EJB session

  17. L’interface du service EJB (2/2) @Remote publicinterface ServiceDuPersonnelService { double soldeConges(EmployeId id) throws EmployeInexistantException; void poserConges(EmployeId id, double nombre) throws SoldeInsuffisantException; } Les EJB session

  18. L’implémentation d’unservice RMI côté serveur Nous demande ceci: public class ServiceDuPersonnel extends UnicastRemoteObject { ServiceDuPersonnel() throws RemoteException {} double soldeConges(EmployeId id) throws EmployeInexistantException { … } Les EJB session

  19. L’implémentation d’un EJB sans état. @Stateless public class ServiceDuPersonnelBean implements ServiceDuPersonnelService { // Les cas d’utilisations que nous proposons public double soldeConges(EmployeId id) throws EmployeInexistantException{ …} } Les EJB session

  20. L’EJB sans état (Stateless bean) Parce qu’il est sans état, le stateless bean ne devrait pas comporter de variables membres, sinon en considérant ceci: • Elles ont des chances de ne plus avoir de contenu à l’appel suivant. • et il y a un risque qu’elles aient encore le contenu qu’elles avaient à l’appel précédent. Les EJB session

  21. L’EJB sans état peut être initialisé • Il reste possible de procéder à son initialisation dans une méthode porteuse de l’annotation @PostConstruct • Et un équivalent « destructeur » pourra être défini dans une méthode annotée @PreDestroy Les EJB session

  22. Client Serveur Application RMI L’implémentation des cas d’utilisation de notre service Ce que le client finira par utiliser Client Serveur Les EJB session Application J2EE

  23. Client Serveur • Inexploitable encore, car: • Les serveurs n’ont pas encore pris en compte ces services.Comment les leur déclarer? • Les serveurs doivent placer des entrées dans l’annuaire, permettant d’obtenir ces services. • Quand ils existeront, ils seront accessibles aux clients au travers de l’annuaire.Comment s’adresser à celui-ci? Application RMI L’implémentation des cas d’utilisation de notre service Ce que le client finira par utiliser Client Serveur Les EJB session Application J2EE

  24. La création par le serveur RMI d’un objet et sa mise à disposition • Dans un serveur RMI, la prise en compte d’un service et son enregistrement dans l’annuaire, se fait par une instruction: Naming.rebind("ServiceDuPersonnel", new ServiceDuPersonnel()); Elle est prise en compte au lancement du serveur, lorsqu’il Exécute la méthode main() de d’une classe RegisterServices. • Mais il ne met à disposition qu’un seul objet. • Un seul choix de constructeur sera possible. Les EJB session

  25. La création par le serveur d’application d’un objet L’annuaire remet une interface de service également. Mais son implémentation sous-jacente décide elle-même de la création ou non de nouveaux objets. Les EJB session

  26. EJBServiceDuPersonnel.jar ServiceDuPersonnel-client.jar L’empaquetage de l’EJB (1/2) • Le Bean de l’EJB et son interface de service sont rassemblés dans un jar pour le serveur. • L’interface de service est reprise aussi dans un jar destiné aux clients. Les EJB session

  27. L’empaquetage de l’EJB (2/2) Mais attention, dans ce jar ne se trouvent que l’EJB et ses déclarations. Pour fonctionner, il devra s’intégrer à un environnement qui comprendra typiquement: • les objets métiers partagés. • des librairies utilitaires. … Les EJB session

  28. Un environnement pour le serveur d’application (ear) Il réclame: • De dresser une liste des modules (jar, war…) à mettre en ligne dans un descripteur. • Et de rassembler ce descripteur et les modules qu’il énumère dans un fichier d’extension ear. Les EJB session

  29. Un environnement pour le serveur d’application (ear) (1/2) <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE ...> <application> <display-name>Mon entreprise</display-name> <description>Mon entreprise.</description> <!-- Objets métiers --> <module> <java>objetsMetiers.jar</java> </module> <!-- Service du personnel --> <module> <ejb>EJBServiceDuPersonnel.jar</ejb> </module> </application> META-INF/application.xml Les EJB session

  30. MonEntreprise.ear Un environnement pour le serveur d’application (ear) (2/2) Nous constituons un fichier ear pour rassembler les modules et leur descripteur. Il sera copié dans le répertoire de déploiement du serveur d’application Les EJB session

  31. L’empaquetage de RMI On peut de la même manière que pour EJBServiceDuPersonnel.jar rassembler l’implémentation du service RMI et son stub dans: RMIServiceDuPersonnel.jar Les EJB session

  32. Un environnement pour RMI Mais c’est la composition du classpath au lancement de rmiregistry qui décidera de ce qu’il verra en ligne ou non. (Dans un serveur d’application, c’est application.xml qui sert d’équivalent classpath.) Les EJB session

  33. Client Serveur Annuaire de Rmiregistry Stubs classpath + jars Application RMI Client Annuaire JNDI Serveur application.xml "<ear>/<ejb>/[remote|local] " "MonApplication/ServiceDuPersonnelBean/remote" MonApplication.ear Les EJB session Application J2EE

  34. Contrôle du bon déploiement • Une fois l’ear placé dans le répertoire de déploiement, et le serveur lancé. • Aller sur http://localhost:8080/jmx-console • Sélectionner le service JNDIView • Appeler la fonction list() Et contrôler la présence de l’EJB dans l’annuaire. Les EJB session

  35. Client d’EJB: adresser l’annuaire (1/3) Une application cliente du serveur d’application, va pour lui réclamer un service: • Joindre son annuaire, en donnant l’emplacement où le trouver. • Demander l’interface du service souhaité à cet annuaire grâce à son nom<ear>/<ejb>/[remote|local] Les EJB session

  36. Client d’EJB: adresser l’annuaire (2/3) Avant de rechercher quelque-chose dans l’annuaire JNDI, il faut indiquer où cet annuaire se trouve: • Soit en définissant les propriétés: - java.naming.provider.url - java.naming.factory.initial - java.naming.factory.url.pkgs • Soit en fournissant un fichier jndi.properties, présent dans le classpath du client. Les EJB session

  37. Client d’EJB: adresser l’annuaire (3/3) java.naming.provider.url= jnp://localhost:1099 java.naming.factory.initial= org.jnp.interfaces.NamingContextFactory java.naming.factory.url.pkgs= org.jboss.naming:org.jnp.interfaces Les EJB session

  38. Client d’EJB: Réclamer le Service à l’annuaire public ServiceDuPersonnelService obtenirServiceDuPersonnel() throws NamingException { // Provoquer le chargement de jndi.properties qui déclare l’url // où trouver l’annuaire InitialContext ctx = new InitialContext(); // dans MonApplication.ear, je veux l’interface @Remote pour // accéder à l’EJB ServiceDuPersonnelBean. ServiceDuPersonnelService service = ctx.lookup("MonApplication/ServiceDuPersonnelBean/remote"); return(service); } Les EJB session

  39. Client d’EJB: Utiliser le service try { ServiceDuPersonnelService service = obtenirServiceDuPersonnel(); double dSolde = service.obtenirSoldeConge(monId); // Trois jours pour noël, si j'en ai plus de cinq. if (dSolde > 5) service.poserConges(monId,3); } catch(EmployeInexistantException e) { ... } Les EJB session

  40. Client d’EJB: jars JBoss requis • Pour joindre l’annuaire, connaître les interfaces de base des EJBs, et adhérer à quelques protocoles requis par JBoss, un client emploie des jars issus d’un répertoire de distribution pour clients: jbossall-client.jar Les EJB session

  41. Contraintes d’utilisation • Les objets qui circulent entre clients et serveurs doivent être sérialisables. (implements java.io.Serializable). • Un EJB ne devrait pas employer de threads. • Un EJB ne devrait pas avoir de variables statiques comme variables membres. Les EJB session

  42. L’EJB à état (Stateful bean) • A la différence de l’EJB sans état, il conserve d’un le contenu de ses variables membres d’un appel à l’autre.Il se lie au client qui l’a créé et ne sera partagé avec personne d’autre. • Il sera détruit après qu’une de ses méthodes annotée @Remove ait été appelée. • Le serveur peut lui demander de se préparer à être supprimé de la mémoire temporairement (en cas de manque de ressources) en appelant une méthode annotée @PrePassivate. • Il le restituera plus tard, et appellera une méthode annotée @PostActivate. Les EJB session

  43. @Stateful publicclass ServiceComptabiliteBean implements ServiceComptabilité { private NotesFrais m_notes; @PostConstructpublicvoid create() {m_notes = new NotesFrais(); } publicvoid declarerFrais(EmployeId id, TypeFrais type, double dMontant) { NoteFrais note = new NoteFrais(); note.setEmployeId(id); note.setTypeFrais(type); note.setMontant(dMontant); m_notes.ajouter(note); } @Removepublicdouble fraisTotaux() { return(m_notes.getMontantTotal()); } Les EJB session

  44. Le client de l’EJB à état ServiceComptabilite service = obtenirServiceComptabilité(); // Accumuler une série de frais. service.declarerFrais(monId, new TypeFrais(TypeFrais.REPAS), 15); service.declarerFrais(monId, new TypeFrais(TypeFrais.FOURNITURES), 8); service.declarerFrais(monId, new TypeFrais(TypeFrais.DEPLACEMENT), 4); // En prendre le total. double dTotal = service.fraisTotaux(); // Provoquera sa destruction avec: publicServiceComptabilite obtenirServiceComptabilité() throws NamingException {InitialContext ctx = new InitialContext(); ServiceComptabilité service = ctx.lookup("MonApplication/ServiceComptabilitelBean/remote");return(service); } Les EJB session

  45. Les transactions (1/8) Le morcellement d’un problème complexe en cas d’utilisation et la facilité d’invocation des services conduit à une composition de services fréquente. En vue de déménager(Date dateDéménagement),je réserve un jour de congé (EmployeurService)je réserve un véhicule utilitaire (LocationVéhiculeService)je préviens EDF (ElectricitéService)je préviens mon agence immobilière (AgenceService) Et voilà qu’un impondérable m’empêche de déménager… Les EJB session

  46. Les transactions (2/8) • Certains services pourront revenir totalement en arrière.- Soit parce qu’ils font quelque chose de complexe, susceptible d’échouer, et qu’ils s’estiment capables de prendre cette décision eux-mêmes.- Soit parce qu’ils acceptent qu’un appelant qui les joint les engagent dans leur propre transaction. • D’autres conserveront forcément des traces (numéro d’appel, frais « de réservation fût-elle abandonnée ensuite »). • D’autres voudront annoncer qu’ils sont incapables de revenir en arrière si c’était nécessaire. Et que quelqu’un qui les en croirait capables ne doit pas les joindre. Les EJB session

  47. Les transactions (3/8) C’est ainsi que les méthodes de service peuvent être qualifiées avec une annotation @TransactionAttribute qui précise le comportement du service lorsqu’il est joint ou composé avec d’autres. @TransactionAttribute(value=TransactionAttributeType.REQUIRED) S’intègre à une transaction existante, en débute une nouvelle sinon. C’est ce choix qui est fait si aucun autre n’est précisé. @TransactionAttribute(value=TransactionAttributeType.REQUIRES_NEW) Débute une nouvelle transaction systématiquement. @TransactionAttribute(value=TransactionAttributeType.MANDATORY) Une transaction doit déjà exister. Sinon, une exception est levée. Les EJB session

  48. Les transactions (4/8) @TransactionAttribute(value=TransactionAttributeType.SUPPORTS) S’intègrera à une transaction existante, mais ne pourra pas en débuter une s’il n’en n’existe pas. @TransactionAttribute(value=TransactionAttributeType.NOT_SUPPORTED) Ne sait pas s’intégrer à une transaction existante. Ne sait pas en débuter une. @TransactionAttribute(value=TransactionAttributeType.NEVER) N’accepte pas d’être dans une transaction, et lève une exception si une est en cours. Les EJB session

  49. Les transactions (5/8) Concrètement, les transactions agissent sur des connections fournies par les Datasources que le serveur d’application a sous sa garde. • Agir sur les connections pour débuter une transaction n’est pas nécessaire, le serveur d’application s’en charge. • Le commit advient de lui-même lorsque le service qui a débuté une transaction s’ est exécuté intégralement et a su composer avec d’autres services- Sans avoir reçu de notification d’abandon.- Sans s’être retrouvé dans une situation d’annulation. Les EJB session

  50. Les transactions (6/8) De sorte que dans un service, on ne s’occupe que de notifier les situations de rollback. • Les exceptions Systèmes:sur initiative du serveur d’application et dans des situations « sévères ». Les exceptions issues de RuntimeException, RemoteException, et EJBException. Ce sont des exceptions système qu’il n’est pas attendu que nous levions nous-mêmes. Les EJB session

More Related