Java/EE/EJB

Un article de Agora2ia.

< Java | EE(Redirigé depuis EnterpriseJavaBean)


Sommaire

Présentation

Un EJB c'est...

  1. Un composant Java,
  2. Portable
  3. Réutilisable,
  4. Déployable,
  5. Que l'on peut assembler (-> Architecte J2EE)
  6. Qui s'execute dans un conteneur.


Un conteneur EJB est un environnement d'exécution fournissant des services aux EJB. Comme exemple de services on peut citer par exemple :

  • transaction,
  • persistence,
  • autorisation,
  • ...

Les avantages de cette architecture sont :

  1. Grâce au conteneurn, le développeur peut se concentrer sur la logique applicative, et non sur l'implémentation des services, ces derniers sont alors développer par les développeurs du conteneur. La fiabilité des services est alors directement liée à celle du conteneur, à sa rénommée...
  2. La logique de l'application est concentrée dans ces composants, permettant de réaliser des clients plus légers.
  3. Grâce à la spécification EJB, tout conteneur compatible EJB peut héberger un EJB, offrant ainsi une grande portabilité, et facilitant donc la réutilisation et l'assemblage des EJB.

Pourquoi utiliser des EJB ?

Chez mon client actuel (applications de gestion de produits financiers), on avait besoin de faire du 3 tiers car il fallait un serveur pour :

  • Lancer des batchs,
  • Faire des traitements la nuit,
  • Décharger la machine des clients
  • Et le serveur permet de protéger les données (via ses traitements de cohérence métier).

Or l'EJB est l'architecture officielle de Sun.


De maniere generale, EJB 2.0 est conseillé :

  • Sur les grands projets, ayant des "milliers" de clients, avec une charge phénoménale sur le serveur.
  • Quand on a besoin de services techniques complexes mais standards (et donc dèjà existants). Le plus fréquents est le gestionnaire de transaction, mais il y en a bien d'autres : sécurité/profiles, messaging... Cela prend du temps pour les configurer correctement, mais le gain en fiabilité ne souffre aucune contestation.
  • Surtout quand on a des clients légers (web) : dans EJB, les composants web sont des composants EJB comme les autres qui s'integrent très bien.
  • Quand les différentes fonctionnalités doivent être développées par différentes personnes/équipes.


Mon responsable considère que la mise en place des EJB ici n'est pas un franc succès car :

  • On ne s'est pas donné les moyens,
  • On a eu enormement de problèmes avec le drivers JDBC : l'exploitation n'a pas voulu acheter le driver compatible (XA compatible JTA), et du coup l'équipe a perdu enormément, enormement, enormement de temps à faire des "grouilles" pour que ça marche à peut près !
  • On est toujours avec des vieux vieux vieux serveurs (Weblogic 6, qui n'est meme pas certifie JDK 1.4)

Comment choisir son type de Bean

Il existe 3 types de Bean Entreprise en fonction du besoin :

  • Séssion : Renferme la logique métier, effectue une tâche ou mets en application un WebService pour un accès client.
    • Stateless
    • Stateful
  • Entité : Objet de persistance représentant une entité métier, "protégé" sur le serveur.
    • Persistance Bean-Managed (BMP)
    • Persistance Container-managed (CMP)
  • Message : Système de méssages asynchrones, pour un accès externe (Agit comme un listener pour l’API JavaMessageService).


  • Si on appelle directement un "Entité" risque d'y intégrer la logique fonctionnelle
  • IHM doit être indépendante des "Entité" : isolé par les "Session"
  • Restreindre l'accès client aux "Session" : nombre de "Session" < nombre d'"Entité"

JDBC

DataSource

  • Recommandé pour obtenir une connexion à la base de données
  • Masque les détails de connexion à la base (URL, hôte, port...)
  • Notion de Pool de connexions
  • Obtenue :
    • par recherche dans un contexte (Association nom/ressource, cf. LDAP, ActiveDirectory)
    • Créée et associée côté serveur


JNDI

  • JNDI pour Java Naming and Directory Interface
  • Interface neutre pour les services de répertoire
  • Comme JDBC pour les bases de données


Pool de connexions

Pour une application J2EE distribuée, les serveurs étant sur des machines différentes, la création d'une connexion est longue. C'est pour cela que l'on met en place un pool de connexions, c'est à dire une collection de connexions créees à l'avance et recyclées, réutilisées durant la vie de l'application.


Cycle : on prend la connexion du pool, l'utilise et la « rend » au pool.

Le Connection.close() ne ferme pas physiquement la connexion, mais la remet dans le pool. Transparent pour le client/utilisateur de la connexion.


Les beans Session

Présentation

Les 2 côtés :

  • Côté Client : 2 interfaces à écrire (=> 2 stubs générés), HOME (EJBHome) et BEAN (EJBObject)
  • Côté Serveur : 1 classe BEAN à écrire


Les stubs :

  • Créés automatiquement par l'outil de déploiement
  • Invocation des méthodes EJB sur le serveur via RMI


Image:Ejb.png


Côté client, on utilise JNDI pour récupérer le HOME, puis le HOME pour créer le BEAN.

Exemple de code côté client pour utiliser un EJB Session :

// Récupérer un contexte de nom JNDI
Context initialContext = new InitialContext();

// Retrouver l'objet associé au nom JNDI (cf. ejb-jar.xml)
Object object = initialContext.lookup("AnActor");

// Vérifier que l'objet (interface distante) peut être projeté vers un type voulu.
AnActorHome home = (AnActorHome)PortableRemoteObject.narrow(object, AnActorHome.class);

// Obtenir un objet ayant le même type que l'interface distante
HelloWorld myHelloWorld = home.create();

// Invoquer la méthode "metier" de l'interface distante
System.out.println(myHelloWorld.playInAMovie());

Les beans à état

  • Imperceptible dans le code, uniquement dans le descripteur de déploiement
  • Avantages :
    • Permet de se passer d’un bean entité (persistance, JDBC)
    • Pas besoin de renvoyer toutes les informations à chaque fois (limite le trafic)
  • Inconvénients :
    • Besoin en mémoire
    • Déchargé/rechargé en mémoire par le serveur selon sa gestion de ressource


Ressources

Présentations