Version imprimable
Un accès "local" à un EJB est considéré à partir du même EAR.
Par exemple d'un module WAR à un module EJB-JAR tu peux faire du local, tant qu'ils sont dans le même EAR.
Quand tu as du remote, ça veut que ton module WAR n'est pas dans le même EAR ... ça peut avoir ses raisons, mais c'est peut-être un défaut de conception. Ou alors quand tu as un client riche distant, genre appli SWING, qui invoque les EJB de ton serveur sur RMI.
Je crois avoir compris : les accès en local ne peuvent s'effectuer que lorsque le client est sur la même JVM que les EJB, donc en gros sur le même ordi non ?
C'est surtout "sur le même EAR" ... et par corrélation, la même JVM.
Tu as été plus rapide que moi :mrgreen:
D'accord je comprends mieux... Mais alors comment savoir si les modules WAR et EJB sont dans le même EAR (=fichier/archive si j'ai bien compris) ???
(désolé si mes question peuvent paraitre débutantes.. mais en effet je débute :aie: )
Un EAR est un ZIP qui contient le WAR et l'EJB-JAR qui sont eux aussi des zip.
L'EAR contient un descripteur de déploitement (fichier XML) qui référence tous les modules de l'EAR. Il peut y avoir 40 modules WAR et 20 modules EJB-JAR, par exemple ... pour le FUN :mrgreen:
Il n'y a jamais de question bête !Citation:
Envoyé par VinceSSJ
Super j'ai bien cerné ce qu'est un EAR, je soupçonnais même pas son existence jusqu'à présent :aie:
Merci pour ton aide ! :P
Je suis sous Netbeans et je vois bien mes WAR et EJB côte à côte avec les interfaces entre eux. Mais maintenant comment voir si ces modules sont dans un seul et même EAR ou si WAR et EJB sont dans 2 EAR différents ?
tu peux faire une capture d'écran de ton NetBeans.
Peut-être n'as-tu simplement pas ouvert l'EAR mais simplement les modules qui le compose.
Regarde à quoi ça devrait ressembler :
http://netbeans.org/kb/docs/javaee/j...ntapp-ejb.html
Merci pour le lien.
En réalité, pour l'instant je travaille directement sur le serveur sur lequel l'application est déployée et tourne 24/24 puisqu'elle est en production. Je ne peux donc pas faire ce que je veux.
Tout ce que je peux dire c'est que Netbeans est ouvert sur l'application qui est en train de tourner.
Bref, je vais regarder la page que tu m'as donnée et je retiens au courant :D
le cas est typique, on fait une analyse en prévoyant très large, la couche métier pourrait être utilisée par une autre application, voir invoquée à distance par un client lourd (swing par exemple).
dans ton cas, si les ejb ne servent qu'à une application web, l'usage des interfaces Local serait un plus (passage par référence plutôt que serialisation/deserialisation...
en fait, avec certains serveurs (jboss en tout cas), on peut paramétrer l'application et faire un passage par référence même sur du Remote, regarde pass-by-reference si tu veux faire un test de performance.
ceci dit, avec les ejb, on a vite fait de perdre en performance par des aller/retour entre le conteneur web et le conteneur ejb, d'où l'intérêt du pattern Facade.
Effectivement, si je cite la doc techniques de l'appli :Citation:
Envoyé par OButterlin
"Les servlets sont interrogés directement par les clients. Tout le code métier intéressant se trouve au niveau des EJB. Ce la permet d'envisager une réutilisation ultérieure dans d'autres applications, cela permet aussi de permettre la séparation de l'application en 2 (web et EJB). De plus, c'est le serveur d'application qui gère les instances des EJB, leur accès et leur existence.
Les EJB implémentés sont des EJB sans état
[...]
Pour faire le lien entre l'application Web et les EJB, une bibliothèque contenant les classes communes a été implémentée; Elle contient les interfaces permettant de retrouver les EJB et aussi les objets Java [...]"
Par contre, je ne vois aucune sérialisation/désérialisation dans le code. Les servlets accèdent directement via les interfaces. Pourtant les interfaces sont Remote ?! Comment expliquer ça ? Y'a pas contradiction ?
Bref, effectivement ici les EJB ne servent qu'à lappli Web..
GlassFish permet ce passage par référence aussi ?Citation:
en fait, avec certains serveurs (jboss en tout cas), on peut paramétrer l'application et faire un passage par référence même sur du Remote, regarde pass-by-reference si tu veux faire un test de performance.
ceci dit, avec les ejb, on a vite fait de perdre en performance par des aller/retour entre le conteneur web et le conteneur ejb, d'où l'intérêt du pattern Facade.
Oui la lenteur de l'application pourrait peut être venir de là.
Mais elle vient surement des requêtes de la BD aussi.
Le mécanisme de serialization est transparent, tu ne le verras pas.
Pour les requêtes base de données, c'est du jpa ?
AHHHHH Mais si en fait !!! J'avais pas fait attention, mais dans la bibliothèque interfaces, il y a tous les objets utilisés par les Servlets et par les EJB (Connexion, Tâches, etc..), et bien tous ces objets sont sérialisables !!!! Ce qui confirme qu'il puisse y avoir un manque de performance à ce niveau
Sinon, non pas de JPA utilisé. Tous les accès aux bases sont fait en JDBC.
Même si je n'en suis pas encore là : est-il simple de transformer un accès Remote en accès Local niveau EJB et Servlets ? Avec un accès en Local j'imagine que toute les bibliothèque des interfaces devient inutile ?
Oui très facile de basculer sur du Local
Il y aurait un tuto pour voir comment faire ?
Je pousse mon raisonnement en disant : en réalité je en vois pas pourquoi la personne a développé l'appli avec des EJB.. Selon elle c'était pour envisager une réutilisation future de l'appli par un client lourd (type SWING). Seulement ça n'a jamais été le cas et l'application n'a jamais été touchée depuis 2008 : tout le monde y accède par son navigateur via l'intranet de la société.
Sachant que l'appli accède à d'autres BD situées sur d'autres serveurs pour aller chercher ses données, est ce que vous croyez que ça nécessite obligatoirement une utilisation des EJB ?
Conclusion, dans ce cas qu'est ce que je pourrais prendre à la place des EJB ?
Dans tous les cas remplacer les accès distant au locaux sera déjà un bon début il me semble.
PS: j'aimerais aussi modifier le titre de mon topic parce que là il est plus du tout explicite lol mais comment faire ?Je n'arrive pas à éditer mon premier message
Un EJB n'a pas pour seule propriété d'être accessible à distance.
C'est aussi transactionnel ;
C'est adapté à de fortes montées en charges sans (trop) de risque d'avoir un OutOfMemory ...
Bref, les vertues des EJB sont largement méconnues. :calim2:
Tu devrais chercher un peu documentation à ce sujet.
Tiens par exemple :
- http://onjava.com/pub/a/onjava/2005/...ring-ejb3.html
- http://www.roseindia.net/ejb/FeaturesOfEJB3.0.shtml
- http://www.theserverside.com/news/13...ures-in-EJB-31
Personnellement j'ai longtemps cru (par méconnaissance) aussi que les EJB étaient des usines à Gaz (à l'époque des EJB 2), mais maintenant que j'y ai goûté (depuis les EJB 3.x) je ne peux plus m'en passer.
Réécrire tout la couche d'accès au données est risqué, à ta place, j'essayerais plutôt d'optimiser l'existant.
Fait une étude pour voir où se situe les temps de réponse les plus lents et corrige le code ou l'architecture à cet endroit.
Si les requêtes à la base de données sont lentes, regarde si la création d'index pourrait accélérer le traitement.
Bref, il y a pas mal de chose qu'on peut faire...
Merci pour ces précisions fxrobin, je vais regarder ça.
OButterlin, c'est exactement ce que je pensais !! Pour les index, c'est la première chose que j'ai demandé à mon responsable, et en effet aucun index n'a été créé. Et vu la longueur de certaines requêtes, et le nombre de colonnes/lignes dans chaque tables, si le SGBD parcourt les lignes 1 à 1 c'est sûr que ça doit coûter du temps !
Bref, donc j'abonne la réécriture de la couche métier alors. Déjà que j'ai encore du mal à comprendre certaines relations, alors si je m'amuse(ou pas) à tout récrire.. lol
Par contre, juste le fait de passer d'accès distants à locaux, est-ce lent à faire ? Et surtout est ce que le gain de performance pourrait vraiment être significatif ? Je n'ai aucun moyen de voir ça..
En fait, pour le moment j'en ai déduit ça :
Les lenteurs sont situées au niveau de l'interface, soit quand on charge de nouvelles ressources (d'un technicien par exemple), soit quand on charge un récapitulatif, ou bien (et surtout) quand on glisse une tâche (ligne d'un tableau) dans l'emploi du temps (grille pré construite) : toutes ces manip' prennent plusieurs secondes, jusqu'à ~10secondes chacune..
Donc les lenteurs sont logées soit : au framework (EXT JS 2.1) trop lourd, soit au niveau des communication Servlet/EJB, soit au niveau des requêtes.. Si ça se trouve c'est même les 3 !
Ce que je sais aussi c'est que mon responsable avait supprimé il y a quelques semaines toutes les anciennes données qui ne servaient plus à rien dans les tables, et à partir de là ils avaient déjà eu de meilleures performances.
Pour l'instant, j'essaie d'identifier ce que toutes ces fonctionnalités (construction de l'emploi du temps, récapitulatif, etc..) ont en commun afin de voir ce qui ralentit le bazar