Quand utiliser JBoss ?

jlp <jlp@ft.com> wrote:

100% d'accord avec TestMan sur la robustesse J2EE ( et sa complexité
jusqu'à ce jour)

Entièrement d'accord pour la robustesse, mais concernant sa
complexité, je ne suis pas du tout d'accord.
Ce qui rend les choses complexes, c'est la structure choisie et le
niveau de qualité/maintenabilité/évolutivité du code que l'on
souhaite atteindre.
Concevoir/maintenir une appli sécurisée et "propre" en php est à mes
yeux beaucoup plus difficile qu'en java.
Au contraire, faire une appli dégueu en php est beaucoup plus facile
qu'en java.


Je parle de compexité par rapport aux compétences / connaissances à

avoir en J2EE et notamment jusqu'à la version EJB2.1 incluse. Le
modèle Improve à 4 ou 5 niveaux n'est pas d'une évidence biblique.
Sans compter qu'il faut bien utiliser les Design Pattern à chaque
niveau.
Par rapport à la simplicité un accés direct en base de données
depuis une page PHP y a pas photo...
Apres sur l'aspect maintenabilité et si le découplage de chaque
niveau est bien fait, le modèle J2EE est bien le plus industrialisé.

Arrr... Improve, emmm... pas de commentaires.
"améliorer" c'est bien, mais commme dit le sage : le mieux est
l'ennemi du bien :o)

En clair, dix tonne de patrons lours super "beaux" mais innaccessibles
au commun des "mortels codeurs", ne servent à strictement rien (sauf à
se faire mousser dans des articles et des confs).

Quand à EJB2.1... ejbDestroy() ? :P

Perso je reste sur du plus simple :
- EJB3 Session Stateless avec interface distantes pour coder les
services (facilement mise à dispo en webservice) métiers en haut niveau
- EJB3 Entité pour mon modèle objet

Les EJB Sessions retournent soit des types simples ou alors des objets
ou graphes détachés (suivant les besoins).

Pour le coté Web : Seam + Facelet et le tour est joué !
J'espère que Seam va réussir à faire se raprocher les managedbeans JSF
et les session statefull dans une future spec, ça serrait un
simplification de plus :)

Mon seul regret, le cycle de dev qui est vraiment trop trop long ...
Je suis d'accord avec toi sur ces architectures logicielles à base de

EJB3, mais je ne vois pas de différence entre le modele Improve et ce
que tu proposes, les niveaux sont les mêmes, la technologie peut être
différente. Alors qu'en PHP tu fais du quasi Client/serveur.
Coucou,

Clairement, je suis toujours "attéré" par les arguments style "PHP c'est
simple" ou "ASP c'est simple". Le problème est que l'on confond
simplicité de codage et simplisme (absence?) de l'architecture mise en
place. Sous Java EE, on a tendance à penser qu'il faut mieux faire une
bonne archi dès le départ, histoire de pas se trouver bloquer. En PHP,
trop souvent le code part tout de suite ("comme on le sent") avec le
sentiment qu'il sera toujours temps de corriger ce qui ne va pas. La
vérité est que la maintenance d'un projet sans un minimum d'archi est un
véritable cauchemard :( car "p*sser du code" n'importe comment est
toujours facile pour celui qui le fait, mais autrement plus complèxe
pour celui qui doit le corriger !

Pour ce qui est de l'archi de "amélioré", je lui reproche d'être trop
complexe de compréhension. Les "effets de manches" sur l'utilisation de
patrons, bien qu'exacts, facilitent peu la compréhension des néophites.
Présenter en EJB3 le schmillclibk me parrait plus simple :
- EJB3 Stateless --> les services metier
- EJB3 Entity --> le stockage donnée

EJB2.x c'est sûr c'est la plaie. EJB3 ( qui entre parentheses est EJB2.1
+ API JPA) amène des simplications de codages mais les annotations sont
quand même assez intrusives dans le code, surtout quand on utilise les
extensions Hibernate, Toplink...

Lest annotations de JPA sont intrusive au modèle objet car elles
spécifient la relation avec un modèle relationel. Quid de l'interret de
stocker toujours en 2006 les objets dans un SGBD/R ... mais là je
m'égare... Par contre les annotations d'EJB3 me semblent aller dans le
bon sens.

Les extensions ne sont pas utile, sauf pour ce qui est de
HibernateValidator qui me semblerait nécessaire d'inclure même au niveau
de Java SE dans javax.annotation ... celà permettrait une meilleure
definition des domaines de validité pour les types standards. Un
rapprochement vers XMLShema en somme, qui bénéficierait à JPA, JSF et
même au Swing !

Par contre coté client Riche, je ne me prononcerai pas sur l'avenir :
Adobe/Flex vs JSF+AJAX (Seam, IceFaces, JSF4Ajax ...) vs JWS ?
Je ne parierais pas grand chose sur Java Web Start...

Flex reste proprio et assez limité, et je reste dubitatif sur la faible
modularité et la séparation entre programmation et conception visuelle,
mais celà peut être une solution transitoire interessante. Je
préfèrerais Openlaszlo mais avec une intérrogation sur sa pérénité.

Quand à AJAX, bof bof bof ... comment faire une solution stable avec des
implementations non-cohérentes et non-conforme aux standards édictés. Se
retrouver à devoir disposer de multiples environements de test pour
reproduire et deboguer les problèmes des utilisateurs ne me parrait pas
vraiment un "progrès". Et la vague "web 2.0" ressemble (google exclus à
75%) surtout plus à une "bulle 2.0" (le pipotron a encore frappé chez
les pousses). Si l'on veut une nouvelle génération de services internet,
il faut commencer par rétablir le bout en bout qui est la raison d'être
de l'internet. En clair, "ipv6 pour tous et maintenant" ! Celà permettra
de faire de la vrai sécurité et des nouveaux services distributés plus
souples, plus simple d'utilisation, montant mieux en charge et disposant
d'un meilleur cout global.

Quand à webstart, compte tenue du manque total de publicité autour de
cette techno, la multitude d'application disponible sur le net et les
entreprises montre qu'il doit bien avoir un sérieu potentiel ;-) C'est
une solide base existante, pragmatique, loint du pipo-marketing sur le
quel la JSR277 pourrait bien s'appuyer ...

Au final, je pense vraiment que Java coté client avec le OpenJDK
pourrait offrir une vraie alternative libre et performante, pour peu que
les quelques points bloquants soit résolus coté client riche.

Pas d'accord avec toi pour ce qui concerne les DP, c'est pas seulement
pour se faire mousser car ils sont bien utiles : que serait un
container de servlets/JSP sans le DP Chain Of Responsabilities,ou bien
sans le pattern MVC. Evidemment certains patterns sont complexes , et
les reconnaitre n'est pas toujours possible, mais en appliquer 4 ou 5
c'est déja pas mal ...

Effectivement, certains patrons conceptuels sont utiles mais d'autres
sont du domaine de la tautologie (un peu comme un certain Jourdain qui
faisait de la poésie sans le savoir), "fantaisistes" ou encore tellement
complexe et ultra-spécialisés qu'ils en deviennent innutiles et
innaplicables dans un projet réel.

De façon générale, j'avoue que je suis encore partagé entre utilisés des
patrons à outrance et utiliser de la POA.

Quand au MVC, il faudrait déjà qu'il soit réellement appliqué. Car dire
qu'on est MVC "c'est bien mais" l'être vraiment et complètement, "c'est
mieux" ... :)

A+
TM - "Pas de pause café"

jlp <jlp@ft.com> wrote:

100% d'accord avec TestMan sur la robustesse J2EE ( et sa complexité
jusqu'à ce jour)

Entièrement d'accord pour la robustesse, mais concernant sa
complexité, je ne suis pas du tout d'accord.
Ce qui rend les choses complexes, c'est la structure choisie et le
niveau de qualité/maintenabilité/évolutivité du code que l'on
souhaite atteindre.
Concevoir/maintenir une appli sécurisée et "propre" en php est à
mes yeux beaucoup plus difficile qu'en java.
Au contraire, faire une appli dégueu en php est beaucoup plus
facile qu'en java.


Je parle de compexité par rapport aux compétences / connaissances à

avoir en J2EE et notamment jusqu'à la version EJB2.1 incluse. Le
modèle Improve à 4 ou 5 niveaux n'est pas d'une évidence biblique.
Sans compter qu'il faut bien utiliser les Design Pattern à chaque
niveau.
Par rapport à la simplicité un accés direct en base de données
depuis une page PHP y a pas photo...
Apres sur l'aspect maintenabilité et si le découplage de chaque
niveau est bien fait, le modèle J2EE est bien le plus industrialisé.

Arrr... Improve, emmm... pas de commentaires.
"améliorer" c'est bien, mais commme dit le sage : le mieux est
l'ennemi du bien :o)

En clair, dix tonne de patrons lours super "beaux" mais
innaccessibles au commun des "mortels codeurs", ne servent à
strictement rien (sauf à se faire mousser dans des articles et des
confs).

Quand à EJB2.1... ejbDestroy() ? :P

Perso je reste sur du plus simple :
- EJB3 Session Stateless avec interface distantes pour coder les
services (facilement mise à dispo en webservice) métiers en haut niveau
- EJB3 Entité pour mon modèle objet

Les EJB Sessions retournent soit des types simples ou alors des
objets ou graphes détachés (suivant les besoins).

Pour le coté Web : Seam + Facelet et le tour est joué !
J'espère que Seam va réussir à faire se raprocher les managedbeans
JSF et les session statefull dans une future spec, ça serrait un
simplification de plus :)

Mon seul regret, le cycle de dev qui est vraiment trop trop long ...

Je suis d'accord avec toi sur ces architectures logicielles à base de
EJB3, mais je ne vois pas de différence entre le modele Improve et ce
que tu proposes, les niveaux sont les mêmes, la technologie peut être
différente. Alors qu'en PHP tu fais du quasi Client/serveur.

Coucou,

Clairement, je suis toujours "attéré" par les arguments style "PHP c'est
simple" ou "ASP c'est simple". Le problème est que l'on confond
simplicité de codage et simplisme (absence?) de l'architecture mise en
place. Sous Java EE, on a tendance à penser qu'il faut mieux faire une
bonne archi dès le départ, histoire de pas se trouver bloquer. En PHP,
trop souvent le code part tout de suite ("comme on le sent") avec le
sentiment qu'il sera toujours temps de corriger ce qui ne va pas. La
vérité est que la maintenance d'un projet sans un minimum d'archi est un
véritable cauchemard :( car "p*sser du code" n'importe comment est
toujours facile pour celui qui le fait, mais autrement plus complèxe
pour celui qui doit le corriger !
Je suis capable d'écrire du cote "imb*table" aussi en java ;-)

Pour ce qui est de l'archi de "amélioré", je lui reproche d'être trop
complexe de compréhension. Les "effets de manches" sur l'utilisation de
patrons, bien qu'exacts, facilitent peu la compréhension des néophites.
Présenter en EJB3 le schmillclibk me parrait plus simple :
- EJB3 Stateless --> les services metier
- EJB3 Entity --> le stockage donnée

Oui,oui !!

EJB2.x c'est sûr c'est la plaie. EJB3 ( qui entre parentheses est
EJB2.1 + API JPA) amène des simplications de codages mais les
annotations sont quand même assez intrusives dans le code, surtout
quand on utilise les extensions Hibernate, Toplink...

Lest annotations de JPA sont intrusive au modèle objet car elles
spécifient la relation avec un modèle relationel. Quid de l'interret de
stocker toujours en 2006 les objets dans un SGBD/R ... mais là je
m'égare... Par contre les annotations d'EJB3 me semblent aller dans le
bon sens.

Oui d'accord avec toi pour l'avancée EJB3 dans la simplication

Les extensions ne sont pas utile, sauf pour ce qui est de
HibernateValidator qui me semblerait nécessaire d'inclure même au niveau
de Java SE dans javax.annotation ... celà permettrait une meilleure
definition des domaines de validité pour les types standards. Un
rapprochement vers XMLShema en somme, qui bénéficierait à JPA, JSF et
même au Swing !

Par contre coté client Riche, je ne me prononcerai pas sur l'avenir :
Adobe/Flex vs JSF+AJAX (Seam, IceFaces, JSF4Ajax ...) vs JWS ?
Je ne parierais pas grand chose sur Java Web Start...

Flex reste proprio et assez limité, et je reste dubitatif sur la faible
modularité et la séparation entre programmation et conception visuelle,
mais celà peut être une solution transitoire interessante. Je
préfèrerais Openlaszlo mais avec une intérrogation sur sa pérénité.

Quand à AJAX, bof bof bof ...
Seam, que tu as l'air d'aimer, utilise les mécanismes AJAX (

Javascript, arbre DOM, XMLHttpRequest)
[SNIP]

A+
TM - "Pas de pause café"

Bon WE
A+
JL PASTUREL