Date sent:      	Tue, 29 Feb 2000 03:18:51 -0800 (PST)
From:           	Mohamed Ould <ouldmoh@yahoo.com>
Subject:        	CRITIQUONS EJB & JSP!
To:             	java@u-strasbg.fr
Send reply to:  	java@u-strasbg.fr

Salut tout le monde,

Je ne sais pas si vous êtes aucourant des critiques 
suivantes sur les JSP et EJB.

JSP:

http://www.servlets.com/soapbox/problems-jsp.html

EJB:

http://www.techmetrix.com/lab/trendmarkers/tmkindex.shtml

Autant je suis d'accord avec pas mal de points
dans la critique des JSP, je n'approuve pas du
tout celles du fameux TrendMarkers.

Que pensent les specialistes de la liste?

Merci pour vos commentaires.

Ould Mohamed 


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From:           	"Cedric Beust" <cedric@beust.com>
To:             	<java@u-strasbg.fr>
Subject:        	RE: CRITIQUONS EJB & JSP!
Date sent:      	Tue, 29 Feb 2000 10:22:18 -0800
Send reply to:  	java@u-strasbg.fr


> From: Mohamed Ould [mailto:ouldmoh@yahoo.com]

> EJB:
>
> http://www.techmetrix.com/lab/trendmarkers/tmkindex.shtml
>
> Autant je suis d'accord avec pas mal de points
> dans la critique des JSP, je n'approuve pas du
> tout celles du fameux TrendMarkers.
>
> Que pensent les specialistes de la liste?

C'est difficile de faire un commentaire global sans savoir a quels
problemes ils se sont heurtes specifiquement, et avec chaque conteneur
EJB.

Quelques remarques :

> 4.2. No Support for Reentrancy

Il y a des raisons claires pour justifier cela dans la specification EJB,
les auteurs ne les mentionnent pas. Meme s'il est vrai que la restriction
"pas de creation de threads" est assez severement critiquee (voire a ce
sujet le thread recent dans ejb-interest, et plus specifiquement les
remarques d'un collegue, Sriram), les justifications initiales sont
valides a mon avis.

De ce point de vue, les auteurs du rapport semblent manquer de
perspective.

> 4.4. Incompatibility with the standard Java model
> The specification introduces incompatibilities between the EJB component
model
> and the standard Java object model. In some cases, this makes it
> impossible
to use
> frameworks designed for the standard Java object model with EJBs. This
> is why
the
> EJB model does not ensure ascending compatibility with the Java object
> model.

> Here is an example of incompatibility concerning the concept of object
identity.
>  In order to determine if two Entity Beans are identical, the
>  specification
indicates
> that one must always use the method isIdentical(). Use of the operator
> "==",
the
> equals() method and the hashcode()method is not allowed. The problem
> stems
from
> the fact that here we get away from the standard Java model, which uses
> these methods in a traditional manner. The numerous existing frameworks
> that are
>  based on this model for the notion of object identity cannot easily be
>  used
with EJBs.

Dure realisation... "le developpement d'applications distribuees est
complexe". Ben oui, c'est plutot evident. Les developpeurs ont pris
l'habitude avec CORBA par exemple d'utiliser _narrow() au lieu d'un
classique cast. La situation est similaire ici. On se detache du modele
Java parce que celui-ci est insuffisant pour decrire le type
d'applications visees par les EJB.

Leur critique revient un peu a dire "je ne vais pas faire d'appel a
distance parce que ca m'oblige a catcher "RemoteException" et ce n'est pas
ce que j'ai l'habitude de faire".

Pas tres convaincant.

> 4.6. No support for inheritance at the competent level
> The component model defined by the EJB specification does not support
inheritance.

C'est deja une critique plus valide. Pas grand-chose a ajouter si ce n'est
que c'est en cours de discussion aussi. Pas vraiment un point faible a mon
avis, mais plutot une manifestation de la jeunesse de la technologie. En
gros, on est encore en train d'essayer de comprendre comment tout cela
fonctionne...

Notez qu'on n'a pas attendu EJB pour avoir ce genre de problemes :

- templates derives en C++ (qui ne sont plus lies par l'heritage alors que
leurs arguments le sont) - servants CORBA (les interfaces heritents les
unes des autres, pas les implementations)


Sinon, je trouve l'article interessant et il met en valeur certains
problemes avec la norme actuellement. Les auteurs, implementeurs et
utilisateurs des EJB sont tres conscients des limitations actuelles et
soyez assures qu'il  y a enormement de discussions en cours pour les
aplanir (il suffit de voir le volume de ejb-interest).

Ca fait du bien de lire un article critique, merci pour le lien !

--
Cedric