Bonjour,
 
Je me suis mis au EJB3 depuis quelques semaines maintenant (Netbeans 6 beta + Glassfish v2 + PostgreSQL 8.2). J'ai assimilé un certain nombre de chose à leur sujet mais j'ai une question concernant l'architecture d'une application se voulant le plus modulaire possible. Je m'explique :
 
Un module d'une application gère par exemple un carnet d'adresse. Je n'ai eu aucune problème pour créer un EJB Entity qui gère la persistance dans une table PostgreSQL ni pour créer un EJB Session (stateless/remote) avec un set de méthodes d'interrogation. J'ai ensuite créé un client java SE qui accède à l'EJB Session à l'aide d'un fichier jndi.properties.
 
Mon problème c'est que dans cet façon de faire il faut inclure le jar de l'EJB dans le classpath du client ! Or j'aimerais une application plus modulaire, soit pouvoir redévelopper une version différente d'un module côté serveur (même interface) et pouvoir utiliser soit l'un soit l'autre lors d'un déploiement. Et ceci à la volée grâce à un gestionnaire de module.
 
J'ai tenté de placer l'interface remote dans un module et le code du stateless bean dans un autre mais le module d'interface refuse de compiler car il ne contient aucun EJB !
 
J'ai fait plein d'autre tentative mais rien de fonctionne...
 
Quel architecture serait adaptée à un tel besoin ? Peut-être faudrait-il un bus de services mais au final je ne vois pas comment me passer d'inclure le jar contenant le code métier dans le classpath du reste de l'application...
 
C'est pourtant nécessaire si l'on veut vraiment de la modularité !

Clarifions encore un peu...
 
Prenons une application simple, composée de 2 modules (une bibliothèque de prêts) :
- Gestion des clients
- Gestion des livres
 
Dans le déploiement de base les livres et les clients sont stocké dans la DB de l'application, au travers des EJB Entity et Session. Un client lourd en java SE se connecte au serveur d'application et propose l'UI principale. C'est cette architecture qui est déployée en général.
 
Un nouveau client dispose déjà d'une base de client (accessible par exemple en services web ou d'une autre manière ça n'a pas d'importance). Il serait inadéquat de migrer leur système de gestion des clients car il est partagé avec d'autres entreprises. L'idéal serait de réécrire uniquement le code métier de l'EJB Session (qui par exemple utilise des services web pour se connecter à l'autre système plutôt que de se connecter aux EJB Entity de l'application). De cette manière en déployant le nouveau module à la place du module de base l'application (une contrainte du gestionnaire de module empêche l'installation des deux modules en //) fonctionne (sans avoir à recompiler-reversioner le client et le module de gestion des livres).
 
Evidement dans ce cas-ci il paraîtrait plus judicieux de synchroniser notre DB avec l'autre système, mais si par exemple un client veux une version plus évoluée du module de gestion de leurs clients. On pourrait leur coder un nouveau module côté serveur ainsi qu'un nouveau module côté client, mais ne pas toucher au module de gestion des livres (car le nouveau client utilise les mêmes interfaces que celles du module de base, ce n'est que la partie client spécifique à le gestion des clients qui utilisent une interface plus spécialisée).

Bonjour,  
 
Je suis actuellement confronté au même problème. As tu trouvé des informations intéressantes à ce sujet ?
 
Merci

Salut,
 

 
En principe, l'injection de dependances (ou IOC, Inversion Of Control), est fait pour ca : on definit une interface de services, et au deploiement on definit dans un fichier de configuration quelle implementation concrete parmi plusieurs (implementant justement cette interface de services, evidemment) va etre utilisee.
 
Ca veut dire presque obligatoirement utiliser Spring (http://www.springframework.org/) tellement il est devenu incontournable dans ce domaine.
 
@++