Bonjour,
 
Je désirerais délocaliser ma logique métier sur un serveur distant et l'encapsuler dans des EJBs Session Stateless.
 
Donc, en gros, j'ai un client d'EJB et mon serveur d'EJB séparés par un réseau local.
Je configure donc mon lookup JNDI de façon à pouvoir invoquer mon EJB:
 
  try {
    Hashtable env = new Hashtable();
   env.put(Context.INITIAL_CONTEXT_FACTORY,com.ibm.websphere.naming.WsnInitialContextFactory);
   env.put(Context.PROVIDER_URL, iiop://remote_host:2809  );
   context = new InitialContext(env);    
  }catch(IOException ex){}    
  catch(NamingException ne) {}
 
Jusque là, pas de problème.
 
Ensuite, j'essaie de récupérer ma Home interface de mon EJB Session Stateless :
 
  try {
    Object objref = context.lookup(name);
    MyHome myHome = (MyHome) PortableRemoteObject.narrow(objref, MyHome.class);
    return myHome;
  } catch(NamingException ex) {}
 
               MyEJB anEJB = myHome.create();
               // code applicatif utilisant les méthodes métiers de l'EJB (ex : anEJB.doSomeWork(....))
 
Enfin, c'est le code qui est fourni un peu partout sur le Net. Mes questions sont là:
- qu'est ce que la classe MyHome sur le code ci-dessus ? c'est la home interface de mon EJB distant ? Si oui, cela voudrait dire qu'il faut déclarer l'interface Home de mon EJB du côté client et Pourtant ce code doit se trouver du côté client EJB ? Il faut encore déclarer son interface Home du côté client ?
- Faut il récupérer la home interface et faire un create() dessus côté client ou faire le create() côté serveur puis récupérer juste la remote interface ?
- Serais-je passé à côté d'un pattern qui dédié à l'invocation à distance ? Je ties à préciser que j'utilise les patterns Delegate, Factory et ServiceLocator du côté client-EJB.
 
Merci de votre aide.
(j'espère avoir été clair dans mes explications   )

quand tu crées tes EJB sur le serveur, tu récupères un jar à utiliser sur le client. il contient nottament les interfaces Home et Remote.
Bien sûr, ce ne sont que des interface => tu n'as pas à les trouver, juste à les "récupérer" par JNDI.
L'instance de l'objet côté serveur est crée par le container EJB. C'est jamais toi qui le créé !
 
Mais bon, tu devrais trouver ce genre d'explication dans n'importe quel petit tuto EJB ... si tu comprends pas ca, j'ai peur que tu ne comprennes pas grand chose à ce que tu fais

J'ai peur de pas avoir été clair et je voudrais être sûr de ce que tu me dis parce des EJBs, ça fait un petit moment que j'en bouffe matin midi et soir.
 
Lorsque tu crées ton EJB (Session Stateless pour faire au plus simple). Tu déclares tes interfaces home (qui déclare la signature de tes méthodes métiers) et remote et qui ne possèdent (on est d'accord ?) aucun code métier. Tu codes aussi l'implémentation de ton EJB avec tout ton code métier.
Tu packages tout ça dans un jar avec le Manifest qui va bien et tes fichiers de déploiement (ejb-jar.xml et le fichier pour ton serveur d'applis) où tu déclares les noms de tes interfaces (ejb-jar.xml) et le nom JNDI de ton EJB (fichier de déploiement pour ton serveur d'appli). Parles-tu de ce "jar" là ? Parce que jusqu'ici, on est d'accord, c'est le B.A BA des EJBs.
Par contre, là où je ne suis plus d'accord (et p'tre que je suis passé à côté d'un truc là..) c'est que ce jar est déployé coté serveur ! (d'EJBs).
Celui-ci va faire le mapping entre le nom JNDI et l'EJB et va pouvoir fournir en instances tout client qui fait un lookup sur ce nom JNDI.
 
Et tu me dis qu'il faut mettre aussi un jar contenant les interfaces de l'EJB côté client ?
 
Ps : j'ai jamais dit que c'était le client qui créait un EJB ! je suis d'accord que c'est le serveur qui met à disposition une instance d'EJB. Je parlais de la méthode create() qui permet de récupérer, côté client, l'interface remote de ton EJB permettant d'accéder à tes méthodes métier.

j'ai pas bcp d'expérience en EJB, donc je ne sais pas comment ca se passe avec tous les conteneurs. Avec l'implémentation de référence de Sun, y a 3 ans, quand tu créais l'ear (l'archive qui contient toute ton appli, y compris les jar contenant tes ejb), tu pouvais demander à ce qu'il te créer un "jar client".
Je me souviens plus en détail, mais le jar contenait au moins les interfaces remote et home (faut bien que ton client les ait à dispo pour pouvoir les utiliser, sinon il va pas compiler !) et j'imagine qu'il contient aussi les stubs rmi.

Ok.
En effet, on vient de me confirmer qu'il faut créer un jar côté client qui ne contient que les interfaces home et remote (et non pas le jar entier généré pour le côté serveur).
 
Nous sommes entièrement d'accord sur le fait que c'est évidemment pas le client qui crée une instance d'EJB mais le serveur avec tous les services qui vont bien (transactionnalité, persistance le cas échéant ...)
Bref, je vais pas épiloguer sur les EJBs, y'aurait pas mal de trucs à dire ...
Bref, je tiens quand même à dire que la précision que tu m'as donnée sur le fait de déclarer les interfaces côté client n'est absolument pas dans n'importe quel tutorial EJB !    
ou alors on ne parlait toujours pas du même jar...

Je viens de voir ta réponse : ok, nous sommes d'accord.    
Mon incompréhension venait du fait que, jusqu'à présent, tous mes EJBs et client d'EJBs étaient sur la même machine et que les exemples de code pour une invocation distante ne sont pas légion.
Merci !

you're welcome

 
tu as inversé remote et home
remote (extends EJBObject) : interface qui fournit les méthodes métiers
home (extends EJBHome): interface qui te permet de créer, trouver, supprimer un bean

tout à fait !    
J'ai inversé dans la précipitation.
d'ailleurs je me contredisais tout seul par rapport à mon premier post !
(dans le code, je fais bien un create() sur mon interface home...)