Je crois que l'idée de "répartition", plutôt que la répartition de charge entre plusieurs machines, signifie plutôt "distribution".
Les EJB sont des composants distribués, dans le sens où on peut invoquer leurs méthodes à distance, via RMI.
L'idée est donc dans une application J2EE, de séparer les différentes couches applicatives, et de placer par exemple les applications web (JSP/Servlets) sur une machine, et les EJB sur une autre, pour améliorer la scalabilité de l'application.
On obtient ainsi un environnement n-tiers, avec une machine pour Apache, une machine pour les applications Web, une machine pour les EJBs, une machine pour le SGBD, etc etc...
Ca permet également de répondre à des problématiques de sécurité, comme par exemple interdire l'accés à la machine "EJB", qui contient le métier de l'application, à partir de la machine Apache.
Pour les perfs voir les benchs déjà cités qui montrent que l'introduction de l'interface local ne change pas grand chose? D'autre part, Fleury a déjà dit dans plusieurs papiers et docs que JBoss optimise les appels locaux.
ha JBoss le prend peut etre en compte, effectivement. Par contre je rappelle que JBoss n'a pas été certififié compatible J2EE 1.3.
Argh ! Utilise donc XDoclet, malheureux ! Une seule classe à coder par Bean. Faux vraiment être un troll pour coder ça à la main.
c'est clair... WSAD le fait aussi
mais bon justement, on a été obligé de fabriquer de nouveaux outils pour résoudre les problèmes soulevés plus haut... C'est comme le pattern Session Facade, on l'utilise à cause des problèmes de granularité des Entity Beans (en appel distant, on fait des getAttribute, on devrait pouvoir faire des getObject)...
Fleury dit exactement le contraire, et j'ai plutôt tendance à le croire lui, désolé.
ha... ben Fleury il est pas forcément impartial hein... ;-) Si j'étais toi je m'intéresserais aussi aux retours d'expérience des utilisateurs, et pas qu'aux dires des éditeurs... :-)
Un exemple serait le bienvenu...
faudrait que je retrouve ca, j'ai lu un papier quelque part là dessus, j'ai pas expérimenté moi même là dessus... je me base sur des retours d'exp désolé...
Tout dépend de ton niveau d'acceptance, et des perfs dont tu as besoin effectivement, ca peut convenir... Mais j'ai eu trés peu d'échos favorables à ce sujet, en général ce n'est pas trés glorieux... Si tu as un lien pour tes benchs, ca m'intéresse!
Sinon je ne critique pas J2EE, si c'est moi que tu visais, je critique les EJB Entity Beans CMP (et BMP). Je trouve les Session Beans extremement utiles. Au passage je demande confirmation pour les jointures avec les EJB 2, là aussi si tu as une info je suis preneur :)
C'est-à-dire ? Le surcout de l'architecture EJB vient en gros exclusivement de l'aspect RMI. La persistence ne pose en général pas de problème.
pour les CMP:
empreinte mémoire des EJB, et surtout pas d'héritage, c'est un comble, alors qu'on utilise un langage objet!
la norme EJB 2 a pas mal apporté, heureusement:
- interfaces locales comme on a dit
- EJBQL (langage de query)
- relations entre les EJB, 1-1 1-n n-n (CMR = Container Managed RelationShips)
Pourrais-tu développer, ça ne me semble pas très clair, ton truc. Sur le client, tu as le Home et le Remote, sur le serveur le Bean lui-même plus de l'enrobage propre au serveur.
par exemple, tu as besoin dans certains cas de coder une classe ObjectKey pour gérer la clé primaire... ca fait 4...
Ba oui, c'est le but de CMP. Si tu veux du contrôle tu fais tu BMP. Sinon, les find sont codés en EJBQL, pas en SQL.
oui bien sur, si le code SQL généré me convenait ca serait trés bien, mais je pense que ce n'est pas assez optimisé... il me semble que le code généré ne fait pas de jointures tout seul par exemple...
Tu sais, comme le dis Boubou, avant les EJB 2.0 les serveurs d'applications faisait déjà souvent des appels locaux en interne, ce qu'a fait Sun c'est inclure cette possibilité dans la spec. Donc niveau perf, c'était déjà +- idem.
ha... je demande confirmation, tu as un lien?
Je ne trouve pas ça dérangeant d'avoir plusieurs classes par EJB, tu as les diverses interfaces implémentées (EJBHome, ...) et tu as l'implémentation proprement dite (qui est générée automatiquement). Effectivement ça bouffe de la mémoire, mais en contre partie ça rend pas mal de service.
ha... moi avoir 4 ou 5 classes par objet métier, quand tu as un modèle de 300 objets, je trouve ca un peu génant... quand tu vois que tu n'en as qu'une à coder avec JDO...
En plus les services rendus par le conteneur d'EJB, tu les as en utilisant des Session Beans, suffit de placer JDO (ou des DAO) derrière ces Session Beans, et tu rends ton modèle objet beaucoup plus simple, et tu diminues l'empreinte mémoire de ton application
De toute façon, en pratique, tout le monde fait du Session Bean + JDBC, aprés s'être cassé les dents sur les Entity Beans...
Par contre je ne comprends pas pourquoi tu te plains que le SQL soit généré tout seul dans les CMP (tu peux utiliser des BMP si tu veux), puis juste après tu te plains de devoir utiliser du SQL pour les finders ...
je ne me plains pas que le SQL soit généré tout seul, je me plains que le SQL généré tout seul soit pourri... et qu'en conséquence on soit obligé de tout coder dans les finders... où est alors l'utilité des CMP je vous le demande... (par rapport aux BMP)
Effectivement, les EJB sont gourmands en ressources, et il ne faut pas les utiliser pour de petits projets. Mais ils font gagner pas mal de temps, ont des performances très satisfaisantes et surtout ont une très bonne scalability lorsqu'ils sont utilisés au bon endroit.
Pour les performances, si on parle des EJB Entity Beans, elles sont loin d'être satisfaisantes!
Depuis les EJB 2 les choses se sont arrangées (appels locaux entre les Session et les Entity, avant il fallait passer par RMI), mais tu as toujours au moins 3 classes par EJB, voir 4 ou 5, et l'empreinte mémoire d'un objet métier modélisé par un Entity Bean est énorme! Sans parler des requêtes SQL générées dans les CMP, où on n'a pas de contrôle, on est obligé de coder les méthodes find en SQL...
On peut aussi parler de l'absence de notion d'héritage avec les Entity Beans...
Pour l'accès aux bases de données, tu as typiquement le choix entre les EJB, JDBC dans les servlets, ou (dans un futur proche) JDO (Java Data Object, un nouveau moyen de gérer la persitence, plus léger que les EJB).
JDO (Java Data Objects) n'est pas directement comparable aux Entity Beans CMP, puique suivant l'implémentation utilisée, on peut gérer la persistance dans une base de données relationnelle, mais aussi dans une base de données objet, dans du XML, etc etc (la spec JDO n'est pas restrictive)
pour plus d'infos, www.libelis.com
Personnellement dans un projet de taille moyenne sur lequel je travail, j'utilise des servlets pour le Controller, des query appelés par JDBC comme Model et les JSP comme View. (Je déconseille l'utilisation de servlet comme view, parce que l'HTML hardcodé ça pue quand même ...)
eclipse avec le plugin CDT (C/C++ Development Tools) tu auras:
- coloration syntaxique
- completion syntaxique, templates de code (du style du tappes if et il te génère le bloc if{}else{})
- bouton make ce que tu veux sur le projet, tu peux choisir le compilateur que tu veux
- déboggueur local (pas de debug distant aujourd'hui, ca va venir), ca a pas l'air trés stable
- travail en équipe avec CVS intégré à eclipse
le plugin est pour eclipse 2.0.2, tu auras les key bindings emacs avec eclipse 2.1, mais il faut attendre une mise à jour du plugin CDT qui fonctionne sur eclipse 2.1
sinon pour installer eclipse sur une debian, il te faut juste un jre/jdk, et télécharger le zip eclipse-SDK pour linux, c'est tout
WSAD c'est plus qu'une version "commercialisée", c'est eclipse + des plugins développés par IBM, par exemple le support des JSP, avec complétion syntaxique, des outils pour générer des EJB CMP à partir d'une base existante, etc etc...
et pour info, WSAD 4 est basé sur eclipse 1, et WSAD 5 sur eclipse 2.
regarde du coté de la techno objectspace, tu verras un "équivalent" des EJB CMP (qui ne sont d'ailleurs quasiment jamais utilisés, voir les différents site j2ee pour savoir pourquoi...)
Résultat : interface avec CVS qui fonctionne à moitié, bécane enorme pour faire tourner le serveur d'app, galère diverses...
quel rapport entre WSAD et le serveur d'app? tu fais tourner le serveur d'app sur la machine de dév???? sinon si tu utilisés WTE (WebSphere Test Environment effectivement faut une grosse bécane...)
sinon j'utilise CVS avec Eclipse 2 ca fonctionne trés bien!
à noter que WSAD 4 (4.0.3 la dernière) est basé sur Eclipse 1, il faut attendre WSAD 5 pour Eclipse 2, il y aura beaucoup de bugs corrigés et des fonctionnalités ajoutées (on pourra enfin utiliser les plugins pour eclipse 2)...
les plugins eclipse: http://eclipse-plugins.2y.net/eclipse/(...)
enfin, je pense qu'un petit paragraphe sur les EJB, décrivant les Session et les Entity Beans (et eventuellement les Message Beans) ne ferait pas de mal...
# Re: Pourquoi choisir JOnAS plutôt que JBoss ?
Posté par Guillaume Carre . En réponse à la dépêche Pourquoi choisir JOnAS plutôt que JBoss ?. Évalué à 1.
"Workshop" c'est l'environnement de développement de BEA.
# Re: Gaim 0.68
Posté par Guillaume Carre . En réponse au journal Gaim 0.68. Évalué à 2.
[^] # Re: Xbox: jour de l'indépendance
Posté par Guillaume Carre . En réponse à la dépêche Xbox : jour de l'indépendance. Évalué à 3.
[^] # Re: Matrix reloaded
Posté par Guillaume Carre . En réponse au journal Matrix reloaded. Évalué à 3.
[^] #
Posté par Guillaume Carre . En réponse à la dépêche JOnAS 3.1 est sortie. Évalué à 1.
Les EJB sont des composants distribués, dans le sens où on peut invoquer leurs méthodes à distance, via RMI.
L'idée est donc dans une application J2EE, de séparer les différentes couches applicatives, et de placer par exemple les applications web (JSP/Servlets) sur une machine, et les EJB sur une autre, pour améliorer la scalabilité de l'application.
On obtient ainsi un environnement n-tiers, avec une machine pour Apache, une machine pour les applications Web, une machine pour les EJBs, une machine pour le SGBD, etc etc...
Ca permet également de répondre à des problématiques de sécurité, comme par exemple interdire l'accés à la machine "EJB", qui contient le métier de l'application, à partir de la machine Apache.
[^] # Re: Avantages ?
Posté par Guillaume Carre . En réponse à la dépêche JOnAS 3.1 est sortie. Évalué à 1.
Pour les perfs voir les benchs déjà cités qui montrent que l'introduction de l'interface local ne change pas grand chose? D'autre part, Fleury a déjà dit dans plusieurs papiers et docs que JBoss optimise les appels locaux.
ha JBoss le prend peut etre en compte, effectivement. Par contre je rappelle que JBoss n'a pas été certififié compatible J2EE 1.3.
Argh ! Utilise donc XDoclet, malheureux ! Une seule classe à coder par Bean. Faux vraiment être un troll pour coder ça à la main.
c'est clair... WSAD le fait aussi
mais bon justement, on a été obligé de fabriquer de nouveaux outils pour résoudre les problèmes soulevés plus haut... C'est comme le pattern Session Facade, on l'utilise à cause des problèmes de granularité des Entity Beans (en appel distant, on fait des getAttribute, on devrait pouvoir faire des getObject)...
Fleury dit exactement le contraire, et j'ai plutôt tendance à le croire lui, désolé.
ha... ben Fleury il est pas forcément impartial hein... ;-) Si j'étais toi je m'intéresserais aussi aux retours d'expérience des utilisateurs, et pas qu'aux dires des éditeurs... :-)
Un exemple serait le bienvenu...
faudrait que je retrouve ca, j'ai lu un papier quelque part là dessus, j'ai pas expérimenté moi même là dessus... je me base sur des retours d'exp désolé...
[^] # Re: Avantages ?
Posté par Guillaume Carre . En réponse à la dépêche JOnAS 3.1 est sortie. Évalué à 1.
Sinon je ne critique pas J2EE, si c'est moi que tu visais, je critique les EJB Entity Beans CMP (et BMP). Je trouve les Session Beans extremement utiles. Au passage je demande confirmation pour les jointures avec les EJB 2, là aussi si tu as une info je suis preneur :)
[^] # Re: Avantages ?
Posté par Guillaume Carre . En réponse à la dépêche JOnAS 3.1 est sortie. Évalué à 1.
C'est-à-dire ? Le surcout de l'architecture EJB vient en gros exclusivement de l'aspect RMI. La persistence ne pose en général pas de problème.
pour les CMP:
empreinte mémoire des EJB, et surtout pas d'héritage, c'est un comble, alors qu'on utilise un langage objet!
la norme EJB 2 a pas mal apporté, heureusement:
- interfaces locales comme on a dit
- EJBQL (langage de query)
- relations entre les EJB, 1-1 1-n n-n (CMR = Container Managed RelationShips)
[^] # Re: Avantages ?
Posté par Guillaume Carre . En réponse à la dépêche JOnAS 3.1 est sortie. Évalué à 1.
Pourrais-tu développer, ça ne me semble pas très clair, ton truc. Sur le client, tu as le Home et le Remote, sur le serveur le Bean lui-même plus de l'enrobage propre au serveur.
par exemple, tu as besoin dans certains cas de coder une classe ObjectKey pour gérer la clé primaire... ca fait 4...
Ba oui, c'est le but de CMP. Si tu veux du contrôle tu fais tu BMP. Sinon, les find sont codés en EJBQL, pas en SQL.
oui bien sur, si le code SQL généré me convenait ca serait trés bien, mais je pense que ce n'est pas assez optimisé... il me semble que le code généré ne fait pas de jointures tout seul par exemple...
[^] # Re: Avantages ?
Posté par Guillaume Carre . En réponse à la dépêche JOnAS 3.1 est sortie. Évalué à 2.
Tu sais, comme le dis Boubou, avant les EJB 2.0 les serveurs d'applications faisait déjà souvent des appels locaux en interne, ce qu'a fait Sun c'est inclure cette possibilité dans la spec. Donc niveau perf, c'était déjà +- idem.
ha... je demande confirmation, tu as un lien?
Je ne trouve pas ça dérangeant d'avoir plusieurs classes par EJB, tu as les diverses interfaces implémentées (EJBHome, ...) et tu as l'implémentation proprement dite (qui est générée automatiquement). Effectivement ça bouffe de la mémoire, mais en contre partie ça rend pas mal de service.
ha... moi avoir 4 ou 5 classes par objet métier, quand tu as un modèle de 300 objets, je trouve ca un peu génant... quand tu vois que tu n'en as qu'une à coder avec JDO...
En plus les services rendus par le conteneur d'EJB, tu les as en utilisant des Session Beans, suffit de placer JDO (ou des DAO) derrière ces Session Beans, et tu rends ton modèle objet beaucoup plus simple, et tu diminues l'empreinte mémoire de ton application
De toute façon, en pratique, tout le monde fait du Session Bean + JDBC, aprés s'être cassé les dents sur les Entity Beans...
Par contre je ne comprends pas pourquoi tu te plains que le SQL soit généré tout seul dans les CMP (tu peux utiliser des BMP si tu veux), puis juste après tu te plains de devoir utiliser du SQL pour les finders ...
je ne me plains pas que le SQL soit généré tout seul, je me plains que le SQL généré tout seul soit pourri... et qu'en conséquence on soit obligé de tout coder dans les finders... où est alors l'utilité des CMP je vous le demande... (par rapport aux BMP)
enfin on va pas refaire le gueguerre JDO vs CMP de serverside hein ;-)
http://www.theserverside.com/discussion/thread.jsp?thread_id=771&am(...)
[^] # Re: Avantages ?
Posté par Guillaume Carre . En réponse à la dépêche JOnAS 3.1 est sortie. Évalué à 1.
Effectivement, les EJB sont gourmands en ressources, et il ne faut pas les utiliser pour de petits projets. Mais ils font gagner pas mal de temps, ont des performances très satisfaisantes et surtout ont une très bonne scalability lorsqu'ils sont utilisés au bon endroit.
Pour les performances, si on parle des EJB Entity Beans, elles sont loin d'être satisfaisantes!
Depuis les EJB 2 les choses se sont arrangées (appels locaux entre les Session et les Entity, avant il fallait passer par RMI), mais tu as toujours au moins 3 classes par EJB, voir 4 ou 5, et l'empreinte mémoire d'un objet métier modélisé par un Entity Bean est énorme! Sans parler des requêtes SQL générées dans les CMP, où on n'a pas de contrôle, on est obligé de coder les méthodes find en SQL...
On peut aussi parler de l'absence de notion d'héritage avec les Entity Beans...
Pour l'accès aux bases de données, tu as typiquement le choix entre les EJB, JDBC dans les servlets, ou (dans un futur proche) JDO (Java Data Object, un nouveau moyen de gérer la persitence, plus léger que les EJB).
JDO (Java Data Objects) n'est pas directement comparable aux Entity Beans CMP, puique suivant l'implémentation utilisée, on peut gérer la persistance dans une base de données relationnelle, mais aussi dans une base de données objet, dans du XML, etc etc (la spec JDO n'est pas restrictive)
pour plus d'infos, www.libelis.com
Personnellement dans un projet de taille moyenne sur lequel je travail, j'utilise des servlets pour le Controller, des query appelés par JDBC comme Model et les JSP comme View. (Je déconseille l'utilisation de servlet comme view, parce que l'HTML hardcodé ça pue quand même ...)
Utiliser un framework de type Struts va beaucoup aider dans ce cas là... http://jakarta.apache.org/struts(...)
# Re: Quel outil pour programmer en C++ ?
Posté par Guillaume Carre . En réponse au journal Quel outil pour programmer en C++ ?. Évalué à 4.
- coloration syntaxique
- completion syntaxique, templates de code (du style du tappes if et il te génère le bloc if{}else{})
- bouton make ce que tu veux sur le projet, tu peux choisir le compilateur que tu veux
- déboggueur local (pas de debug distant aujourd'hui, ca va venir), ca a pas l'air trés stable
- travail en équipe avec CVS intégré à eclipse
le plugin est pour eclipse 2.0.2, tu auras les key bindings emacs avec eclipse 2.1, mais il faut attendre une mise à jour du plugin CDT qui fonctionne sur eclipse 2.1
sinon pour installer eclipse sur une debian, il te faut juste un jre/jdk, et télécharger le zip eclipse-SDK pour linux, c'est tout
[^] # Re: IBM n'est pas dans le même sac quand même !
Posté par Guillaume Carre . En réponse à la dépêche Microsoft récompensé au LinuxWorld Expo de New York. Évalué à 3.
et pour info, WSAD 4 est basé sur eclipse 1, et WSAD 5 sur eclipse 2.
[^] # Re: Benchmark J2EE vs dotNET
Posté par Guillaume Carre . En réponse à la dépêche Benchmark J2EE vs dotNET. Évalué à 1.
[^] # WSAD 4 = Eclipse 1 !
Posté par Guillaume Carre . En réponse à la dépêche Des nouvelles d'Eclipse. Évalué à 4.
quel rapport entre WSAD et le serveur d'app? tu fais tourner le serveur d'app sur la machine de dév???? sinon si tu utilisés WTE (WebSphere Test Environment effectivement faut une grosse bécane...)
sinon j'utilise CVS avec Eclipse 2 ca fonctionne trés bien!
à noter que WSAD 4 (4.0.3 la dernière) est basé sur Eclipse 1, il faut attendre WSAD 5 pour Eclipse 2, il y aura beaucoup de bugs corrigés et des fonctionnalités ajoutées (on pourra enfin utiliser les plugins pour eclipse 2)...
les plugins eclipse: http://eclipse-plugins.2y.net/eclipse/(...)
[^] # jakarta.apache.org aussi
Posté par Guillaume Carre . En réponse à la dépêche Article d'introduction à J2EE. Évalué à 10.
avec tomcat le moteur de servlets, ant le "make" de java, Struts le framework MVC etc etc...
# www.theserverside.com
Posté par Guillaume Carre . En réponse à la dépêche Article d'introduction à J2EE. Évalué à 10.
ce que tu appelles "balises semblables au XML" pour les JSP,
je suppose que tu parles des Tag Libraries (TagLib):
http://java.sun.com/products/jsp/taglibraries.html(...)
enfin, je pense qu'un petit paragraphe sur les EJB, décrivant les Session et les Entity Beans (et eventuellement les Message Beans) ne ferait pas de mal...
mais sinon c'est pas mal ;-)