Architecture: Http et Application

Bonjour,
J'ai passé pas mal de temps à apprendre le monde des applications web avec Java. Mes choix de technos sont Tapestry pour le framework web, Glassfish pour la partie application et Mysql5 pour la base de données.
Maintenant j'en suis à la conception de l'architecture et je me sens partir dans des directions compliquées ... C'est pourquoi je m'adresse à vous sur ce forum dédié au serveur d'application.

Voici en gros la direction dans laquelle part mon esprit, direction qui me semble sur-dimensionnée.

un serveur http (Lighttpd1.4 ou Apache2) pour servir directement les images et diriger les pages vers le framework web et aussi éventuellement diriger le load balancing.
un serveur Java (Tomcat5) pour le fonctionnement du framework web (Tapestry).
un serveur d'application (GlassfishV2) pour le fonctionnement de l'application.
et pour finir le serveur de base de données (Mysql5).

C'est joli mais me semble-t-il trop copieux. C'est vrai que celà dépend de la taille de l'application et du nombre de visiteurs prévus...

Peut être que ma question pourrait plus simplement être: est il judicieux de se passer du serveur HTTP et de laisser Tomcat en frontal web ?

Tout ceci manque de précision pour que l'on puisse y apporter des réponses précises, mais peut être pourriez vous simplement me donner vos habitudes de déploiement en fonction des applications, charges d'utilisation et de maintenance.

Merci d'avance
cyrille

Tout dépends de tes besoins.
Pour ma part, je déploie la plus tard du temps mes applications web sous tomcat, avec le connecteur ajp13. J'installe httpd 2.0 devant avec mod_jk linker en static. Ceci principalement pour 2 raisons:

1. L'environnement de déploiement est Linux ou solaris et il faut être root sous Unix pour lier le un port sous 1024 (donc le port 80) et je ne veux pas que Tomcat tourne en tant que root. Apache, lui, fork et drop le uid 0 dès qu'il peut!
2. Ce n'est peut-être plus d'actualité, mais httpd a réputation de servir du contenu static plus vite que Tomcat. Ainsi je fait un déploiement splitté de mes application entre static par httpd et jsp/servlet par tomcat.

Généralement, nos applications web n'utilise pas de serveur d'application, mais tout tourne dans Tomcat avec Spring. Nous ne déployons sous JBoss que la solution utilise une application riche comme client et la couche JMS.
La raison est simple: être le plus léger en resources possible.
Généralement le tout est une application qui utilise Postgresql comme base de donnée.

Cela donne des applications qui tourne sur un serveur OVH avec 2Gb de RAM, HDD RAID 1 et Dual Xeon. Tous les tiers sont sur la même machine et la solution sert de l'ordre de 15 tx/sec sans problème (plus le static).

Maintenant nous avons des applications qui tourne sur des monstres avec ms sql comme BD sur serveurs dédiés etc. Mais là nous ne sommes pas responsable de gestion du parc informatique et ne peut pas te renseigner sur l'utilisation du hardware, en plus le tout fait pas mal d'autre trucs...

Alex

Merci beaucoup pour ta réponse.

Citation:

---

Envoyé par a.snaps

... Tous les tiers sont sur la même machine ...

---

Comment gères tu la communication entre le tier présentation et le tier application ? Avec un des connecteurs de Spring ? Soap ? RMI ?

merci,
cyrille

Je me permet de joindre un petit schéma reprenant l'état de ma réflexion

Tout tourne non seulement sur la même machine, mais dans la même VM, sauf Apache httpd et Postgresql évidement la communication tcp/ip est comme suit;

Code:

---

1 2	httpd<-ajp13->tomcat<-tcp/ip->postgresql

---

Dans la VM, Spring "raccorde" l'architecture... tout en IoC

Alex

Je devrais peut-être ajouter que pour le framework de présentation, que ce soit WebWork (rien à faire), JSF, Struts ou autre, nous l'intégrons toujours avec Spring. Dans le cas de WebWork, où rien n'est à faire car il a lui-même à sa base Spring, t'es actions se voient injectées tes services (Bean de Spring) automatiquement selon la signature, le nom etc... soit:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public class UneAction implements Action {   private UnService unService;   public void setUnService(UnService service) { this.unService = service; }   public String execute() { unService.faitQuelqueChose(); ... } }

---

Lors de l'instanciation de l'action, Spring injecte le service UnService pour toi et il est à ta disposition.

Dans le cas de JSF, tu remplace le VariableResolver par celui qui délège à Spring si le nom du managed-bean n'est as connu pas JSF. Ainsi si tu as un bean Spring unServiceBienUtil, tu peux l'injecter dans un bean JSF via faces-config.xml en le référencant comme un managed-bean normal:

Code:

---

#{unServiceBienUtil}

---

Alex