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.
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.
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.
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.
;-)
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.
;-)
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.
;-)
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é
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é
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é
100% d'accord avec TestMan sur la robustesse J2EE ( et sa complexité
jusqu'à ce jour)
100% d'accord avec TestMan sur la robustesse J2EE ( et sa complexité
jusqu'à ce jour)
100% d'accord avec TestMan sur la robustesse J2EE ( et sa complexité
jusqu'à ce jour)
jlp 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 à
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 à
jlp 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 à
jlp 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é.
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é.
jlp 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é.
jlp 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
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
jlp 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
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.
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.
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.
"#cyrille37#" wrote in message
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,
"#cyrille37#" <cyrille37@gmail.com> wrote in message
news:1164703625.470937.67910@80g2000cwy.googlegroups.com...
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,
"#cyrille37#" wrote in message
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,