EJB et WAS
Un EJB est l'implémentation de deux interfaces : le home et l'EJB.
/javaee5/ejb/EJB_FAQ.html#RMIStubsNeeded )
Donc, pour garantir une portabilité cross serveur d'application, il faut systématiquement générer les Stub rmi sur IIOP pour les clients de l'EJB.
A partir de l'interface et de paramètres dans ejb-jar.xml, le conteneur WAS est capable de générer les tei lors du déploiement du fournisseur de l'EJB.
En théorie, il faut organiser le code ainsi :
- un projet maven pour faire un jar avec uniquement les deux interfaces Home et EJB. Ce jar doit être publié dans le repository maven (interface_ejb.jar)
- un projet maven EJB, dépendant de interface_ejb.jar avec l'implémentation de l'interface de l'EJB, avec déclaration de l'EJB dans ejb-jar.xml
- un projet maven EAR incluant le projet EJB ci dessus, en charge de l'implémentation de l'EJB
- un projet maven EJB ou WAR, client de l'EJB, dépendant de interface_ejb.jar. Ce projet doit déclarer dans web.xml ou ejb-jar.xml, le souhait de référencer l'EJB via une clef java:comp/env
- un projet maven EAR incluant le client EJB ci dessus
- lors du déploiement de l'EAR de l'EJB, les stub et tei doivent être créer par WAS. Lors du bind de l'EJB dans l'annuaire JNDI, c'est en fait le Stub qui est sérialisé.
- lors du déploiement de l'EAR client de l'EJB, plusieurs options :
* les stubs doivent également être généré lors du déploiement (cela semble le cas pour la dernière génération de WebSphere 6+)
* les stubs sont récupéré par le RMIClassLoader en interrogeant le JNDI (Impossible avec WebSphere, car il utilise un annuaire JNDI de type Corba, qui n'implémente pas le
"Dynamic RMI-IIOP", voir https://glassfish.dev.java.net * générer les stub rmi-iiop via le plugin maven http://mojo.codehaus.org/rmic-maven-plugin/usage.html
Donc, pour garantir une portabilité cross serveur d'application, il faut systématiquement générer les Stub rmi sur IIOP pour les clients de l'EJB.
