Discussion :

[le Daoud]

Bonjour,

Actuellement sur un nouveau projet, nous sommes confrontés au choix du serveur. Le client souhaite nous orienter vers Tomcat car il possède des ressources en interne pour son administration.
Nos contraintes actuelles : Pas d’EJB, utilisation de struts, hibernate, spring. Nous allons mettre en œuvre des Web Services, mais les choix technologiques ne sont pas arrêtés.

Y aurait-il une ou des raisons de proposer un serveur d’application comme JBoss à la place de Tomcat ?

Merci,

[le Daoud]

Je vous transmets les informations réunies à présent et mes observations.

• Utilisation d'un pool de connexion - On peut l'implémenter avec Tomcat, mais c'est il faut une API externe. Donc de la charge. Cependant dans mon projet le pool de connexion n'est pas un pré-requis.
• Utilisation de JTA - En cas de besoin de transactions distribuées, nécessite l'ajout d'une api externe. Ajout de charge.
• Utilisation d'un service de mail - Différence au niveau de la réalisation, peu significatif.
• Composants spécifiques comme le scheduler de Jboss - Trop lié au serveur d'appli.
• Faciliter d'administration.

Des idées, remarques ?

[_Mac_]

J'ai pas compris : tu nous listes quoi ? Les contraintes du projet ou autre chose ? A mon avis, il faut partir des contraintes du projet. Le but c'est de trouver une fonctionnalité que ne remplit pas Tomcat et que tu ne peux pas lui faire faire avec une API externe. Par exemple, s'il te faut un scheduler, laisse tomber Tomcat. En revanche, pour la partie accès aux données, tu peux envisager Hibernate car il implémente un pool de connexion (note du rédacteur : un pool de connexion n'est pas une fin en soi...).

[le Daoud]

Je notais des éléments qui doivent être pris en compte dans le choix, avec mes contraintes actuelles (précisées dans mon premier message), mais j'essaie de voir le plus large possible car certains éléments peuvent permettre d'anticiper des besoins futurs (genre JTA).

[alexismp]

Administration, clustering, intégration WebServices & performance font pencher la balance coté app server (en tout cas coté GlassFish).

[toomsounet]

Le problème c'est que ça existe aussi avec Tomcat..

[wace]

Hi all,

Si le client veux du Tomcat et qu'il possède des compétences Tomcat, pourquoi aller contre sa volonté?

De plus c'est qui fera la production de l'application, donc je comprends qu'il est envie de capitaliser sur ses compétences,

Aller dans son sens c'est aussi le moyen de débuter la relation du bon pied en lui montrant que vous avez confiance en son expertise mais que votre devoir de conseils vous a obligé à lui présenter des alternatives pour choisir avec lui la meilleur solution pour lui.

Et dit toi bien qu'a la fin de toute facon comme c'est lui qui paye c'est lui qui a raison

[JoloKossovar]

Hi all,

Si le client veux du Tomcat et qu'il possède des compétences Tomcat, pourquoi aller contre sa volonté?

De plus c'est qui fera la production de l'application, donc je comprends qu'il est envie de capitaliser sur ses compétences,

Aller dans son sens c'est aussi le moyen de débuter la relation du bon pied en lui montrant que vous avez confiance en son expertise mais que votre devoir de conseils vous a obligé à lui présenter des alternatives pour choisir avec lui la meilleur solution pour lui.

Et dit toi bien qu'a la fin de toute facon comme c'est lui qui paye c'est lui qui a raison

c'est tarré mais c'est exactement ca ...
Quand a ton choix LeDaoud, je pencherai vers Tomcat puisque le client y est favorable et que rien technologiquement parlant ne te force a opter pour un serveur d'application.

[le Daoud]

Merci pour ta réponse,

Mon but est de trouver la meilleure solution pour le client, je n'ai aucune volonté de lui imposer un serveur d'appli (le fait que nous maitrisons plus JBoss est un argument, rien de plus). Je cherche à m'informer le plus loin possible pour déterminer les conséquences du choix de Tomcat, notamment en terme de devs à venir, mais aussi de perfs, d'admin...

Merci

Hi all,

Si le client veux du Tomcat et qu'il possède des compétences Tomcat, pourquoi aller contre sa volonté?

De plus c'est qui fera la production de l'application, donc je comprends qu'il est envie de capitaliser sur ses compétences,

Aller dans son sens c'est aussi le moyen de débuter la relation du bon pied en lui montrant que vous avez confiance en son expertise mais que votre devoir de conseils vous a obligé à lui présenter des alternatives pour choisir avec lui la meilleur solution pour lui.

Et dit toi bien qu'a la fin de toute facon comme c'est lui qui paye c'est lui qui a raison

[alexismp]

Le problème c'est que ça existe aussi avec Tomcat..

OK, j'ai pas été très clair:
- Administration: as-tu regardé la console GlassFish? Est-elle comparable à Tomcat?
- Clustering: peux-on faire du load-balancing et de la réplication de données stateful avec Tomcat?
- Intégration WebServices: GlassFish intègre JAX-WS et des WS sécurisés, fiables et optimisés (fast infoset, mtom). L'admin reflète cette intégration (stats sur les temps de réponse, transfo XSL, management JMX, ...)
- Performance: difficile à comparer puisqu'il n'y a pas de benchmark SPEC pour les conteneurs Web comme SPECjAppServer sert pour les AppServer. Disons que les records de perfs de GF sont en grande partie dus au frontal Grizzly qui ne se trouve pas dans Tomcat.

La valeur est dans l'intégration de toutes ces briques.
L'autre question c'est : qui fournit le support Tomcat?

[toomsounet]

OK, j'ai pas été très clair:
- Administration: as-tu regardé la console GlassFish? Est-elle comparable à Tomcat?
Je ne connais pas l'interface d'admin de Glassfish, mais c'est un point non négligeable en effet

- Clustering: peux-on faire du load-balancing et de la réplication de données stateful avec Tomcat?
oui on peut faire du load balancing et de la réplication de session

- Intégration WebServices: GlassFish intègre JAX-WS et des WS sécurisés, fiables et optimisés (fast infoset, mtom). L'admin reflète cette intégration (stats sur les temps de réponse, transfo XSL, management JMX, ...)
Me semble bien que JAX-WS soit utilisable avec Tomcat en SSL...

- Performance: difficile à comparer puisqu'il n'y a pas de benchmark SPEC pour les conteneurs Web comme SPECjAppServer sert pour les AppServer. Disons que les records de perfs de GF sont en grande partie dus au frontal Grizzly qui ne se trouve pas dans Tomcat.
Si dans ma boite on utilise une ferme avec exclusivement du Tomcat c'est que les temps de réponse ne doivent pas être pourris... et on connait pas du tout les contraintes de performance du client dans le cas traité ici

La valeur est dans l'intégration de toutes ces briques.
L'autre question c'est : qui fournit le support Tomcat?

Tu poses pas mal de questions de façon à orienter vers GlassFish qui est sûrement un excellent serveur mais avant de sortir l'artillerie lourde pour vendre à un client, on doit d'abord partir avec les contraintes qu'il a définies et regarder si c'est réalisable dans les coûts et temps définis.

Pour le support, ils ont l'air d'avoir pas mal de gens capables en interne et après tout je pense qu'ils y ont déjà pensé sinon ils n'orienteraient pas leur choix vers Tomcat..

.

[alexismp]

qu'entends-tu par "artillerie lourde"?

[toomsounet]

Sur le papier, si prendre un serveur d'application c'est facile à mettre en place, dans la réalité il y a pas mal de choses à faire dont integrer les applis existantes, former les utilisateurs et payer des consultants... (ceux de Red Hat par exemple facturent cher à l'heure...).

Je ne prêche pas contre le serveur d'appli juste pour préciser.

[alexismp]

Sur le papier, si prendre un serveur d'application c'est facile à mettre en place, dans la réalité il y a pas mal de choses à faire dont integrer les applis existantes, former les utilisateurs et payer des consultants... (ceux de Red Hat par exemple facturent cher à l'heure...).

Je ne prêche pas contre le serveur d'appli juste pour préciser.

C'est intéressant de voir la perception que les gens ont des serveurs d'applications. Je ne pense pas que l'expérience avec un produit soit représentative de tous les autres produits. Je ne pense pas non plus qu'il faille se payer nécessairement les consultants JBoss (ou de Sun pour GlassFish).

Par contre, je ne comprends pas "pas mal de choses à faire dont integrer les applis existantes"...

[wace]

payer des consultants... (ceux de Red Hat par exemple facturent cher à l'heure...)

Je croyais betement que c'etaient la seule raison d'exister des consultants... se faire payer (cher qui plus est...)

Sinon pour le contexte de ce topic, il me semble qu'a partir du moment ou c'est le client qui désire un produit parce qu'il a de l'experience avec, alors on peut raisonnablement penser que c'est lui qui se charge de l'integration, déploiement et production de l'application.

Dans ce cas la, il est important je trouve de verifier que les pré requis techniques de l'application collent aux spécificités du produit pour lequel le client à le plus d'affinités.

Et comme je l'ai déja dit, vu que c'est lui qui paye, c'est lui qui a raison

[rberthou]

Si le client veux du Tomcat et qu'il possède des compétences Tomcat, pourquoi aller contre sa volonté?

+1

Ne pas oublier que le client à toujours raison.. :-)

Par contre tu peux toujours proposer une autre solution en précisant bien les points positifs et négatifs de chaque produits et de voir ce qu'en pense les equipes du client possédant une compétence sur Tomcat.

[le Daoud]

Merci à tous pour vos réponses

Nous avons rédigé un document prenant en compte les éléments indiqués. Le client fera son choix en fonction. Etant donné l'exigence forte de sont côté d'éviter d'investir du temps dans un serveur non maitrisé et d'éviter d'avoir un "parc" hétérogène, je ne pense pas que l'heure du serveur d'application soit arrivée.

[wace]

Tu peux mettre le tag Résolu alors,

Clic sur le bouton Résolu en bas du topic