Différences entre EJB 3.1 et EJB 2.1

Comparé à EJB 2.1, EJB 3.1 simplifie le processus de création d'applications Enterprise Java™ Bean.

EJB 2.x et complexités de l'architecture J2EE 1.4

Architecture J2EE 1.4

Couche métier Dans l'architecture J2EE 1.4, les beans session servent à encapsuler les composants de la logique métier, en leur offrant des services transactionnels, répartis, éloignés et de sécurité. Ils implémentent généralement un pattern de façade afin de réduire le trafic réseau entre le client et le fournisseur de services. Des clients locaux (qui résident dans la même JVM) ou éloignés peuvent y accéder.

Des beans gérés par message sont utilisés pour intégrer des fournisseurs JMS externes (tels que MQSeries) afin de permettre la prestation de services de messagerie asynchrone.

L'ensemble des beans session et des beans gérés par message forme la couche de logique métier. Ils sont appelés "couche" car ils sont au centre d'un autre paradigme fondamental adopté dans la conception de cette architecture d'entreprise, paradigme qui permet la mise en oeuvre de fonctionnalités essentielles telles que la séparation des tâches et des compétences, le regroupement (clustering), et la réutilisation des composants.

Couche de persistance L'autre couche fondamentale, appelée "couche de persistance", est formée de l'ensemble des services et composants qui permettent aux données applicatives de persister dans une base de données relationnelle. Elle peut être implémentée de plusieurs manières :
  • Beans entity (persistance gérée par conteneur ou gérée par bean)
  • Objets accès aux données (DAO) JDBC
  • Infrastructures ORM (object-relational mapping)

Problèmes liés à la spécification EJB 2.x

  • La spécification EJB 2.x stipule que l'interface de composant doit étendre une interface du package de l'infrastructure EJB, et la classe d'implémentation de la logique métier doit implémenter une interface du package de l'infrastructure EJB. Ces exigences créent un couplage étroit entre le code écrit par le développeur et les classes d'interface du package de l'infrastructure EJB. Elles impliquent également la nécessité d'implémenter plusieurs méthodes de rappel superflues (ejbCreate, ejbPassivate, ejbActivate), qui ne sont pas directement liées à la finalité principale de l'EJB, et de gérer des exceptions tout aussi superflues.
  • Les descripteurs de déploiement de beans EJB sont trop prolixes, complexes et sources d'erreurs.
  • Les EJB sont difficiles à tester car l'application a besoin d'un conteneur J2EE pour offrir tous les services nécessaires à l'exécution correcte des composants EJB.
  • Faire appel à JNDI chaque fois que vous devez accéder à une ressource (telle qu'une source de données ou une référence à un objet EJB home) est répétitif et fastidieux.
  • Le modèle de persistance gérée par conteneur est complexe à développer et gérer.

Modèle simplifié dans EJB 3.1

L'architecture globale de Java EE et EJB 3.1 reflète la simplification du modèle EJB 3.1 :

Architecture EJB 3.1

Le concept sous-jacent de la spécification EJB 3.1 est centré sur un modèle de programmation POJO(plain old Java object) qui utilise des annotations Java afin de capturer les informations qui, jusqu'à présent, se trouvaient dans les descripteurs de déploiement. Ces derniers sont désormais facultatifs dans la plupart des cas. Le recours à des valeurs par défaut signifie aussi que vous n'avez pas besoin d'écrire et de tenir à jour autant de code annexe qu'auparavant. Cela simplifie nettement la tâche de programmation liée à la création et à l'utilisation des composants EJB 3.1. Les principales caractéristiques de ce modèle simplifié sont les suivantes :
  • Les EJB sont désormais des objets POJO qui exposent des interfaces métiers classiques (POJI), et il n'est plus nécessaire d'utiliser des interfaces home.
  • Il utilise des métadonnées d'annotation, via une infrastructure extensible, basée sur des métadonnées et orientée attributs, qui servent à générer du code Java ou des descripteurs de déploiement XML.
  • L'utilisation d'interfaces spécifiques et de descripteurs de déploiement n'est plus nécessaire (les informations précédemment indiquées dans les descripteurs de déploiement peuvent être remplacées par des annotations).
  • Une fonction d'interception permet d'appeler des méthodes utilisateur lors de l'appel de méthodes métier ou lors d'événements du cycle de vie.
  • Des valeurs par défaut sont utilisées chaque fois que possible (approche appelée "configuration par exception").
  • L'utilisation des exceptions contrôlées est soumise à des exigences moins nombreuses.
  • Il utilise un modèle de persistance entièrement nouveau (basé sur la norme JPA), qui remplace les beans entity EJB 2.x.
Tableau 1. Comparaison des procédures de création de beans avec EJB 2.1 et EJB 3.1. EJB 2.x utilise des descripteurs de déploiement et EJB 3.1 utilise des annotations.
Procédure de définition d'un bean session sans état avec EJB 2.x Procédure de définition d'un bean session sans état avec EJB 3.1

Pour créer un bean session sans état conformément à la spécification EJB 2.x, il convient de définir les composants suivants :

  • Interface de composant EJB : utilisée par un client EJB pour accéder aux fonctionnalités du bean. C'est là que les méthodes métier sont définies. L'interface de composant est appelée objet EJB. Il existe deux types d'interface de composant :
    • Interface de composant distante (EJBObject) : utilisée par un client éloigné pour accéder à l'EJB via le protocole RMI-IIOP.
    • Interface de composant locale (EJBLocalObject) : utilisée par un client local (qui s'exécute dans la même JVM) pour accéder à l'EJB.
  • Interface home EJB : utilisée par un client EJB pour accéder au bean. Elle contient les méthodes de cycle de vie du bean relatives à la création, la rechercher ou la suppression. L'interface home est appelée home EJB. L'objet EJBHome est un objet qui implémente l'interface home et qui, à l'instar d'EJBObject, est généré à partir des outils de conteneur lors du déploiement et inclut du code propre au conteneur. Lors du démarrage, le conteneur d'EJB instancie les objets EJBHome des beans enterprise déployés et enregistre l'objet home auprès du service de dénomination. Un client EJB accède aux objets EJBHome avec l'interface JNDI (Java Naming and Directory Interface). Il existe deux types d'interface home :
    • Interface home distante (EJBHome) : utilisée par un client éloigné pour accéder à l'EJB via le protocole RMI-IIOP.
    • Interface home locale (EJBLocalHome) : utilisée par un client local (qui s'exécute dans la même JVM) pour accéder à l'EJB.
  • Classe de bean EJB : contient toute la logique métier du bean. C'est la classe qui fournit l'implémentation de la logique métier. Les méthodes qu'elle contient s'associent à celles des interfaces de composant et des interfaces home.

Pour déclarer un bean session sans état conformément à la spécification EJB 3.1, il suffit de définir un objet POJO :

  • @Stateless
    public class MySessionBean implements MyBusinessInterface {
    // business methods according to MyBusinessInterface
    .....
    }
  • Pour exposer le même bean sur l'interface distante, utilisez l'annotation @Remote :
    @Remote(MyRemoteBusinessInterface.class)
    @Stateless
    public class MyBean implements MyRemoteBusinessInterface {
    // ejb methods
    .....
    }

Comparaison de la classe EJB 2.1 avec descripteur de déploiement et de la classe EJB 3.1 équivalente

Les exemples du Tableau 1 sont fonctionnellement équivalents :

Tableau 2. Comparaison d'EJB 2.1 et EJB 3.1. EJB 2.1 utilise des descripteurs de déploiement et EJB 3.1 utilise des annotations.
EJB 2.1 EJB 3.1

Classe Java

public class AccountBean
implements javax.ejb.SessionBean {
 
     SessionContext ctx;
     DataSource accountDB;
 
     public void setSessionContext(SessionContext ctx) {
        this.ctx = ctx;
     }
 
     public void ejbCreate() {
          accountDB = (DataSource)ctx.lookup(
                          "jdbc/accountDB");
 
     }
     public void ejbActivate() { }
     public void ejbPassivate() { }
     public void ejbRemove() { }

     public void setAccountDeposit(int empId,
                                      double deposit) {
       ...
       Connection conn = accountDB.getConnection();
       ...
     }
  ...
}

Classe Java

@Stateless
public class AccountBean implements Account
{
     @Resource private DataSource accountDB;
 
     public void setAccountDeposit(int customerId,
                                      double deposit) {
       ...
       Connection conn = accountDB.getConnection();
       ...
     }
  ...
}

Descripteur de déploiement

<session>
  <ejb-name>AccountBean</ejb-name>
  <local-home>AccountHome</local-home>
  <local>Account</local>
  <ejb-class>com.example.AccountBean</ejb-class>
  <session-type>Stateless</session-type>
  <transaction-type>Container</transaction-type>
  <resource-ref>
    <res-ref-name>jdbc/accountDB</res-ref-name>
    <res-ref-type>javax.sql.DataSource</res-ref-type>
    <res-auth>Container</res-auth>
  </resource-ref>
</session>
...
<assembly-descriptor>...</assembly-descriptor>
 
Icône indiquant le type de rubrique Rubrique
Dispositions pour les centres de documentation | Commentaires en retour

Icône d'horodatage Dernière mise à jour: May 29, 2014 10:11

Nom de fichier : cejb3vejb21.html