Discussion :

[derek.mf]

Bonjour,

Je débute en J2EE et je me pose une question concernant les EJB et plus particulièrement l'utilisation distante de ces derniers via une application cliente.

J'ai fait de nombreuses recherches à ce sujet et très souvent, je voyais le même schéma où l'application locale dialoguait avec le serveur d'EJB distant.

Dans l'application cliente qui s'exécute en local, j'ai cru comprendre que, typiquement, on écrit un code ressemblant à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
import javax.naming.InitialContext;
 
import test.ejb.*; //Package contenant mes EJB DISTANTS
 
Properties props = new Properties();
props.load (new FileInputStream("jndi.properties"); //Je charge mon fichier de config jndi
 
InitialContext context = new javax.naming.InitialContext(props);
 
test.ejb.MonSuperBeanHome home = (MonSuperBeanHome) context.lookup("ejb/MonSuperBean";
 
test.ejb.MonSuperBeanRemote monSuperBean = home.create();

J'ai lu aussi que l'architecture J2EE multi-tiers permet de réduire les coûts de déploiement lorsqu'on change de version parce la logique métier se trouve sur le serveur... Ok, admettons.

Mais ce que je ne comprends pas, c'est que, pour faire un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
import test.ejb.*;

mon package doit bien se trouver dans mon classpath, non ???


Or, si les EJB sont uniquement sur le serveur distant, comment les avoir dans le classpath local autrement qu'en incluant les fichiers .class de mes EJB dans l'application locale ?


Si ma précédente hypothèse est exacte, je ne vois pas 36 solutions :

Solution 1 : On est obligés de créer un lecteur réseau (Windows)/créer une partition NFS (Unix) ou une autre méthode de ce type ? Je trouve que cette solution ressemblerait à du bricolage mais bon, pourquoi pas...

Solution 2 : On créé un jar de notre appli locale et qu'on y inclut les fichiers .class de nos EJB. Dans ce cas, si l'interface des EJB change, faut changer le .jar en local et donc nous ne sommes plus dans l'optique "L'architecture J2EE multi-tiers permet de réduire les coûts de déploiement lorsqu'on change de version parce la logique métier se trouve sur le serveur.

Bref, cet aspect du fonctionnement des EJB me semble obscur et si quelqu'un pouvait m'éclairer à ce sujet, je le remercie d'avance.

[ego]

La seule chose dont tu as besoin sur le client ceux sont les classes "interface" de tes EJBs (Home, Remote, PK éventuellement) et les classes présentent dans la signature des opérations de ces interfaces.
En aucun cas tu as besoin du code qui tourne sur le serveur.

Pour fabriquer le .jar qui va contenir ce qu'il faut, il faut spécifier l'éléments : <ejb-client-jar> dans ton fichier ejb-jar.xml

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Ex: <ejb-client-jar>employee_service_client.jar</ejb-client-jar>

La commande ejbc se chargera de générer ce fichier .jar que tu pourras alors distribuer sur les clients. Regardes ce qu'il y a dedans pour te convaincre.

[derek.mf]

D'accord, donc au final, si on ne change pas les interfaces Home et Remote, effectivement il n'y a rien à faire côté Client.

Si les interfaces changents (j'ajoute une méthode métier sur un SessionBean par exemple), en revanche, on a bel et bien un souci au niveau du déploiement sur les postes client, non ?

Après, tu me diras qu'en utilisant Java Web Start, le problème est réglé mais bon, finalement, les EJB ne permettent pas de prévenir tous les soucis de déploiement sur les clients.

En tout cas, merci de ta réponse, c'est tout de suite plus clair

[vallica]

Bonjour,

Je me joint à votre discussion, car je m'interroge sur le fonctionnement des EJB.

D'après ce que j'ai compris, imaginons une application J2EE sur un serveur tomcat, elle pourrait acceder via des méthodes du genre getListePersonnes(), invoquées sur l'EJB, et on pourrait developper l'EJB pour qu'il retourne une liste qu'il se procure en faisant une reqûete sur une base de données?

L'EJB ferait interface entre notre appli J2EE et la base de données c'est ca?

On peut faire tourner l'EJB sur des serveurs comme JBoss ou le serveur de Sun?

[derek.mf]

Ben, en gros, il me semble que c'est bel et bien ça !

[kurupt76]

les ejb ne tournent pas sous tomcat. il y aussi JoNas , un serveur d'appli J2ee .

en utilisation persos, je me tournerai plutôt vers hibernate ( qui lui peut tourner sous tomcat) .

Le team d'hibernate participe à la spec des ejb 3.0 qui vont bientôt sortir.

[vallica]

tu veux dire remplacer les EJB par hibernate?

[raj]

Juste pour dire en passant ,
A la base EJB est une norme qui devait contribuer au développement
d'une industrie COMPOSANTS et faire évoluer le développement
d'une application d'entreprise vers un assemblage de composants .

Aujourd'ui n'ayant pas réussi à assouvir ce désir , un forcing marketing
a été fait sur les EJB et beaucoup les utilisent pour faire de la persistance ,
or les EJB n'ont pas été concu pour ca à la base (logique trop intrusif ) .

Je conseille à quiconque qui penetre dans l'univers J2EE de se tourner
vers Hibernate pour la persistance , EJB 3.0 s'appuye sur Hibernate pour
le coté persistance ( bien sur Hibernate n'est qu'un sous-ensemble de la spec EJB 3.0 ) .

Voilà

[vallica]

ok, merci pour l'info !

[kurupt76]

un autre avantage (pour une utilisation perso) il me semble c'est que hibernate peut être déployer sous tomcat .

avec ejb c Jonas et Jboss et le chargement des classes est plus compliqué :

packaging des projet en ear-jar-war , donc il faut tâter du ant