Discussion :

[storm_2000]

Bonjour,

Quand nous utilisons RMI nous sommes dans le cas suivant :
client (qui manipule Service) <-> proxy (client) ----- internet ------ proxy (serveur) <-> ServiceBean (objet qui implémente Service).
Service hérite de Remote.

Par contre, si nous utilisons des EJB, nous avons :
Service qui implémente EJBHome
ServiceBean qui implémente Service. et nous avons un fichier pour dire que ServiceBean à un liens avec ServiceHome

ServiceHome contient une méthode :
public Service create()....

Ou ce trouve l'implémentation de la classe qui utilise ServiceHome ?
De plus, côté clients, nous devons faire :

Code :

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

1
2
3
4
5
 
Object ref = ctx.lookup("MonPremierBean");
      ServiceHome home = (ServiceHome) javax.rmi.PortableRemoteObject.narrow(ref,
        MonPremierBeanHome.class);      
      Service bean = home.create();

Avons nous un Proxy derrière home et bean ?
Pourquoi appeler avax.rmi.PortableRemoteObject.narrow ?
De plus, ou ce trouve la l'implémentation de la classe qui hérite de ServiceHome ?
Ne pouvons-nous pas directement récupérer une instance de type Service au lieu de faire toutes ses lignes ?

[yashiro]

En effet le schéma d'utilisation de RMI est
client <-> ProxyClient <-> Reseau <-> ProxyServeur <-> ObjetDistant

Dans ce shéma, c'est le développeur lui-même qui crée, et expose ses objet distants (exportObject et bind).

La norme EJB 2.X a été crée pour offrir au développeur un certains nombre de service technique comme en l'Occurence l'exposition des Objets distants: Ce n'est donc plus au développeur de le faire comme avec RMI. Mais la question c'est comment la norme EJB2.x a-t-elle pévue de le faire:
Une EJB est un assemblage de 3 entités: 2 Interfaces et une classe d'implémentation.
Chaque EJB doit implémenter ces 2 interfaces et chacune des 2 étant déclinée en une version à usage local, et une version à usage distant.

Ces interfaces sont:
- la HomeInterface (EJBHome, EJBLocalHome) qui est chargée de gérer le cycle de vie d'une EJB (création, destruction, recherche, mise en mémoire virtuelle, restauration etc...): Ces méthodes ne sont pas comceptuellement liée à une EJB en particulier.

- la BuisnessInterface (EJBObject et EJBLocalObject) qui définit les méthode métiers liées à une Instance d'une EJB qui réalisent le fonctionnalités de l'application.

Lorsque le conteneur expose un EJB, il expose en fait 2 interfaces: la Home et la Buisness mais le nom de l'EJB est affecté à la HomeInterface. Donc lorsque tu effectue un lookup, tu récupères en réalité un proxy sur la HomeInterface de l'EJB. Lorsque tu appelles une méthode create (ou find) de cette HomeInterface, tu demandes au conteneur de créer (ou de rechercher) une EJB puis de t'envoyer un proxy sur la BuisnessInterface de l'EJB.

On peut donc avoir un schéma

Client <-> ProxyClientHomeInterface <-> ProxyServeurHomeIntercafe
puis
Client <-> ProxyClientBuisnessInterface <-> proxyServeurBuisnessInteface

La norme a été crée comme ça, tu ne peut pas obtenir directement la BuisnessInterface (Ce que Personnellement je trouve lourd).
Cette norme a heuresement été revue (à cause des approches plus simple des frameworks comme spring et des outils de mapping orm) et maintenant on dispose de la norme EJB3 qui à abandoné le concept de HomeInterface et tu peux désormais acceder directement à la BuisnessInterface de ton EJB.

J'espère avoir pu répondre à ta question.

[longbeach]

J'ai mis 5 etoiles à cette discussion car j'ai trouvé la réponse de yashiro excellente