Serveur d'application
I.1. Composants d’un serveur d’application
Un serveur d'application est un élément logiciel, qui formellement ressemble à un serveur Tomcat (conteneur web). La différence est qu'il expose plus de fonctionnalités, et est capable de fournir de nombreux services. Citons-en ici quelques-uns :
• JNDI => association d'un "nom" à un "objet" type IP, DNS, Connexion à une BDD...
• EJB => sorte de Bean (objet + interface) appartenant à un contexte et appelable via le JNDI
• Il permet de gérer des applications web, et de répondre aux requêtes HTTP sur le port 80 (entre autres).
• Il est capable de se connecter à des bases de données, et d'exposer ces connexions sous forme de data sources (sous forme de bean par exemple). Il gère les transactions, distribuées ou non, de ces bases.
• Il peut se connecter à un service de messagerie (mail), et d'exposer ce service dans son annuaire (JNDI).
• Il gère la journalisation de tous ces éléments, de même que le suivi des performances, et différentes fonctions de monitoring.
• Enfin, il a une vision globale de tous les composants qu'il gère, et est capable de les faire dialoguer les uns avec les autres, notamment sous forme d'injection de dépendances.
Ces composants sont généralement présents dans beaucoup de serveur d’applications.
Ils permettent une gestion et une évolution de l’application plus simple à mettre en place.
I.2. A quoi doit répondre un serveur d’application
Il doit répondre aux contraintes induites par les architectures centralisées :
• Gestion de contextes (différenciation des clients/temps de session par le biais de cookies, d’URL long ou encore de variable cachée)
• La répartition de charge (exécution de plusieurs instances réparties sur différentes machines) et le pooling de connexions (évitant la création de goulet d’étranglement)
• Les reprises sur incident l’application est répliquée sur plusieurs serveurs physiques. En cas de « plantage » au niveau applicatif ou serveur,