Les composants Enterprise Java Beans

Document Sample
Les composants Enterprise Java Beans Powered By Docstoc
					Les composants
Enterprise Java
Beans

     ludovic.maitre@free.fr
Plan (1/3)
    Principe des beans
           Conserver l’état
           Agir sur des données partagées
           Participer à des transactions
           Handle sur des beans
           Clients distants
           Clients locaux
  Types de beans
  Interfaces
           Interface   Home
           Interface   Home locale
           Interface   Remote
           Interface   Locale
Plan (2/3)
    Règles de conception des beans
           Session
              –   Beans de session sans état (stateless session bean)
              –   Cycle de vie d’un bean de session sans état
              –   Beans de session avec état (stateful session beans)
              –   Cycle de vie d’un bean de session avec état
           Entités
              – La sérialisation
              – Cycle de vie d’un bean d’entité
    Implémenter et utiliser un bean
           Développement côté client
           Développement côté serveur
    Serveur d’EJB
Plan (3/3)
    Conteneurs d'EJB
           Fonctions du conteneur
              – Gestion de la persistance
              – Gestion des transactions
              – Gestion d’instances
    Connection aux ressources de l'entreprise
           Types d’objets pour l’accès aux données
           Command Beans
           Objets Data Access Objects (DAO)
           Accès au système d’information à partir d’un EJB
    Implémentations
           Open source
           Commerciales
Composants
Enterprise Java Beans
(entreprise java beans tiers)


         Dans une application J2EE multi-tiers, le tiers Enterprise JavaBeans héberge la
          partie de l‟application concernant la logique métier et fournit les services
          systèmeainsi que la gestion de la concurrence, des transactions et de la
          sécurité.

         La technologie EJB fournit un modèle de composants distribués qui permet aux
          développeurs de se concentrer sur les problèmes liés à la logique métier de
          l‟application, en se reposant sur la plate-forme J2EE pour toutes les interactions
          complexes avec le système.

         Dans le modèle de programmation J2EE les composants EJB sont le lien
          fondamental entre les composants de présentation hébergés par le tiers web et
          les données de l‟application stockées sur les serveurs du système d‟information
          de l‟entreprise.
Principe des beans
    Les EJBs sont des objets dérivés de la classe de base EJBObject, contenue dans le
     package javax.ejb. Les EJBs sont définies dans les spécifications EJB 2.0.

    Ce sont des composants capables d‟être exécutés en environnement distribué, avec des
     capacités transactionnelles et une gestion de la persistance.

    La philosophie WORA : “Write Once, Run Anywhere” a guidé la conception des EJBs. Ces
     composants permettent d'étendre dynamiquement le comportement d'un serveur et de
     connecter facilement des applications à une BD.

    Utiliser des EJB revient à “enficher” des entités autonomes sur une plate-forme applicative
     Java.

    Les beans doivent implémenter deux types d'interfaces :
    - une interface home, chargée de créer et gérer les beans
    - une interface "normale" qui implémente les méthodes métiers des beans.

    Ces interfaces peuvent être soient locales soit distantes.

    En plus d'implémenter ces interfaces un beans dispose des caractéristiques décrites ci-
     après.
Conserver l’état
     Un objet métier a souvent besoin de maintenir son état entre des appels successifs à ses
      méthodes.

     Cet état peut être simplement conversationnel ou peut être persistant.

     L‟état conversationnel dure le temps d‟une conversation entre le client et l‟application.

     L‟état persistant est un état qui est stocké dans une base de donnée ou un autre type
      d‟entrepôt de données, dépassant la durée de vie d‟une conversation entre le client et
      l‟application.

     Si l‟on prend l‟exemple d‟un objet caddy, l‟état du caddy représente les articles et le nombre
      d‟articles commandés par le client.

     Le caddy est initialement vide et change d‟état à mesure que l‟utilisateur ajoute des articles
      au caddy.

     Lorsque l‟utilisateur supprime des articles, l‟état de l‟objet caddy doit refléter ce
      changement. Quand l‟utilisateur quitte l‟application, l‟objet caddy est détruit.

     Comme la durée de vie de l‟objet n‟a pas excédé celle d‟une conversation entre le client et
      l„application on parle d‟objet à état conversationnel.
Agir sur des données partagées
    Une autre caractéristique des objets métiers est qu‟ils utilisent souvent des
     données partagées.

    Par exemple dans le cas d‟un compte utilisé par plusieurs utilisateurs.

    Dans ce cas des mécanismes sont mis en place pour fournir un accès
     concurrent aux données et fournir différents niveaux d‟isolation pour l‟accès aux
     données.
                                          
Participer à des transactions
     Une transaction peut être décrite par un jeu de tâches à effectuer pour qu‟une
      opération soit accomplie.

     Si l‟une des tâches n‟aboutit pas, toutes les tâches de l‟opération doivent
      pouvoir être annulées.

     Si toutes les tâches réussissent alors la transaction est considérée comme
      accomplie (committed).

     L‟architecture Enterprise JavaBeans définit des composants appelés Enterprise
      Beans – ou beans dans cet ouvrage – qui permettent au développeur d‟écrire
      des objets métiers qui utilisent les services fournis par la plate-forme J2EE.
Handle sur des beans
    Un handle sur un bean est un objet qui permet d'identifier un objet bean sur le
     réseau.

    Un client qui dispose d'une référence sur l'interface distante d'un bean d'entité
     peut obtenir un handle sur le bean en utilisant la méthode getHandle(). Cette
     méthode est uniquement disponbile dan l'interface distante.

    Comme la classe handle étend la classe java.io.Serializable, un client peut
     sérialiser un handle. Le client pourra alors réutiliser le handle plus tard
     éventuellement dans un autre processus ou sur un autre système.

    La méthode javax.rmi.PortableRemoteObject.narrow(...) doit être utilisée pour
     convertir le résultat de la méthode getEJBObject() invoquée sur le handle en
     une interface distante de bean d'entité.

    La durée de vie et la visibilité d'un handle dépendent de l'implémentation.
Exemple d'utilisation d'un handle
     Détermination du type des références d'objets distants
           un programme client qui veut être interopérable avec les conteneurs EJB doit utiliser la
            méthode javax.rmi.PortableRemoteObject.narrow(...) pour réaliser les opérations de
            détermination du type des objets des interfaces distantes et home.
           Il est aussi possible d'obtenir un handle sur un interface home distante de bean.

  // Un client obtient un handle sur un bean d‟entité account et le stocke
  ObjectOutputStream stream = ...;
  Account account = ...;
  Handle handle = account.getHandle();
  stream.writeObject(handle);

  // Un cilent peut relire le handle a partir de l‟emplacement ou il a ete stocke et l‟utiliser pour
  // recréer une référence d‟objet sur le bean d‟enttié account
  ObjectInputStream stream = ...;
  Handle handle = (Handle) stream.readObject(handle);
  Account account = (Account)javax.rmi.PortableRemoteObject.narrow(
  handle.getEJBObject(), Account.class);
  account.debit(100.00);
Clients distants
     Un client distant accède à un beans d'entité via ses interfaces distantes (remote
      interface) et home distante (remote home).

     Ces deux interfaces fournissent au client une vue distante du beans
      indépendante de la localisation du client. Cette vue utilise de manière sous-
      jacente l'API RMI pour gérer le transport des méthodes/objets sur le réseau.
Clients locaux
     Les clients locaux sont situés dans la même JVM que le beans, et de ce fait
      n'utilisent pas d'interfaces distantes pour accéder au beans.

     A la place, ils utilisent les interfaces locales et home locales du beans pour le
      manipuler.
Types de beans
    Il y a 3 types de beans: les beans de sessions (session beans), les beans d‟entité (entity
     beans) et les beans à message (message-driven beans).

    Les beans de session sont des beans destinés à contenir des ressources privées
     concernant un seul client. Pour cette raison, les beans de session paraissent du point de
     vue du client comme anonymes.

    Les beans d‟entité sont des composants qui représentent la vue objet d‟une entité stockée
     dans un entrepôt de données persistant, comme une base de données.

    Par rapport au beans de session, chaque beans d‟entité peut être identifié par un attribut
     appelé la primary key.

    Les beans à messages sont une nouveauté de l‟architecture EJB 2.0 et sont supportés à
     partir de la plate-forme J2EE 1.3. Les beans à message sont des composants qui traite de
     manière asynchrone des messages délivrés par l‟API Java Message Service (JMS).

    Les sections suivantes présentent les deux premiers types de beans et les principes
     généraux des beans.
Interfaces
Interface Home
    L‟interface home fournit des méthodes pour créer et détruire des beans. L‟interface home
     peut aussi contenir des méthodes pour chercher les beans suivant certains critères, et peut
     contenir des méthodes métiers communes à tous les beans.

    L‟interface home distante (remote) d‟un beans doit étendre l‟interface javax.ejb.EJBHome.

    L‟interface home pour un client local doit étendre l‟interface javax.ejb.EJBLocalHome.

    Habituellement ce type d‟interface doit permettre au client de :
         créer de nouvelles instances de bean
         supprimer des instances de bean
         obtenir des méta-données via l‟interface javax.ejb.EJBMetaData.
         obtenir un handle sur l‟interface home. Ce handle peut être sérialisé et écrit sur un support persistant.
          Il peut ensuite être désérialisé pour obtenir une référence sur l‟interface home, éventuellement dans
          une autre Java Virtual Machine.
         trouver une instance de bean déjà crée. L‟interface home d‟un beans fournit une ou plusieurs
          méthodes pour retrouver des instances de bean existantes. Chaque bean d‟entité fournit une
          méthode findByPrimaryKey.
         fournit la logique métier entre les instances

    L‟utilisation de l‟interface home distante engendre une perte de performances. En effet
     chaque méthode est enveloppée dans des appels RMI-IIOP, ce qui fait perdre un temps non
     négligeable.
Localiser un bean d'entité par son
interface home distante

     Un client peut localiser l'interface home distante d'un bean d'entité en utilisant
      l'API JNDI.

     Exemple :
       Context initialContext = new InitialContext();
       AccountHome accountHome = (AccountHome) javax.rmi.PortableRemoteObject.narrow(
          initialContext.lookup(“java:comp/env/ejb/account”,AccountHome.class)
       );
Méthode create()

    Une interface home distante de bean contient habituellement une ou plusieurs
     méthodes create().

    Les arguments passés à ces méthodes sont en général des paramètres
     d'initialisation du bean.

    Le type de retour de ces méthodes est une interface distante du bean.

    La clause throws d'une méthode create() distante doit inclure les exceptions
     java.rmi.RemoteException et javax.ejb.CreateException. (au minimum)
Exemple create()
 public interface AccountHome extends javax.ejb.EJBHome {

     public Account create(String firstName, String lastName, double initialBalance) throws
       RemoteException, CreateException;

     public Account create(String accountNumber, double initialBalance) throws RemoteException,
       CreateException, LowInitialBalanceException;

     public Account createLargeAccount(String firstname, String lastname, double initialBalance)
         throws RemoteException, CreateException;
     ...
 }

      Exemple de création d'un objet

 AccountHome accountHome = ...;
 Account account = accountHome.create(“John”, “Smith”, 500.00);
Méthodes finder()

    L'interface home distante d'un bean d'entité doit définir une ou
     plusieurs méthodes find…(), utilisées pour retrouver un bean en
     fonction de certains critères.

    Ces méthodes doivent contenir une clause java.rmi.RemoteException
     et javax.ejb.FinderException.

    L'interface    distante      inclut principalement   la    méthode
     findByPrimaryKey(primaryKey) qui permet à un client de retrouver un
     bean d'entité par sa clé primaire.

    Cette méthode renvoit une interface distante du bean d'entité, utilisée
     pour déclencher des méthodes métier sur le bean.
Exemple findByPrimaryKey()
      public interface AccountHome extends javax.ejb.EJBHome {
       ...
       public Account findByPrimaryKey(String AccountNumber)
       throws RemoteException, FinderException;
      }


    Exemple d'utilisation :

      AccountHome = ...;
      Account account = accountHome.findByPrimaryKey(“100-3450-3333”);
Méthodes remove()

    L'interface javax.ejb.EJBHome définit plusieurs méthodes pour supprimer un
     objet entité.

      public interface EJBHome extends Remote {
         void remove(Handle handle) throws RemoteException, RemoveException;
         void remove(Object primaryKey) throws RemoteException, RemoveException;

      }
Méthodes home
    Ces méthodes implémentent les parties de la logique métier non-spécifiques à
     chaque instance de bean.

    Leur nom ne doit pas commencer pat “create”, “find”, ou “remove”.

    Les clauses d'exception de ces méthodes                                 doivent       toutes     inclure
     java.rmi.RemoteException, au minimum.

    Exemple de méthodes home :
      public interface EmployeeHome extends javax.ejb.EJBHome {
      ...
      // Cette méthode renvoit dynamiquement un chiffre basé sur l‟état et le salaire d‟un employé.
      // Cette méthode n‟est pas spécifique à une instance de bean
      public float livingIndex(String state, float Salary) throws RemoteException;

      // Cette méthode accorde un bonus a tout les employés en fonction
      // des bénéfices réalisés par la compagnie
      public void addBonus(float company_share_index) throws RemoteException,
           ShareIndexOutOfRangeException;
      ...
      }
Interface Home locale
    L‟interface home locale d‟un bean est similaire à l‟interface home distante mais
     ne fournit pas certaines méthodes (metadonnées, handle [obtention de
     référence sur un objet réseau])

    L‟utilisation de l‟interface locale requiert que le bean et le client résident dans la
     même JVM.

    Cette interface étend la classe EJBLocalHome.
Localiser un bean d'entité par son
interface home locale
     Cette opération se réalise de la même facon que pour une interface home
      distante mais ne mets pas en jeu les APIs pour l'accès distant.

     Exemple :

       Context initialContext = new InitialContext();
       AccountHome accountHome = (AccountHome)
          initialContext.lookup(“java:comp/env/ejb/accounts”);
Méthode create()
    Dans une interface locale, la seule excpetion à gérer obligatoirement dans les
     méthodes create…() est l'exception javax.ejb.CreateException.

    Exemples :

      public interface AccountHome extends javax.ejb.EJBLocalHome {

      public Account create(String firstName, String lastName, double initialBalance) throws CreateException;

      public Account create(String accountNumber, double initialBalance) throws CreateException,
          LowInitialBalanceException;

      public Account createLargeAccount(String firstname, String lastname, double initialBalance) throws
          CreateException;
      ...
      }


    Exemple d'instanciation de l'interface locale d'un bean avec l‟interface home
     locale :

      AccountHome accountHome = ...;
      Account account = accountHome.create(“John”, “Smith”, 500.00);
Méthodes finder()

    Ces méthodes doivent gérer l'exception javax.ejb.FinderException au minimum.

    Exemple de déclaration :

      public interface AccountHome extends javax.ejb.EJBLocalHome {
      ...
      public Account findByPrimaryKey(String AccountNumber)
      throws FinderException;
      }

    Exemple d'utilisation :

      AccountHome = ...;
      Account account = accountHome.findByPrimaryKey(“100-3450-3333”);
Méthodes remove()

    L'interface définie dans la classe javax.ejb.EJBLocalHome définit des
     méthodes pour permettre au client de supprimer un objet entité.

    Exemple :
          public interface EJBLocalHome {
            void remove(Object primaryKey) throws RemoveException, EJBException;
          }


    L'exception javax.ejb.NoSuchObjectLocalException doit être gérée par
     ces méthodes.
Méthodes home

    Les mêmes restrictions que pour les méthode home d'un interface
     home distante s'appliquent.

    Exemple :

      public interface EmployeeHome extends javax.ejb.EJBLocalHome {

      // Cette méthode renvoit dynamiquement un chiffre basé sur l‟état et le salaire
      // d‟un employé. Cette méthode n‟est pas spécifique à une instance de bean
      public float livingIndex(String state, float Salary);

      // Cette méthode accorde un bonus a tout les employées en fonction
      // des bénéfices réalisés par la compagnie
      public void addBonus(float company_share_index) throws
          ShareIndexOutOfRangeException;
      ...
      }
Interface Remote

    Un client peut accèder à un bean d'entité via l'interface distante du bean. Cette
     interface étend la classe javax.ejb.EJBObject.

    L'interface distante définit les méthodes métier appelables par des clients
     distants.

    L'interface javax.ejb.EJBObject définit des méthodes qui permettent au client
     d'effectuer les opérations suivantes sur la référence au bean d'entité :
         obtenir une une interface home distante pour l'objet d'entité
         supprimer l'objet
         obtenir un handle sur l'objet
         obtenir la clé primaire de l'objet entité

    C'est le conteneur qui fournit l'implémentation des méthodes définies dans
     l'interface javax.ejb.EJBObject. Seules les implémentations des méthodes
     métiers sont déléguées aux instances de bean.
Exemple

   public interface Account extends javax.ejb.EJBObject {

   void debit(double amount) throws java.rmi.RemoteException,
      InsufficientBalanceException;

   void credit(double amount) throws java.rmi.RemoteException; double getBalance() throws
       java.rmi.RemoteException;

   }
Interface Locale
     Cette interface remplit le même rôle que l'interface distante mais à
      l'intention des clients locaux et comporte donc les méthodes métiers
      accessibles par les clients locaux du bean.

     Elle doit étendre l'interface javax.ejb.EJBLocalObject.

     Exemple :

           public interface Account extends javax.ejb.EJBLocalObject {

               void debit(double amount) throws InsufficientBalanceException;

               void credit(double amount);

               double getBalance();
           }
Règles de conception des beans
    Il faut veiller à garder un code aussi indépendant du client que possible et
     notamment éviter toute méthodes en rapport avec http ou le rôle du tier web.

    Il faut aussi reposer plutôt sur des beans de sessions que sur le client pour
     conserver les données conversationnelles.
Session
    Les EJBs de session sont non-persistants (short-lived) et en général associés à
     un seul client.

    Ce type de bean est détruit après un arrêt ou une panne du serveur d‟EJB.

    Les beans de sessions ne peuvent pas être inclus dans une transaction.
Beans de session sans                                                  état
(stateless session bean)
    Les beans de session sans état ne conservent pas d‟informations entre les
     appels de méthodes et peuvent être partagés par plusieurs clients.

    Comme ce type de bean ne conserve pas de données internes, il est inutile de
     les rendre passif.

    Ex: bean qui effectue un calcul et renvoie un résultat sans le mémoriser.
Cycle de vie d’un bean de session
sans état

                 
Beans de session avec                                                    état
(stateful session beans)
    Les beans de session avec états sont capables de retenir des informations entre
     plusieurs appels de méthodes provenant du même client.

    Ex.: un bean caddie qui contient des articles le temps de la visite du client.
Cycle de vie d’un bean de session
avec état
                 
Entités
     Les beans d‟entité représentent les lignes d‟une base de données relationnelle
      ou un objet persistant dans une base de données objet.

     Ces objets ont la particularité d‟être persistants (long-lived).
     La persistance des beans d‟entité est:
     - gérée par le bean (bean managed persistence),
     - gérée par le conteneur (container managed persistence).

     Un bean d‟entité est restauré dans le dernier bon état en cas de panne du
      serveur EJB et les pannes sont transparentes pour le client.

     Les beans d‟entité peuvent participer à des transactions.

     Les beans d‟entité acceptent l‟accès multiple de plusieurs clients simultanément
      (concurrence) et gèrent plusieurs niveaux de sérialisation.
La sérialisation
     Le concept de base de la sérialisation d‟objet est la capacité de lire et d‟écrire des objets
      sous forme de flux d‟octets.

     Ces flux peuvent être utilisés pour sauver des informations sur l‟état d‟une session par une
      servlet, pour envoyer des paramètres lors d‟appels RMI, pour sauver les informations d‟état
      d‟un JavaBeans, d‟une manière générale cette technique est utilisée pour envoyer des
      objets sur le réseau, ainsi que pour beaucoup d‟autres tâches.

     Pour qu‟un objet soit sérialisable, il doit implémenter l‟interface Serializable . Il faut utiliser
      les classes ObjectOutputStream et ObjectInputStream pour sauvegarder un objet et le
      restaurer.

     Le processus de sérialisation s‟occupe de créer une vision à plat de l‟objet (à partir de la
      structure en arbre utilisée pour modéliser l‟objet) ainsi que de toutes les données brutes qui
      composent l‟objet, en incluant tous les objets référencés par l‟objet en cours de sérialisation.

     Lorsqu„il faut restaurer l‟objet, l‟objet original est reconstitué. Les cas spéciaux tels que les
      références circulaires et les références multiples sur un objet sont pris en compte de façon à
      ce qu‟un nouvel objet ne soit pas récrée lorsqu‟il s‟agit en fait d‟une référence à un objet
      déjà existant.
                                                  
Cycle de vie d’un bean d’entité

                  
Implémenter et utiliser un bean
Développement côté client

         Pour utiliser un bean, on doit obtenir une référence sur ses interfaces.

         L'utilisation d'un bean suit habituellement le synopsis suivant :
     1.       Rechercher l‟interface Home du bean par son nom, via JNDI
     2.       Accéder au bean: on récupère une référence sur une interface Remote
     3.       Invocation du bean: on appelle les méthodes du bean via la référence précédente,
     4.       Fin de session: on notifie au bean que la session courante est terminée.
Exemple
 public class HelloClient {
  public static void main( String[] args ) {
   /* Recherche de l‟interface Home */
   InitialContext ic = new InitialContext();
   HelloHome home = (HelloHome) ic.lookup(“ HelloHome”);

         /* Création d‟une nouvelle instance */
         Hello hello = home. create();

         /* Invocation de méthode */
         hello. ping();

         /* Fin de session - Retrait de l‟instance */
         hello. remove();
     }
 }
Développement côté serveur

         L'implémentation d'un bean suit habituellement le synopsis suivant :
     1.          Ecrire une interface Remote
     2.          Ecrire une interface Home
     3.          Implanter les méthodes de l‟EJB
     4.          Ecrire un programme « descripteur de déploiement » (ejb-jar.xml) fournissant
                    le nom de l‟interface Remote
                    le nom de l‟interface Home
                    le nom de la classe d‟implantation de l‟EJB
                    les ACL des clients et des groupes de clients autorisés
                    pour un session bean, dire si le bean est stateless ou stateful
                    pour un entity bean, indiquer les variables d‟instances dont la persistance est gérée par le
                     conteneur
     5.          Un fichier de propriété décrivant les ≠ paramètres de configuration du bean
     6.          Un fichier dit manifest donnant le nom de tous les fichiers précédents. Ce fichier
                 sert à créer un fichier .jar que l‟on déploie sur les serveurs d‟EJB
Exemple (1/2)
    L‟interface Remote

 public interface Hello extends EJBObject {
     public void ping() throws RemoteException;
 }

    L‟interface Home

 public interface HelloHome extends EJBHome {
     public Hello create() throws ... ;
 }

    L‟implémentation

 public class HelloBean implements SessionBean {
 /* Contient également ejbCreate, ejbRemove, ejbActivate, ejbPassivate */

  public void ping() { System. out. println(“ping reçu” ); }
 }
Exemple (2/2)
    Le descripteur de déploiement ejb-jar.xml :
      <ejb-jar>
       <display-name>HelloJar</display-name>
       <enterprise-beans>
        <session>
          <display-name>HelloBean</display-name>
          <ejb-name>hello</ejb-name>
          <home>Beans.HelloHome</home>
          <remote>Beans.Hello</remote>
          <ejb-class>Beans.HelloBean</ejb-class>
          <session-type>Stateless</session-type>
          <transaction-type>Bean</transaction-type>
          <security-identity>
           <description></description>
           <use-caller-identity></use-caller-identity>
          </security-identity>
        </session>
      </enterprise-beans>
      </ejb-jar>


    Le fichier manifest.inf contient :
      Name: HelloBean
      Enterprise- Bean: True
Serveur d’EJB

    Le serveur d'EJB est une machine de l‟environnement EJB qui gère les
     conteneurs d'EJB.

    Les systèmes d‟entreprise distribués requièrent un grand nombre de services
     communs.

    Cela inclut la gestion de état, l‟accès aux données partagées, la participation à
     des transactions, le service d‟une grand nombre de clients, la fourniture de
     services d‟accès distant aux données et le contrôle de l‟accès à ces données.

    Le tier central de l‟architecture J2EE qu‟est le serveur d‟EJB tente de réunir tous
     ces services.
Conteneurs d'EJB
    Le conteneur d‟EJB est l‟environnement d‟exécution des EJBs.

    Les Enterprise beans résident dans des conteneurs d‟EJB (EJB container), qui fournissent
     les services de gestion du cycle de vie, des transactions, de la sécurité, de la persistance, et
     aussi d‟autres services.

    Un conteneur d‟EJB fait partie d'un serveur d‟EJB qui fournit les services de nommage et
     d‟annuaire, de messagerie électronique, etc… Quand un client appelle une méthode sur un
     bean, l‟appel est intercepté par le conteneur.

    En s‟interposant entre le bean et le composant au niveau de l‟appel de méthode, les
     conteneurs peuvent injecter des services qui sont propagés entre les composants et
     peuvent même être propagés à d‟autres conteneur résidents sur des serveurs différents ou
     d‟autres machines. Comme le serveur injecte ces services de manière transparente, ce
     mécanisme permet de simplifier le développement des composants et des clients.
Fonctions du conteneur
    Le conteneur implémente 4 fonctionnalités principales pour le compte des beans
         gestion de la persistance
         gestion des transactions (JTA)
         gestion des instances
         gestion de la sécurité


    Le souhait des concepteurs est de pouvoir remplacer ou faire cohabiter ces
     technologies avec d'autres équivalentes, par exemples issues du monde
     CORBA:
         RMI -> IIOP
         JNDI -> COSNaming
         JTS -> COSTransaction
Gestion de la persistance
     Dans le cas de la persistance gérée par le conteneur, le fournisseur de l‟EB
      précise les champs du bean qui doivent être sauvegardés (container managed
      fields) et précise le support utilisé pour la persistance, le code d‟accès à la base
      de donnée est géré par le conteneur.

     Dans le cas de la persistance gérée par le bean, le fournisseur de l‟EB écrit les
      opérations d‟accès aux données permettant de gérer la persistance dans les
      callbacks appropriés du bean (ejbCreate, ejbStore, ejbLoad, ejbFind…),
      typiquement (mais pas exclusivement) en utilisant JDBC.

     Dans tous les cas, c‟est le conteneur d‟EJB qui assure la cohérence entre l‟état
      du bean et l‟état sauvegardé en base de données.

     Des exemples concrets sont développés dans les travaux pratiques.
EJB QL, the EJB Query Language

    L‟un des avantages d‟utiliser la persistence gérée par le conteneur est que cela
     permet d‟utiliser EQL, le langage de requêtes de beans d‟entités. Ce langage
     est une nouveauté des spécifications EJB 2.0.

    Le conteneur traduit les requêtes EJB QL en requêtes adaptées au serveur de
     données, par exemple en SQL.

    Une requête EJB QL doit toujours comporter ue clause SELECT et une clause
     FROM, et toujours comporter une clause WHERE qui limite l‟étendue du jeu de
     resultants. Le résultat d‟une requête EJB QL peut être soit un bean d‟entié soit
     une valeur persistante ou une collection de l‟un des deux.
Exemple de requête EJB QL

 SELECT DISTINCT OBJECT(o)
 FROM SupplierOrder o
 WHERE o.poStatus =?1
Gestion des transactions
     L‟architecture J2EE peut utiliser l‟architecture XA, une extension standard de
      JDBC 2.0, pour gérer les transactions.

     L‟API Java pour les transactions est la Java Transaction API (JTA) (classes
      javax.sql.XA…, javax.transaction.xa.*).Cette architecture permet d‟utiliser des
      transactions plates (non-imbriquées).

     Les transactions peuvent être contrôlées explicitement par le bean ou par un
      client (cette fonctionnalité est incluse dans JTA).

     La gestion des transactions est déclarative, le développeur doit assigner un
      attribut transactionnel aux méthodes de l‟EJB lors de la phase d‟implémentation
      ou lors du déploiement.
Attributs de transaction
     Les attributs possibles sont:
          TX_ NOT_ SUPPORTED : le bean ne supporte pas les transactions. En cas
           d‟utilisation dans 1 transaction, celle- ci est suspendue.
          TX_ BEAN_ MANAGED : le bean gère ses propres transactions
          TX_ REQUIRED: si le client a une transaction ouverte, le bean s‟exécute
           dans ce contexte sinon le conteneur commence une nouvelle transaction.
          TX_ SUPPORTS: si le client a une transaction ouverte, le bean s‟exécute
           dans ce contexte sinon aucune transaction n‟est ouverte.
          TX_ REQUIRES_ NEW : une nouvelle transaction est systématiquement
           créée.
          TX_ MANDATORY: si le client a une transaction ouverte, le bean s‟exécute
           dans ce contexte sinon une erreur est générée.
Gestion d’instances
     Le conteneur peut effectuer les opérations d‟administration des beans
      suivantes:
          Désactivation d‟instances: sauvegarde temporaire du bean lorsque le
           conteneur a besoin de mémoire
          Pooling d‟instances: pour des raisons de performances, le conteneur peut
           instancier moins de beans qu‟il n‟y a de client ! Plusieurs clients partagent
           un même bean. Cela n‟est possible que si le bean ne gère pas de variables
           d‟instance.
          Pooling de connexion à la base de données: tous les beans d‟un même
           serveur partage un pool de connexions à la base de données, les
           connexions restent ouvertes et sont utilisées à la demande par les beans
           Cache d‟instances
          Les conteneurs gèrent des caches de variables d‟instances qui accélèrent
           le chargement des beans qui doivent être activés
          Optimisation d‟invocations : utilisation d‟appels directs (sans passer par
           RMI) lorsque le client et le bean serveur sont dans le même conteneur
Connexion aux ressources de
l'entreprise

    Une application J2EE doit intégrer des données déjà existantesdu système
     d'information de l'entreprise.

    Ces données peuvent être relationnelles, objets ou sous toute autre forme
     utilisée par le système d‟information de l‟entreprise.

    Ce chaptire présente plusieurs objets destinés à accéder aux serveurs du
     système d'information de l'entreprise (enterprise information system tier).
Types d’objets pour l’accès aux
données
Command Beans
    Un objet peut encapsuler des fonctions pour accéder au système d‟information
     de l‟entreprise.

    On appelle ces objets des beans de commande.

    Exemple d‟utilisation d‟un command bean

      PurchaseFunction pf = …
      //instantiate access object for PurchaseFunction

      //set fields for this purchase order
      pf.setCustomer ("Wombat Inc");
      pf.setMaterial (...);
      pf.setSalesOrganization (...);
      pf.execute ();

      //now get the result of purchase requisition using getter methods
Objets Data Access Objects
(DAO)

    Ce type d‟objet est utilisé pour représenter une structure de donnée
     destinée à contenir une entité issue (ou à créer) dans le tier du
     système d‟information d‟entreprise.
Exemple d’objet DAO
 public class CatalogDAO extends com.example.tool.DAO {

 private RecordFactory rf;

 public CatalogDAO(Connection cx,RecordFactory rf){
  super(cx);
  this.rf =rf;
 }

  public Collection getAllProducts()throws DAOException {
   try {
    MappedRecord input = rf.createMappedRecord("PRODUCT_INPUT_RECORD");
    input.put("ORDER-ID","*");
    IndexedRecord output = rf.createIndexedRecord("PRODUCT_INFO_RECORD");
    InteractionSpecImpl ixSpec =new InteractionSpecImpl();
    ixSpec.setFunctionName("GET_PRODUCTS");
    ixSpec.setInteractionVerb(InteractionSpec.SYNC_SEND_RECEIVE);
    Interaction ix =cx.createInteraction();
    ix.execute(ixSpec,input,output);
    java.util.Iterator iterator =output.iterator();
    while (iterator.hasNext()){ //Get a record element and extract value, add element to the collection }
   //Return Collection
   }catch (ResourceException re){ //...Handle exception }
  } //other DAO class methods ....
 }
Exemple d’utilisation

    public Product getProduct(String productID,Locale locale){
     try {
      CatalogDAO dao =ProductCatalogDAOFactory.getDAO ();
      return dao.getProduct (productID,locale);
     }catch (...){
      //…gérer les exceptions
     }
    }
Accès au système d’information à
partir d’un EJB
    Pour les beans d'entités, les spécifications EJB identifient les méthodes
     possibles pour accéder au système d'information de l'entreprise :
         ejbCreate ,
         ejbPostCreate ,
         ejbRemove ,
         ejbFind ,
         ejbActivate ,
         ejbLoad ,
         ejbStore ,
         et toute autre méthode de l'interface distante.

    Un bean d'entité ne peut accéder au système d'information de
     l'entreprise   à    partir   des     méthodes        setEntityContext    et
     unsetEntityContext car le conteneur ne peut associer un contexte de
     sécurité ou de transactions significatif lors de l'appel à ces méthodes.
Implémentations Open source
    J2EE Sun
    http://java.sun.com/j2ee

    JOnAS Bull
    http://www.bullsoft.com/ejb/

    AnEJB D. O. G.
    http://www.multimania.com/dogweb/

    EJBoss TEO
    http://www.ejboss.org

    Pour une liste détaillée
    http://www.javasoft.com/products/ejb/tools1.html
Implémentations Commerciales
    Websphere
    http://www.ibm.com/websphere

    SunOne (Open Net Environnment)
    http://wwws.sun.com/software/sunone/

    Weblogic
    http://e-docs.bea.com/

    Resin
    http://www.caucho.com