Discussion :

[tinico]

Bonjour a tous, et merci a ceux qui voudrons bien donner leur avis !

Voila, je suis en train de travailler sur un projet déjà existant, et je dois améliorer une chose ! J'ai déjà quelques idées, mais j'aimerais avoir le point de vue de connaisseurs plus avertis que moi !

Voila, mon projet porte sur les EJB, et une servlet.

(1) - Nous possedons un ensemble d'EJB se connectant chancun à une base de donnée pour en sortir des données.
(2) - Nous avons un EJB principal qui, une fois appelé, appel une servlet, qui elle appel tous les EJB décrient en (1). Les données retournées sont concaténés et retournés a l'EJB principal.

Ceci fonctionne, mais mon projet concite a introduire un généricité dans tout cela, c'est a dire une servlet (dans un premier temps) qui pourra etre appelée par d'autres EJB principaux pour se connecter a un ensemble d'EJB (dont les JNDI est passé en parametre) et retournée les retour de chaque EJB (1).

Voila, le probleme, c'est, par exemple, le fait qu'un EJB est appelé de la manniere suivante :

Code :

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

1
2
3
4
Context ctx = new InitialContext();
NomEJBHome home = (NomEJBHome)PortableRemoteObject.narrow( ctx.lookup(JNDI_NAME), NomEJBHome.class );
ld = home.create();

Le probleme est assez clair ici au niveau de la généricité, il n'y en a pas !!
Ceci est un exemple parmis d'autre, j'aimerais donc savoir jusqu'ou je peux pousser la généricité à votre avis, et peut etre certains avis sur la réalisation !!

Précision très importante, je travail sur la version 1.4 de JAVA, et donc, pas de typage possible ( classeTest<type> )

Voila, merci de donner vos avis, vos idées, toutes les idées, meme les plus farfeluent suront les bienvenues !!!

Merci d'avance !

[tinico]

Bon, d'après ma reflection personnel , je pense que je fait de passer par une servlet n'est pas forcément judicieux...

Les données devant etre le plus sécurisées, ce n'est peut etre pas la bonne méthode !!

Cela dis, je ne peux evidement as passer par l'EJB lui meme car la création de threads est interdite par la spec des EJB, il faut donc executer un code hors conteneur d'EJB !

qu'en pensez vous ? des propositions ?

[tinico]

Connaussez vous un autre moyen qu'une servlet pour executer un programme appeler par un EJB hors du conteneur d'EJB ??

Sinon, j'ai pensé a faire une servlet pour pouvoir communiquer et executer des threads hors EJB, et comuniquer avec cette servlet avec JMS... Ce qui me permet d'envoyer plus que de simple String... Qu'en pensez vous ???

HELP ME PLEASE !!

[grishka]

Effectivement la servlet n'est pas un choix judicieux car elle n'est pas prévue pour cela. Remplace ta servlet par un objet distant accessible via RMI. Un simple programme java permettra de l'exécuter.

[tinico]

Merci beaucoup pour ta réponse, depuis le temps que j'attend !!!

Je suis désolé, je ne connais pas beaucoup les structure java (je suis que stagiaire ), peux-tu m'expliquer comment créer, utiliser (invoquer) un objet distant accissible par RMI comme celui que tu parles ? Je précise que je travail sur un serveur d'application Weblogic...

Si tu pouvais me donner quelques indices ou pistes que je puisse commencer mes recherches, ça serait vraiment sympa !!!

En tout cas, merci beaucoup !

[tinico]

Je viens de travailler un peu sur RMI !!

C'est peut etre ce qu'il me faut, mais est-ce possible de lancer le serveur (contenant la class distante) dans weblogic ?

Et, si j'appel une méthode distante a partir d'un EJB, la méthode ne sera pas exécutée dans le conteneur d'EJB mais bien sur le serveur distant n'est ce pas ??? Je demande confirmation parce que c'est très important !

Merci en tout cas !

[grishka]

C'est peut etre ce qu'il me faut, mais est-ce possible de lancer le serveur (contenant la class distante) dans weblogic ?

Ce n'est pas très clair : le programme appelé par l'EJB (celui que tu as transformé en serveur RMI) doit-il s'exécuter dans la JVM du serveur weblogic ou dans une JVM séparée ?

[tinico]

Il devra s'exécuté dans la meme JVM que celle de weblogic vu que la portlet qui appel l'ejb, l'ejb lui meme, et la classe réalisant les threads (donc le serveur RMI) devront etre déployé sur le meme serveur weblogic.

en fait, je cherche juste a exécuter des threads a partir d'un EJB, mais ceci est impossible (a parement) directement, je voulais donc passé par une servlet, mais il est (a parement) déconseillé de faire des thread dans une servlet ! Et donc, il me faut peut etre RMI comme tu l'a dis !! Mais est-ce que ça répondra bien a ma problématique ?

Merci en tout cas !

[grishka]

finalement un serveur RMI n'a pas d'intérêt ici Tu peux intercaller une simple classe java entre tes EJB principaux et tes EJB d'accès au donnée. D'après ce que tu décris, c'est simplement une classe utilitaire permettant de récupérer un ejbhome en fonction d'un nom JNDI. Pour le downcast tu ne pourras rien faire, mais le narrow peut se faire de manière générique (avec Class.forName("NomEjbHome"). Le cast devra se faire dans l'ejb principal. De plus je doute que les types génériques t'aident ici. Maintenant tu peux intervenir au niveau conceptuel, en essayant de factoriser des services dans une interface commune... Sinon je t'invite à jeter un oeil au framework Spring (http://springframework.com), qui permet de découpler les composants avec le pattern d'injection de dépendance, c'est peut être ce que tu souhaites réellement.

Autre point qui semble te poser problème : je ne vois pas pourquoi il y aurais dans ce cas la création d'un nouveau thread, la méthode étant appelée par le même thread que celui de l'EJB. Par contre si la méthode est statique ou que tu choisis de créer un singletion, attention au multithreading. Le plus simple étant de encore de créer une instance à chaque fois.

[tinico]

Ralala Merci beaucoup pour tout ça !!!

En fait, je cherche a faire des threads car je possede deja un ejb par base de donnée a interoger !!!

Et donc, je voudrais que l'ejb principal appel tous ces ejb dans des threads afin que les requettes se face en parrallele pour ne pas additionner tous les temps d'accès aux bases !!

Sinon, si je passe par une classe intermédiaire, il faudra que je fasse un import dans l'EJB principal, et donc, elle sera exécuté dans le conteneur d'EJB, et donc, pas de threads possible !

[grishka]

ok c'est plus clair

effectivement dans la spécification JEE, c'est le conteneur qui à la responsabilité de gestion des threads. Je ne sais pas si c'est vraiment interdit, mais il faudrait gérer proprement l'arrêt/redémarrage d'une appli sinon gare aux fuites mémoire. Mais alors comment réaliser des traitements concurrents au sein d'un ejb de manière propre ?
1) Il est peut être possible de réserver des threads dans le pool du conteneur, qui seraient dédiés à l'appel d'un ejb d'accès aux données. Dans l'ejb principal, il faudrait encore pouvoir accéder au pool de thread...à vérifier.
Ensuite tu n'aurais plus qu'à associer un traitement par thread et des join() pour la synchro...
2) En utilisant JMS, ou des message driven beans (dans ton cas, les ejb d'accès aux données), ce qui te permettra de faire des appels asynchrone. Mais ensuite vient le problème de la synchronisation des résultats (le regroupement des données, la gestion des erreurs, ...) ! Il faudrait un mécanisme de listener (l'ejb lance les traitements et s'enregistre en tant que listener sur la fin des traitements)
tu auras peut être la solution ici :
http://www.devx.com/Java/Article/20184/0/page/1

3) utiliser une JVM différente (donc on en revient au serveur RMI )

[tinico]

Merci beaucoup !!

J'étais justement en train de voir les JMS, ça me rassure de te voir en parler !!!
D'après ce que j'ai compris, les EJB MDB (messaging bean) sont des EJB qui écoutent sur une queue de message JMS et qui s'execute lors de la reception d'un message !!!

Ceci pourrait etre la solution que je cherche, car en fait je doit aussi passer des arguments à ces ejb et les messages pouvant etre des objets, ceci peut etre cool !!!

Je dois donc créer une queue, et de mon EJB principal, j'envois plusieurs messages, un par ejb a executer !! Les ejb s'executent et renvoi, via JMS le résultat à l'EJB principal !

Par contre, est ce que le traitement de tous les ejb se fera bien en parallele ??? Et, dois-je faire une queue par ejb ??? (j'espere que non)

Dis moi si j'ai dit des bétises !!

Merci beaucoup !! Heureusement que tu es la !!