Quand utiliser JBoss ?

Le
#cyrille37#
Bonjour,

Il y a une question qui me cours toujours sur les neurones:
Quand a-t-on besoin d'un serveur d'application comme JBoss ?

Avec un conteneur llger comme Spring qui gre bien l'tat des Beans
selon
des "scopes" diffrents et associ un ORM comme "Hibernate" on
manipule
facilement des objets stocks.
Du coup je ne vois pas sur quels critres un serveur comme Tomcat ne
suffit plus et qu'il faut passer un serveur d'application comme
JBoss, comme de toute faon on a toujours dans cette histoire une base
de donnes derrire tout ce petit monde.

Si vous avez le moindre critre discuter je suis preneur. Cel me
remetterait la pendule l'heure.
;-)

Merci beaucoup d'avance,
cyrille
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
jlp
Le #223662
Bonjour,

Il y a une question qui me cours toujours sur les neurones:
Quand a-t-on besoin d'un serveur d'application comme JBoss ?

Avec un conteneur lléger comme Spring qui gère bien l'état des Beans
selon
des "scopes" différents et associé à un ORM comme "Hibernate" on
manipule
facilement des objets stockés.
Du coup je ne vois pas sur quels critères un serveur comme Tomcat ne
suffit plus et qu'il faut passer à un serveur d'application comme
JBoss, comme de toute façon on a toujours dans cette histoire une base
de données derrière tout ce petit monde.

Si vous avez le moindre critère à discuter je suis preneur. Celà me
remetterait la pendule à l'heure.
;-)

Merci beaucoup d'avance,
cyrille

JBoss inclut un container de servlet/jsp qui peut être Tomcat ou Jetty.

Effectivement on peut faire du J2EE sans EJB ( voir le livre de Rod
Johnson : J2EE without EJB, Rod Johnson est l'un des leader de Spring).
On doit couvrir 80% des cas d'applications en nombre.
Pour les applications de grandes envergures, les EJB, transactions XA,
et autres mécanismes type JMS sont nécessaires.

TestMan
Le #223609
Bonjour,


Bonjour,

Il y a une question qui me cours toujours sur les neurones:
Quand a-t-on besoin d'un serveur d'application comme JBoss ?

Avec un conteneur lléger comme Spring qui gère bien l'état des Beans
selon
des "scopes" différents et associé à un ORM comme "Hibernate" on
manipule
facilement des objets stockés.
Du coup je ne vois pas sur quels critères un serveur comme Tomcat ne
suffit plus et qu'il faut passer à un serveur d'application comme
JBoss, comme de toute façon on a toujours dans cette histoire une base
de données derrière tout ce petit monde.


Et surtout un base de données pré-historique (lire RDBMS) ;-)

Si vous avez le moindre critère à discuter je suis preneur. Celà me
remetterait la pendule à l'heure.
;-)


Spring est un produit, EJB est une spec. Ainsi, Spring a le bénéfice et
les inconvénent du spécifique. Si l'on veut être juste, il faut donc
bien comparer Spring et Glassfish*, JBoss, Geronimo, JOnAS, JFox, ... et
même JEUS*, Sap AS*, IBM WebSphere, WebLogic ... (Pour info, seul ceux
qui ont une * sont certifié Java EE 5 à ce jour)

Domage que Spring n'ait pas choisit la voie d'une JSR (ou tout autre
processus de standardisation). C'est une grossière erreur, car que
va-t-il advenir une fois que la "vague" va le ratrapper ? On a vu le
sort de Struts ... lui aussi génial à son heure ;-)

Un choix pérène est un choix qui s'appuie sur un minimum de standards
histoire de s'ouvrir des portes ... Bien sûr, suivre un standard celà
ralentit et limite parfois :(

Heureusement Spring est libre (OpenSource) l'avantage est donc d'éviter
les cas "direct-poubelle" (que l'on trouve dans le monde comercial, j'ai
le nom d'un fabricant de SGBD en tête mais chutt ! ) mais il ne permet
pas d'éviter ceux du "plus-dans-le-vent" ... regardez OJB de Apache, que
sont ils devenu face au duo de choc EJB3 poussé par Hibernate.

Si on compare produit à produit, on voit que les possibilités
d'administrations, de disponibilité, de monté encharge, d'interfaçage
sont clairement pas en faveur de Spring. Domage, mais les placards de
l'histoire de l'informatique sont pleins de "meilleures solutions" :( Ce
qui est choisit n'est donc pas le meilleur techniquement, ni le plus
simple mais bien le plus souple.

Niveau souplesse, Java EE est là depuis un bail et niveau architecture
distribuée (rebaptisée M2M dans certains diaporama, car c'est plus sexy)
j'ai pas vu mieux ...

Voilà de quoi à démarer un débat ;)

A+
TM

jlp
Le #223605
Bonjour,


Bonjour,

Il y a une question qui me cours toujours sur les neurones:
Quand a-t-on besoin d'un serveur d'application comme JBoss ?

Avec un conteneur lléger comme Spring qui gère bien l'état des Beans
selon
des "scopes" différents et associé à un ORM comme "Hibernate" on
manipule
facilement des objets stockés.
Du coup je ne vois pas sur quels critères un serveur comme Tomcat ne
suffit plus et qu'il faut passer à un serveur d'application comme
JBoss, comme de toute façon on a toujours dans cette histoire une base
de données derrière tout ce petit monde.


Et surtout un base de données pré-historique (lire RDBMS) ;-)

Si vous avez le moindre critère à discuter je suis preneur. Celà me
remetterait la pendule à l'heure.
;-)


Spring est un produit, EJB est une spec. Ainsi, Spring a le bénéfice et
les inconvénent du spécifique. Si l'on veut être juste, il faut donc
bien comparer Spring et Glassfish*, JBoss, Geronimo, JOnAS, JFox, ... et
même JEUS*, Sap AS*, IBM WebSphere, WebLogic ... (Pour info, seul ceux
qui ont une * sont certifié Java EE 5 à ce jour)

Domage que Spring n'ait pas choisit la voie d'une JSR (ou tout autre
processus de standardisation). C'est une grossière erreur, car que
va-t-il advenir une fois que la "vague" va le ratrapper ? On a vu le
sort de Struts ... lui aussi génial à son heure ;-)

Un choix pérène est un choix qui s'appuie sur un minimum de standards
histoire de s'ouvrir des portes ... Bien sûr, suivre un standard celà
ralentit et limite parfois :(

Heureusement Spring est libre (OpenSource) l'avantage est donc d'éviter
les cas "direct-poubelle" (que l'on trouve dans le monde comercial, j'ai
le nom d'un fabricant de SGBD en tête mais chutt ! ) mais il ne permet
pas d'éviter ceux du "plus-dans-le-vent" ... regardez OJB de Apache, que
sont ils devenu face au duo de choc EJB3 poussé par Hibernate.

Si on compare produit à produit, on voit que les possibilités
d'administrations, de disponibilité, de monté encharge, d'interfaçage
sont clairement pas en faveur de Spring. Domage, mais les placards de
l'histoire de l'informatique sont pleins de "meilleures solutions" :( Ce
qui est choisit n'est donc pas le meilleur techniquement, ni le plus
simple mais bien le plus souple.

Niveau souplesse, Java EE est là depuis un bail et niveau architecture
distribuée (rebaptisée M2M dans certains diaporama, car c'est plus sexy)
j'ai pas vu mieux ...

Voilà de quoi à démarer un débat ;)

A+
TM
100% d'accord avec TestMan sur la robustesse J2EE ( et sa complexité

jusqu'à ce jour). EJB3 est un grand pas en avant quand on a compris les
mécanismes des Injections et des Annotations.
Cependant l'IOC ( Inversion Of Control ou Dependency Injection voir le
site de Martin Fowler à ce sujet) pronée par Spring a bien été reprise
dans les specs EJB3. Il y a des bonnes idées partout...


Lionel
Le #223602
jlp
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.

jlp
Le #224387
jlp
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é.


TestMan
Le #224383
jlp
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 ...



jlp
Le #224380


jlp
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.
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...

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...

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 ...
A+
JL Pasturel




Frederic Lachasse
Le #224366
"#cyrille37#" news:
Bonjour,

Il y a une question qui me cours toujours sur les neurones:
Quand a-t-on besoin d'un serveur d'application comme JBoss ?

Avec un conteneur lléger comme Spring qui gère bien l'état des Beans
selon
des "scopes" différents et associé à un ORM comme "Hibernate" on
manipule
facilement des objets stockés.
Du coup je ne vois pas sur quels critères un serveur comme Tomcat ne
suffit plus et qu'il faut passer à un serveur d'application comme
JBoss, comme de toute façon on a toujours dans cette histoire une base
de données derrière tout ce petit monde.

Si vous avez le moindre critère à discuter je suis preneur. Celà me
remetterait la pendule à l'heure.


Par rapport à Tomcat/Spring, JBoss ajoute:

- Gestionaire de queue de message JMS:
Permet une communication asynchrone entre applications, avec transmission
des messages garanties.

- Moniteur transactionel JTA pour gérer les commit à 2 phases:
Nécessaire pour assurer l'atomicité des transactions entres plusieurs bases
de données et les queues de messages. Par exemple, quand on reçoit un
message JMS pour mettre à jour une base de donnée, le "commit" inscrit les
données et enlève le message de la queue, alors que le "rollback" annule les
modifications sur la base et remet le message dans la queue pour être traité
plus tard.

- RMI-IIOP communication.
Pas vraiment le meilleur choix pour traverser les firewall, mais meilleurs
performances à l'intérieur du réseau de l'entreprise.

- Supporte le fonctionnement en cluster:
Les données de sessions sont répliquées automatiquement, ce qui fait que
même si une machine crashe, les traitements continuent.

Pour une application, même complexe, utilisant une machine avec une seule
base de donnée, tout ça est plutôt inutile, et Tomcat/Spring bien
suffisant.

--
Frédéric Lachasse - ECP86

TestMan
Le #224364
"#cyrille37#" news:
Bonjour,

Il y a une question qui me cours toujours sur les neurones:
Quand a-t-on besoin d'un serveur d'application comme JBoss ?

Avec un conteneur lléger comme Spring qui gère bien l'état des Beans
selon
des "scopes" différents et associé à un ORM comme "Hibernate" on
manipule
facilement des objets stockés.
Du coup je ne vois pas sur quels critères un serveur comme Tomcat ne
suffit plus et qu'il faut passer à un serveur d'application comme
JBoss, comme de toute façon on a toujours dans cette histoire une base
de données derrière tout ce petit monde.

Si vous avez le moindre critère à discuter je suis preneur. Celà me
remetterait la pendule à l'heure.


Par rapport à Tomcat/Spring, JBoss ajoute:

- Gestionaire de queue de message JMS:
Permet une communication asynchrone entre applications, avec transmission
des messages garanties.

- Moniteur transactionel JTA pour gérer les commit à 2 phases:
Nécessaire pour assurer l'atomicité des transactions entres plusieurs bases
de données et les queues de messages. Par exemple, quand on reçoit un
message JMS pour mettre à jour une base de donnée, le "commit" inscrit les
données et enlève le message de la queue, alors que le "rollback" annule les
modifications sur la base et remet le message dans la queue pour être traité
plus tard.

- RMI-IIOP communication.
Pas vraiment le meilleur choix pour traverser les firewall, mais meilleurs
performances à l'intérieur du réseau de l'entreprise.

- Supporte le fonctionnement en cluster:
Les données de sessions sont répliquées automatiquement, ce qui fait que
même si une machine crashe, les traitements continuent.

Pour une application, même complexe, utilisant une machine avec une seule
base de donnée, tout ça est plutôt inutile, et Tomcat/Spring bien
suffisant.
Bonjour,


JMS pas utile même pour une appli complexe ? A voir ...

Quand au support RMI-IIOP est dans le Java SE RI depuis un bail non ?
http://java.sun.com/j2se/1.3/docs/guide/rmi-iiop/
(pas trouvé des liens)

Pour ce qui est du clustering, Tomcat permet aussi d'en faire même s'il
nécessite en général l'aide de Apache HTTPD pour celà ...

Pour une petite appli (pas beaucoup de fonctionalités) Tomcat est un bon
début quoi qu'en informatique "tout est toujours simple .... au début"
mais rarement au final ;) Alors plutôt qu'à devoir se lancer dans des
"grands travaux" par ce qu'on est bloqué niveau archi, mieux vaut
peut-être préférer "voir un peu large" et débuter dans un contexte que
l'on est certain de conserver jusqu'au bout. A voir ...

A+
TM


#cyrille37#
Le #224332
Merci à vous pour toutes ces remarques.

D'ailleurs, je les trouve tellement interressantes que je vous serais
reconnaissant de continuer votre débat. On sens l'expérience et il y
a plein de petits trucs très instructifs.

Merci encore, Et continuez !
;-)

Cyrille
Publicité
Poster une réponse
Anonyme