Aujourd’hui on va essayer de répondre à la question déroutante que tout développeur à du une fois dans ça vie la posé et qui est : « Quelle est la différence entre un serveur web et serveur d’application ? ».
Pour répondre à cette question je vous propose d’exposer les différentes couches à empiler pour arriver à monter un serveur d’application.
Couche 1 : Serveur web Http
Pour commencer, il nous faut tout d’abord : Un serveur http, c’est un serveur qui gère exclusivement des requêtes HTTP. Il a pour rôle d’intercepter les requêtes Http, sur un port qui est par défaut 80, pour les traiter et générer ensuite des réponses Http. Tous les serveurs web embarquent un daemon Http (httpd) ou équivalent qui s’occupe de cette fonctionnalité
Exemple des serveurs web les plus connus : Apache, Nginx, Lighttpd, IIS…
Ces logiciels intègrent généralement des modules permettant d’exécuter un langage serveur comme PHP pour générer des pages web dynamiques
Les fonctionnalités d’un serveur WEB :
A part sa fonction basique qui est d’intercepter et de répondre en Http, un serveur web peut avoir d’autres fonctionnalités tel que
- La gestion de la sécurité, comme les fonctionnalités de restriction des accès par domaine, par utilisateur, par groupe ou par adresse IP,
- La gestion du contenu, comme la redirection des requêtes http, la personnalisation des messages d’erreurs, ou la gestion des timeout..
dans le serveur apache par exemple ces fonctionnalités sont implémentées sous forme de modules (mod_alias, mod_authn_core, mod_proxy…).
Couche 2 : Conteneur web
Ensuite, on va étendre notre serveur web pour devenir un conteneur Web. Cette extension va permettre d’avoir la possibilité d’exécuter des programmes écrits avec des langages de programmation ( java, php, C# ou autres ) dans le serveur web.
Par exemple le serveur Tomcat n’est autre qu’un serveur Apache couplé avec un moteur web java et, les serveurs tel-que easyPhp, wamp ou Xamp ne sont que des serveurs Apaches couplés avec un moteur web php.
Maintenant, on va se concentrer sur le serveur Tomcat qui est un conteneur web java (et pas un serveur d’application jee), pour analyser son architecture.
Le conteneur web Tomcat, est composé d’un moteur jsp, un moteur servlet et d’un descripteur de déploiement pour les modules web de type war. Ces moteurs sont en réalité des API qui sont implémentés dans le serveur Tomcat, et qui permettent de faire déployer seulement des applications web Java de type war.
Les applications java de type EAR, ne peuvent pas être déployées dans Tomcat, parce que tout simplement le serveur manque les API nécessaires et conformes aux spécifications pour l’implémentation des serveurs d’application java jee.
Par exemple, si vous utiliser la bibliothèque JPA dans votre application web et vous le déployez sur un serveur Tomcat, vous serez obligé d’embarquer les jars JPA dans le répertoire lib de l’application, alors que si vous déployez sur un serveur d’application comme JBOSS, vous n’aurez besoin d’aucun jar additionnel.
Couche 3 : Serveur d’application
Donc, vous l’avez bien compris, il faut étendre encore plus le serveur Tomcat pour devenir un vrai serveur d’application java jee.
L’extension nécessaire est composée de deux parties essentielles :
- Un conteneur EJB qui encapsule les traitements des Entreprise JavaBeans.
- Un ensemble de services répartie en :
- Des services d’infrastructures
- JDBC (Java DataBase Connectivity) API d’accès aux bases de données relationnelles.
- JNDI (Java Naming and Directory Interface) API d’accès aux services de nommage et aux annuaires d’entreprises.
- JTA/JTS (Java Transaction API/Java Transaction Services) API pour la gestion de transactions.
- JCA (JEE Connector Architecture) API de connexion au système d’information de l’entreprise comme les ERP.
- JMX (Java Management Extension) API permettant de développer des applications web de supervision d’applications
- Des services de communication:
- JAAS (Java Authentication and Authorization Service) API de gestion de l’authentification.
- JavaMail API pour la gestion de courrier électronique.
- JMS (Java Message Service) API de communication asynchrone entre application.
- Des services d’infrastructures
Tableau comparatif serveur d’application vs serveur web
Serveur web | Serveur d’application | |
Déploiement WAR | Oui | Oui |
Déploiement EAR | Non (seulement servlets et JSP) | Oui |
Pool de connexion | Non | Oui |
Gestion des transactions distribuées | Non | Oui |
Traitement JMS | Non | Oui |
Clustring | Non | Oui |
Load balancing | Non | Oui |
Fonctionnellement | Héberge exclusivement des applications web (Ihm ou web service) en accès HTTP | Peut héberger en plus des applications d’entreprise EAR qui utilisent des ressources JMS |