JSP + bean et prog objet

Le 28.08 2003, "François Le Dorner" <francoisledorner@hotmail.com> s'est
levé(e) et s'est dit "tiens, je vais écrire aux mecs de
fr.comp.lang.java"

Bonjour à tous,

Comment peut s'organiser une appli en 5 niveaux avec une techno
hybride (script et objet) comme : JSP, des tags : jsp.tagext , bean ?
niveau présentation
niveau modele métier
niveau logique métier
niveau abstraction des données
niveau stockage

Jérôme répondrait probablement mieux que moi, mais je peux toujours
donner un début de réponses.
Les jsp sont des outils de présentation, elles gèrent donc cette copuche,
conjointement avec les taglibs (qui sont juste un moyen commode de gérer
la séparation entre le code HTML et Java). Afin de mieux gérer cette
présentation, tu peux utiliser Struts, ou n'importe quel framework MVC
(car je trouve Struts assez inutilement lourd, au final).
Une fois passée la couche de présentation, le reste de ton code, donc le
métier, est géré avec des JavaBeans.
Et l'interface avec la couche de stockage se fait de manière
traditionnelle au moyen de drivers JDBC ou autres (JNDI, accès direct à
des fichiers, stockage XML, framework de persistance objet comme
hibernate, ....).

Coté performance :
Je suis habitué aux concepts EJB et pour moi c'est le top ( ne
serait-ce que pour le lifecycle d'un EJB... )

Tu veux bien dire, là, et c'est ce que je crois, que les EJBs sont top au
niveau performances ?
C'est bien ça, hein ?
Bon, alors compare l'occupation mémoire d'une application à base d'EJB et
d'une application à base de Beans. Une fois cette comparaison effectuée,
compare les temps d'appels entre des beans simples et des EJB (même à
travers un réseau).
Considérer les EJB comme performants me semble aller quelque part dans le
sens d'une hérésie particulièrement raffinée (et peut-être même
rafarinée).
Les EJB sont des composants modulaires facilement administrables et
intégrables à une informatique d'entreprise, soit. Mais rien dans les EJB
(selon moi) n'est fait pour en faire du code Java performant.

Mais d'après certains, c'est une question de performance.
Donc les projets J2EE sont souvent avec JSP plutôt qu'avec EJB.

Oui, car les EJB sont surtout utiles lorsqu'on souhaite mettre en oeuvre
des mécanismes de transaction, de persistance transparente, d'équilibrage
de charge dynamique.
Or ces mécanismes sont loin d'être toujours nécessaires.
Dans ces cas, où les mécanismes qui font les avantages des EJB ne sont
pas nécessaires, pourquoi s'en servir ?

Je ne comprends pas comment une appli avec un max d'EJB (bien
appropriés) peut être moins performant qu'avec des JSP !

As-tu déja fait des benchs de performance entre des applications

JSP+JavaBeans et des applications JSP+EJB ?

Merci pour vos lumières.

--
Nicolas Delsaux
PB > La sincérité ne fait pas avancer la cause nomic.
in fufe en délire

Nicolas Delsaux wrote:

Le 28.08 2003, "François Le Dorner" <francoisledorner@hotmail.com> s'est
levé(e) et s'est dit "tiens, je vais écrire aux mecs de
fr.comp.lang.java"

Bonjour à tous,

Comment peut s'organiser une appli en 5 niveaux avec une techno
hybride (script et objet) comme : JSP, des tags : jsp.tagext , bean ?
niveau présentation
niveau modele métier
niveau logique métier
niveau abstraction des données
niveau stockage

Jérôme répondrait probablement mieux que moi, mais je peux toujours
donner un début de réponses.
flatteur :)

Les jsp sont des outils de présentation, elles gèrent donc cette copuche,
conjointement avec les taglibs (qui sont juste un moyen commode de gérer
la séparation entre le code HTML et Java). Afin de mieux gérer cette
présentation, tu peux utiliser Struts, ou n'importe quel framework MVC
(car je trouve Struts assez inutilement lourd, au final).
Une fois passée la couche de présentation, le reste de ton code, donc le
métier, est géré avec des JavaBeans.
Et l'interface avec la couche de stockage se fait de manière
traditionnelle au moyen de drivers JDBC ou autres (JNDI, accès direct à
des fichiers, stockage XML, framework de persistance objet comme
hibernate, ....).

je sui a peu pres d'accord.....

Coté performance :
Je suis habitué aux concepts EJB et pour moi c'est le top ( ne
serait-ce que pour le lifecycle d'un EJB... )

Tu veux bien dire, là, et c'est ce que je crois, que les EJBs sont top au
niveau performances ?
C'est bien ça, hein ?
Bon, alors compare l'occupation mémoire d'une application à base d'EJB et
d'une application à base de Beans. Une fois cette comparaison effectuée,
compare les temps d'appels entre des beans simples et des EJB (même à
travers un réseau).
cela depend si tu fais du local ou du remote..c'est inherent a la

serialisation Java (meme probleme pour RMI)

Considérer les EJB comme performants me semble aller quelque part dans le
sens d'une hérésie particulièrement raffinée (et peut-être même
rafarinée).
Les EJB sont des composants modulaires facilement administrables et
intégrables à une informatique d'entreprise, soit. Mais rien dans les EJB
(selon moi) n'est fait pour en faire du code Java performant.

pas forcement d'accord, car tu ne vas pas instancier des beans a

outrance non? tu vas les recycler dans un pool non? c'est deja fait dans
un conteneur EJB....
ton acces JDBC a la mimine va tomber inevitablement sur le probleme des
n+1 requetes..une couche d'abstraction CMP doit te l'eviter!!!! coder en
plus des mecanisme de lazy loading/ eager loading a la demande etc... tu
recodes une couche CMP du type celle de JBOSS et bon courage :) en plus
pour faire propre , t'es oblige le choix a l'utilisateur de la strategie
a utiliser (ce qui est fait) et de rendre cela facilement configurable....
regardes deja dans du code JDBC :
- combien utilise des preparedstatement en lieu et place de statements ?
- comment sont construites les chaines (requetes SQL et autres)
- comment swont utilises les proprietes de configuration des resultset !!!


c'est pas si mal que cela les EJBs en fait :)

Jerome

Mais d'après certains, c'est une question de performance.
Donc les projets J2EE sont souvent avec JSP plutôt qu'avec EJB.

Oui, car les EJB sont surtout utiles lorsqu'on souhaite mettre en oeuvre
des mécanismes de transaction, de persistance transparente, d'équilibrage
de charge dynamique.
Or ces mécanismes sont loin d'être toujours nécessaires.
Dans ces cas, où les mécanismes qui font les avantages des EJB ne sont
pas nécessaires, pourquoi s'en servir ?

Je ne comprends pas comment une appli avec un max d'EJB (bien
appropriés) peut être moins performant qu'avec des JSP !

As-tu déja fait des benchs de performance entre des applications
JSP+JavaBeans et des applications JSP+EJB ?

Merci pour vos lumières.

coté organisation je trouve çà dangereux d'avoir une techno comme JSP
qui autorise de faire un mélange entre présentation (HTML) et métier alors
qu'il y a au moins une techno faite exactement pour les IHM (XSLT) ...

Tu veux bien dire, là, et c'est ce que je crois, que les EJBs sont top au
niveau performances ?
C'est bien ça, hein ?

Il ne faut pas en faire n'importe quoi, de n'importe quel type avec
seulement
des interfaces remote tout en statefull et tout en transaction.
L'allocation de mémoire pour la création d'objets prend du temps à java,
le container s'occupe de recycler les EJB...

Bon, alors compare l'occupation mémoire d'une application à base d'EJB et
d'une application à base de Beans.

Les Beans sont chargés a chaque appel d'un JSP pour ce JSP ? çà coûte
sûrement plus
que de récupérer un EJB recyclé.

Une fois cette comparaison effectuée,
compare les temps d'appels entre des beans simples et des EJB (même à
travers un réseau).

Jérome l'a trés bien expliqué... (local remote)

Oui, car les EJB sont surtout utiles lorsqu'on souhaite mettre en oeuvre
des mécanismes de transaction, de persistance transparente, d'équilibrage
de charge dynamique.

Oui mais je persiste a dire que c'est le progrès d'utiliser un container qui
gère (entre autre)
le chargement des objets pour une grosse ou une petite appli pour 1 ou 10000
utilisateurs.
Il ne faut pas voir l'EJB comme une techno compliquée et réservée a des
applis
de banques ou d'assurances !

Or ces mécanismes sont loin d'être toujours nécessaires.
Dans ces cas, où les mécanismes qui font les avantages des EJB ne sont
pas nécessaires, pourquoi s'en servir ?

Parce que les applis doivent être vivantes et il faut les préparer pour
l'avenir.
De plus comme on choisis pour chaque EJB ce que l'on souhaite faire
(transaction...)
çà n'alourdit pas dans un premier temps de ne pas utiliser toutes les
possibilités du container.

As-tu déjà fait des benchs de performance entre des applications
JSP+JavaBeans et des applications JSP+EJB ?

Apparemment des grosses boites "censurent" cette techno en montrant des
chiffres ...
j'aimerai bien en savoir plus mais je sais pas où trouver.

En plus, les EJB sont super bien pris en compte par Rationa Rose 2003
( alors que si j'ai bien vu les JSP, a part du reverse ... ) !

Alors que demander de plus ?

--
François Le Dorner.