[Best Practice] client ejb jar

Bonjour,

Je voulais avoir un retour d'expérience de votre part sur l'utilisation que vous faite des EJB et plus précisément de la manière dont vous générer vos jar client.

Effectivement, jusqu'à maintenant j'utilisais la tache maven maven-ejb-plugin qui permet de le faire, couplé à ejbgen (j'utilise weblogic).

Mais comment faire en EJB3?

Je trouve très surprenant qu'il n'y ai pas plus de documentation sur comment générer un client ejb jar. Car c'est pour moi la base de la conception de services. C'est à croire que les EJB sont toujours utilisés dans des applications monolithiques.

bonjour,

moi mes clients je l'ai génère comme des applications java.
j'utilise eclipse pour exporter mon projet en archive jar.

en faite j'aimerai savoir où réside ton problème ?
pourquoi utilises tu ant ou maven ?
pourquoi cela devrait il poser problème ?

je détourne un peu ta question car n'ayant jamais rencontré de problème aujourd'hui peut être ais je eu de la chance.

jusqu'à aujourd'hui j'ai pu travailler sur deux type de client, un client web avec servlet et jsp.
ce client web faisait des appels distant pour récupérer les "stub" si je me trompe pas via mon serveur tomcat sur lequel était installé easybean.

puis une application en mode console mais dans le principe, l'architecture ne différait pas tellement, mon client fait des lookup pour récupérer les ejb sur le serveur.

Qu'entends tu par application monolithique ?
toi ce qui t'intéresse c'est de savoir comment créer un client qui soit à la fois fournisseur de services ?

en quoi ton client utilisant les ejb serait il différent d'un autre ?
il reste un programme java


dans un exemple simple :

voici l'architecture d'un de mes ejb:

Code:

---

1 2 3 4 5 6

META-INF lib interfaces //contient les interface de mes bean bean //mes bean .classpath

---

et voila mon client:

Code:

---

1 2 3 4 5

META-INF //contient le manifest lib client //contient le main interfaces //contient les interfaces des beans

---

je ne sais pas si j'ai répondu à ta question

Bonjour amazoone,

Merci pour ta réponse.

Tout d'abord je parle bien de génération de client ejb jar : c'est à dire uniquement les interfaces, les objets valeurs et Exceptions en vue d'être utilisé par le client.

Pour te donner un exemple concret. Je suis au sein d'un SI, et je fourni un service EJB à d'autres applications (de 1 à n), il faut bien que je fournisse en plus de mon adresse JNDI un jar à mes clients pour qu'elles puissent utiliser mes interfaces et objets valeurs.

Mais je ne veux leur fournir que ca et surtout pas le code de mes Beans.

Je suis donc obliger de générer un jar spécifique pour les clients ne contenant que le strict nécessaire. Et pour faciliter la création de ce jar, il existe des taches (ant ou maven).

bonjour,

d'accord je pense voir ce que tu veux faire, en faite moi des la création de mon client, je duplique les interfaces que je veux utiliser. Ainsi mon ejb possède son bean et ses interfaces et mon client possède lui aussi les interfaces des ejb dans son architecture.

ça fait de la duplication de code, je ne sais pas si cela est bien de fonctionner ainsi mais du coup je n'ai pas de soucis.

donc si j'ai bien compris, toi tu voudrais que ton client puisse faire référence à des interfaces ou autres situées dans une autre archive jar ou fournies par un autre ejb ?

si c'est le cas je pense que tu dois spécifier cela dans le manifest.xml
je n'ai jamais essayé mais je sais que lorsque je faisais de l'osgi, on spécifiait dans le fichier manifest.xml les "données", packages,classes ect que l'on voulait exporter, rendre visible aux autres

à moins de dupliquer tes interfaces dans ton application cliente je ne sais pas comment faire

désolé

Bonjour amazoone,

Il sagit bien d'automatiser la génération de jar contenant uniquement les interfaces ...
Je voulais avoir des retours d'experiences de votre coté. (c'est certe peut être plus une question d'architecte ou de responsable technique).

En fait je trouve que la documentation concernant cet aspet est très pauvre et malheureusement dans une architecture de type SOA cela me semble indispensable.

bonjour,

d'accord, je suis désolé je ne sais pas.

je te dirai tout de même ceci si ça peut aider:

pour l'application en ejb2 nous utilisons xdoclet pour générer automatiquement les interfaces locale et remote

puis nous utilisons l'option de packaging proposé par eclispe ou l'on choisi les classes que nous voulons voir apparaitre dans le jar ou ear généré

mais nous utilisons uniquement les ejb 2 en accès local, donc nos clients n'accèdent jamais aux méthodes des beans et donc n'ont pas besoin de posséder les interfaces

bon courrage