340 likes | 491 Views
Chapitre 3 Couche Métier : Le nouveau standard EJB 3.0. Sommaire. Introduction à la spécification EJB 3.0 Les Session Beans Entity Beans/JPA RelationShips Héritage EntityManager Message Driven Beans/JMS EJB Design Patterns. Objectifs des EJB. Un standard pour
E N D
Sommaire • Introduction à la spécification EJB 3.0 • Les Session Beans • Entity Beans/JPA • RelationShips • Héritage • EntityManager • Message Driven Beans/JMS • EJB Design Patterns
Objectifs des EJB • Un standard pour • un modèle de composant logiciel distribué, • implémenter des "objets métier" d'une manière propre et réutilisable, • faciliter le développement RAD d'applications côté serveur • Objectifs de l'architecture EJB • Au niveau développement : • Simplifier la tâche des développeurs de composants métier en leur déchargent de la gestion du système (transactions, persistence, erreurs, networking, …) • Au niveau déploiement • Permettre de déployer les composants sur des environnements conteneurs différents sans aucune recompilation de code • Au niveau exploitation • Cette organisation modulaire simplifie la maintenance et l'évolutivité d'une application. • Les EJBs sont en général recommandés lorsque: • Gestion des montées en charge • La gestion des transactions • Accessibilité par divers clients • Co-développement
Historique • Un peu d'histoire … • 1998 : EJB 1.0 Session Bean • 1999: EJB 1.1 : Entity Bean, Descripteurs de déploiement • 2001 : EJB 2.0 : Local Interfaces, Relationships, EJB-QL, MDBs • 2003 : EJB 2.1 : Webb Services, EJB-QL amélioré, Timer Service • EJB 2.1 : Beaucoup d'interfaces, complexité des descripteurs XML, problèmes des entités, test outside container • EJB 3.0 vs Spring +Hibernate !!! • Sur les forums de développement • "Pourquoi appeler cela EJB 3.0 alors que ca ressemble juste à un conteneur léger + framework de persistence ?" • "Intéressant, j'étais sur le point de melancer dans Spring + Hibernate, ça fait réfléchir …"
Annotation des métadonnées Prise en charge des valeurs par default Injection des dépendances Simplification des Beans (proche des POJO) EJBObject, EJBLocalObject, or java.rmi.Remote Home Simplification des CMP Héritage & polymorphisme Annotation du mappage O/R … EJB 3.0 : Nouveautés
Concurrence Transaction (atomicité) Persistance(JPA) Object Distribués (RMI-IIOP/SOAP1.2 [JAX-RPC]) Messagerie asynchrone (JMS) EJB Time Service Nommage (JNDI) Sécurité(Authentification/Autorisation/Sécurité des communications) Interopérabilité Spécification EJB 3, Services desupport
POJO + POJI L’interface home est optionnelle Les méthodes de Callback sont optionnelles Les annotations: Type du Bean, @Stateless, @Stateful, @Remote, @Local, @WebService Attribut de la transaction @Transaction Injection de dependence @Inject, @EJB, @Resource Les Beans de Session
@WebService : exposer un Session Bean comme étant un service Web Bénéficier des avantages des EJB Session: Persistence, Transaction, Sécurité… @WebMethod : expose une méthode dans le web service. @WebResult,@WebParam : paramètres et retour Simplicité d’implémentation: @WebResult, @WebParam, @WebMethod sont facultatives Les beans de Session et Web Services
Spécification supplémentaire: JPA 1.0 POJO + Persistence. Interface Home non requis. Supporte l’héritage et le polymorphisme. Peut être utilisé en dehors du Container. Les Annotations des Metedata du mappage O/R. Les Beans Entité
@Entity : Déclarer un Entity Mappage des Tables: @Table, @SecondaryTable. Mappage des colonnes: @Column, @JoinColumn Clé Primaire @Id. Les objets @Embedded Les Beans Entité : Les annotations
7 types de Relations: @OneToOne, @OneToMany, @ManyToOne, @ManyToMany. (Unidirectional ou bien bidirectional) MétaData: Les Relations entre Entités
Mise en Cascade: exemple: Meta Data : Les Relations entre Entités
Exemple Les Relations entre Entités
Suite Exemple… Les Relations entre Entités
3 types d’héritage(persistant) : Table Unique Jointure des Tables Table par classe Super classe (abstraite ou non): @Inheritance(strategy=InheritanceType.(SINGLE_TABLE | JOINED | TABLE_PER_CLASS) ) @DiscriminatorColumn(name="USER_TYPE“,discriminatorType=STRING, length=1) @DiscriminatorValue(value="S“) Fils (extends SuperClassName) @DiscriminatorValue(value="S") @PrimaryKeyJoinColumn(name="USER_ID") Héritage
Héritage SINGLE_TABLE JOINED TABLE_PER_CLASS
Maintenant que les entités sont devenues des POJOs Qui va s’occuper de la persistance ? Solution : Injection d'un Manager (Pattern IoC !) Injection d'un manager !
C’est notre point d’entrée dans le monde de la persistance avec ces méthodes de CRUD. Il gère le cycle de vie des entités Le Entity Manager
L’EntityManager fait appel au contexte de persistance qui gère les entité dans un contexte transactionnel C’est à l’ intérieur du contexte que les entités managées résident. Dès qu’elles en sortent elle deviennent détachées. Or le contexte est transactionnel, donc dès qu’une transaction se termine le contexte est détruit et les entités sont détachées Entity Manager : Contexte de persistance
2 types de contexte de persistance(scope) Transaction-scoped Pris par default si la persistance est gérée par le conteneur. Extended-scoped A utiliser avec les beans statefull. Le contexte de persistance existera tant que le contexte de session existe. Entity Manager : Contexte de persistance
Comment obtenir l’ EntityManager Injection de l’EM : le cycle de vie de l’EM ainsi que son contexte sera géré par le conteneur JEE A travers l’ EntityManagerFactory : on sera responsable du cycle de vie de l’EM Pour l’EMF on peut faire une injection (in container) ou par look up (JSE). Entity Manager : Contexte de persistance
Principe du service de messagerie JMS Les Beans Message (MDB)/JMS
2 modèles : Point-to-point /Queue Publisher–Subscriber /Topic Le service JMS
Comment utiliser le service? Le service JMS
Créer une destination Descripteur de déploiement JBoss:«deploy/jms/jbossmq-destinations-service.xml» A partir de la console du Serveur Le service JMS
C’est Bean stateless qui écoute une destination JMS. Bean MDB
Création: @MessageDriven Il a besoin d’un certain nombre de paramètres pour configurer sa connexion Destination (nom JNDI) Type de la destination (queue ou topic) Mode d’acquittement Filtre de message (messageSelector) Bean MDB
Envoyer des messages a partir d’un MDB ou d’un Bean de session: Faire comme si on envoyer a partir d’un client JMS Pour les ressources on peut les injectés @Resource(mappedName="QueueConnectionFactory") ConnectionFactory connectionFactory; @Resource(mappedName="queue/examples/OurSampleQueue") Queue queue; Bean MDB
JTA Spécification JEE API offrant un support des transactions distribuées Garantie la atomicité UserTransaction : begin, commit, rollback, … Les EJB supportent la JTA et l’utilisent par défault CMT (par défault) BMT :l’utilisateur définit ces transactions JTA @TransactionManagement(TransactionManagementType.BEAN) Transactions/JTA
Les beans de session supportent 6 types de démarcation CMT: MANDATORY REQUIRED (par default) REQUIRES_NEW SUPPORTS NOT_ SUPPORTED NEVER @TransactionAttribute(TransactionAttributeType.SUPPORTS) CMT
Les entités ne supportent pas les transactions mais, comme on l’a déjà dit, le contexte de persistance lui supporte et gère les transaction JTA et non JTA Tant qu’on est dans le conteneur c’est le mode JTA qui prime Le mode non JTA (resource-Local transaction) fonctionne en dehors du conteneurs , il a l’avantage d’etre plus rapide. CMT
DTO Les EJB Design patterns
EAO: Entity Access Object (EAO) consiste à séparer la logique d’accès au données de l’entity et la logique métier. Il permet de modifier facilement le code de l’entité sans affecter la logique métier. DAO et EAO sont des variations du même pattern. Les EJB Design patterns
Session façade Les EJB Design patterns