|
|
Les Serveurs
d’applications |
Présentation RIO Janvier 2002 |
|||
|
2. Architecture
Technique |
Page précédente Sommaire Page suivante
2.1 Typologie des serveurs d’applications
|
Serveurs d'applications de
type scripting |
|
Les serveurs d'applications de type scripting forment une catégorie bien particulière dans le milieu des serveurs d'applications. Ceux-ci se caractérisent par une approche presque totalement orientée interface hypertexte. En effet, pour bien comprendre le fonctionnement de ce type d'environnement, il faut percevoir les applications HTML dynamiques comme une juxtaposition de pages HTML statiques enrichies d'éléments HTML générés dynamiquement. L'élément fédérateur de ce type de serveur d'applications est donc la page HTML statique. C'est autour de cette dernière que seront articulés les traitements applicatifs et à laquelle seront ajoutés les concepts dynamiques spécifiques aux besoins requis. Pour simplifier, on peut dire dans un premier temps qu'à chaque page HTML dynamique d'une application web issue d'un serveur d'applications de type scripting correspond un et un seul fichier source. Ce fichier contient un ensemble de données liées à l'interface HTML (balises HTML + langage de scripting client) ainsi que l'ensemble du code applicatif destiné à donner de la dynamicité à l'application. Il y a en effet une relation d'identité entre la page HTML visualisée par l'utilisateur, et le fichier source élaboré par le développeur, de manière similaire à un contexte d'enchaînement de pages HTML statiques. Il est possible d'externaliser des traitements dans des fichiers externes, mais le mode de fonctionnement général reste celui présenté ici. En fait, la différence de traitement se fait simplement lors de la demande d'une page par l'utilisateur. Soit il s'agit d'une demande de page HTML statique et le serveur HTTP renvoie cette page, soit il s'agit d'une page dynamique, et le serveur HTTP délègue la gestion de la page au serveur d'applications. Celui-ci va analyser et traiter le fichier source demandé pour retourner via le serveur HTTP la page générée vers le navigateur de l'utilisateur.
Dans une telle situation, le rôle du serveur d'applications sera avant tout de parser le contenu du fichier source. Appliquée à un serveur de type scripting, une interprétation plausible du terme " parser " peut être représentée par l'ensemble des séquences suivantes : ouverture du fichier, parcours de son contenu, interprétation de la partie " script serveur ", puis assemblage des parties statiques avec le résultat des traitements générés par l'interprétation du code. Une fois la concaténation des différentes parties effectuée, le résultat est renvoyé au serveur HTTP. |
|
Serveurs d'applications de
type objet |
|
Le fonctionnement technique interne d'un serveur d'applications n'est pas forcément basé sur des pages orientées interface hypertexte contenant l'ensemble des traitements dynamiques à réaliser. En effet, il existe des serveurs d'applications dont le principe technique repose sur des mécanismes internes propres. Nous n'analyserons pas ici l'ensemble des solutions existantes, mais nous exposerons quelques mécanismes généraux. La partie du moteur exécutif chargée d'assembler les pages ne se repose pas forcément sur un seul fichier contenant les éléments de présentation et les codes de traitements. Par exemple, certains moteurs se basent sur plusieurs fichiers et sur plusieurs moteurs dont chacun possède un rôle spécifique. Dans le cas des serveurs d'applications de type objet, les traitements fonctionnels sont généralement séparés des traitements d'interface, eux-mêmes pouvant être séparés des ressources d'interface (comme les éléments d'interface statique purs). Ce type de fonctionnement complexifie l'architecture applicative et avec elle sa propre modélisation. En revanche, l'atout principal de ces serveurs d'applications, hormis leur modélisation objet, est d'offrir une souplesse dans la répartition et la gestion des traitements. Il devient possible de répartir les traitements choisis à l'endroit où on le souhaite, en environnement distribué, par exemple. |
|
Serveurs d'applications de
type J2EE |
|
Aujourd'hui, parmi les serveurs d'applications objet se démarque une solution majeure : J2EE. En vogue depuis plus de deux ans, les serveurs d'applications J2EE proposent une architecture et un mode de fonctionnement standardisés. Cette architecture repose sur l'ensemble des spécifications Java 2 Enterprise Edition éditées par Sun. L'idée principale de J2EE est de fournir le maximum de spécifications qui répondent aux besoins d'un développement applicatif et cela dans un environnement Java. A ce titre, toute implémentation des spécifications respectant J2EE constitue un serveur d'applications à part entière. Le propos de cette introduction n'est pas de parcourir en détail l'ensemble de ces spécifications et des besoins auxquelles celles-ci répondent précisément. Nous proposons d'exposer synthétiquement les trois spécifications les plus communes que l'on retrouve au sein d'une application web. Il s'agit aujourd'hui des API Java Servlet, JSP et EJB. Ces normes apparaissent complémentaires et répondent globalement à des choix de développement bien spécifiques. Java Servlet : les implémentations des API Java Servlet fournissent une méthode d'extension des serveurs HTTP à des traitements dynamiques via un moteur de servlets. Les servlets sont des programmes écrits en Java. Dans ce cas, l'exécution des servlets permet de réaliser des traitements Java côté serveur, dont l'un des objectifs est de renvoyer au serveur HTTP le flux (HTML par exemple) constituant la réponse que le serveur HTTP retransmet au client. La page (flux HTML) que reçoit le navigateur est donc présente, statiquement ou dynamiquement, dans le code Java de la servlet. JSP (Java Server Pages) : l'implémentation des API JSP permet, par opposition aux API Java Servlet, d'embarquer du code Java au sein même des pages HTML. Ce moyen permet de retrouver la notion de page d'interface au sein de laquelle les traitements sont définis. Ainsi, les concepteurs peuvent retoucher graphiquement, à l'aide d'un outil WYSIWYG par exemple, le design de leurs pages HTML. Il est important de noter qu'à l'exécution, le moteur de JSP génère une servlet.
EJB (Enterprise JavaBeans) : les EJB sont des composants Java, dont l'un des objectifs principaux est de renfermer la logique métier d'une application. L'implémentation des EJB propose un véritable modèle d'architecture objet et de développement par composant métier. Dans un tel contexte, l'utilisation des EJB passe obligatoirement par une modélisation objet. Un projet EJB implique une problématique forte de persistance objet qu'il faudra résoudre. Si les EJB répondent partiellement à la persistance, les projets mettant en œuvre une modélisation complexe devront traiter cette difficulté de manière sérieuse. |
|
Solution de persistance des
données contenues dans les EJB |
|
La deuxième solution consiste à implémenter soi-même l'ensemble des mécanismes de gestion de la persistance. Cette solution apparaît fastidieuse et délicate dès qu'un projet devient conséquent. Les performances ne sont plus garanties, ou à l'inverse les techniques garantissant un minimum de fiabilité ne sont pas à la hauteur. Mais une telle entreprise est toujours envisageable et les API Java minimales et nécessaires à son développement sont présentes au sein de J2EE. Enfin, la troisième solution s'appuie sur un dispositif à part entière, qui est un système de gestion automatisée de mapping objet-relationnel. Ces produits permettent de gérer la persistance des graphes d'objets au sein d'un système de gestion de base de données relationnel. Dans le cas de projets EJB devant tenir compte d'un existant relationnel conséquent, l'utilisation d'une offre de mapping objet-relationnel constitue l'une des solutions généralement la plus adaptée et la plus utilisée. Il est cependant important de noter que pour des mapping complexes, les éditeurs se reposent majoritairement sur des offres tierces. |
Rôle de XML |
|
Un serveur d'applications dit " XML " n'a pas de signification particulière en tant que tel. En réalité, l'intégration de XML au sein des serveurs d'applications peut apparaître à des niveaux totalement différents et donc répondre à des besoins très distincts. Dans certains cas, XML apparaît du côté back-office comme une solution d'échange d'informations, et dans d'autres cas, on voit apparaître XML du côté de l'interface client comme un complément de HTML. Ainsi, de nombreux serveurs d'applications génèrent automatiquement les fichiers XML ainsi que leurs DTD associées. En tout état de cause, XML ne modifie pas les principes de fonctionnement interne d'un serveur d'applications notamment au sein de sa partie moteur d'exécution. XML trouve sa force du côté client dans l'extension et la polyvalence des flux d'interface, et surtout côté back-office, dans la normalisation des échanges de données. |
2.2 Les grandes fonctions du serveur d'applications
Présentation |
|
Au cœur du système, le serveur d'applications fournit un environnement d'exécution et un ensemble de services aux applications. De manière imagée le serveur d'applications est placé entre le système d'exploitation situé en bas, l'application en haut, le serveur web à gauche et le back-office à droite. Ainsi, cette position centrale le conduit à offrir ses services à plusieurs niveaux. En outre, il convient de préciser que l'outil de développement et celui d'administration ont chacun leur rôle à jouer en phase de développement et de production afin de compléter les fonctionnalités du serveur d'applications. Sans pouvoir être exhaustif dans la liste des besoins auxquels se doivent de répondre les serveurs d'applications, quelle que soit leur catégorie d'appartenance, voici décrite une liste qui recouvre la plupart des grandes fonctionnalités attendues :
|
|
Le support des
plates-formes |
|
Le support des principales plates-formes du marché est une qualité première attendue chez ce type d'outil. Tout l'enjeu de cette fonctionnalité est de désolidariser la technologie applicative de la machine hébergeant l'application afin d'offrir davantage de liberté et d'évolutivité. Pour ce faire, le serveur d'applications doit implémenter un ensemble d'API propre à chacun des nombreux systèmes d'exploitation. A titre d'exemple, lorsqu'une application fait appel à des fonctions dites système telles que l'ouverture, l'écriture, la lecture ou la suppression de fichiers, le serveur d'applications doit être en mesure de les exécuter indépendamment de la plate-forme utilisée. |
|
Répartition de charges |
|
Un des devoirs du serveur d'applications est d'assurer la fiabilité et les performances de l'application. Dans ce contexte, la fonctionnalité de répartition de charges joue un rôle essentiel. D'un point de vue technique, cette approche se traduit généralement par l'exécution de plusieurs instances (ou process) qu'il est possible de répartir sur différentes machines serveur. Cette architecture permet également de scinder l'application en modules différents, sans avoir l'obligation de reproduire sur chacun des serveurs la totalité d'une application. Ainsi, un module fréquemment sollicité peut être isolé sur un seul serveur afin d'absorber plus facilement la charge. A ce niveau, les solutions basées sur les technologies objet disposent d'atouts certains pour la mise en place d'architectures complexes. La distribution des objets permet en effet de répartir plus simplement différents modules sur différents serveurs.
|
La disponibilité |
|
Dans une configuration où l'application est répliquée sur plusieurs serveurs physiques, il est plus facile de mettre en place la fonctionnalité de reprise sur incident. En cas de " plantage " au niveau applicatif ou serveur, la requête utilisateur est redirigée vers un serveur disponible de manière transparente. La tolérance aux pannes à ce niveau permet d'offrir la disponibilité au niveau application puisqu'il existe toujours un module actif pouvant être invoqué par les utilisateurs. Toutefois, le serveur d'applications doit être également capable de maintenir l'ensemble des opérations effectuées par l'utilisateur. Pour éviter des désagréments néfastes, il doit donc prévoir la sauvegarde du contexte utilisateur. Cela implique la réplication des sessions utilisateur sur une autre machine. A ce niveau, cette réplication se fait soit en base de données, soit sur disque, soit en mémoire. Les serveurs d'applications les plus avancés automatisent la gestion de reprise sur incident au niveau session. |
|
Le pooling de connexions |
|
En architecture web, l'ensemble des utilisateurs accède à la base de données depuis le serveur d'applications. Cette connexion peut être ponctuelle, mais les temps de réponse deviennent alors catastrophiques. La solution la plus couramment retenue consiste à passer par un pool de connexions. Ceci consiste à démarrer un nombre prédéfini de connexions vers un SGBDR. Le serveur d'applications dirige ensuite les demandes utilisateur en répartissant les différentes requêtes sur les connexions disponibles. Ceci permet d'avoir la maîtrise du nombre de connexions maximales ouvertes et d'éviter le goulet d'étranglement à ce niveau. Dans un contexte où l'application est répartie sur plusieurs serveurs, une autre fonctionnalité attendue est la gestion des connexions dans un mode multi-instances. Le paramétrage d'un pool de connexions s'effectuant la plupart du temps au niveau application, chaque instance applique naturellement la formule retenue en terme d'ouverture de connexions. Le serveur d'applications doit à ce niveau répartir les différentes connexions entre les différentes instances. |
|
L'ouverture vers
l'existant, le respect des standards |
|
En architecture web transactionnelle, la reconnaissance des serveurs HTTP et l'accès aux principales bases de données relationnelles du marché par le serveur d'applications est une condition " sine qua non ". Ces ponts ne se révèlent cependant pas suffisants dans la plupart des contextes, tout d'abord parce que peu d'applications fonctionnent de manière isolée. En effet, les entreprises possèdent généralement un existant auquel il faut s'interfacer. Ainsi, l'ouverture vers les protocoles de communication, les principaux ERP et les mainframes est indispensable pour ne pas limiter fonctionnellement l'application. Ensuite, dans la même optique, l'évolutivité et la pérennité de l'application dépendent en partie de la capacité du serveur d'applications à respecter les standards tels que Java, XML et à intégrer les nouvelles technologies. |
|
La gestion de contexte |
|
Aujourd'hui, il n'est pas imaginable de réaliser des sites transactionnels sans mettre à profit les capacités de gestion de contexte. Le principe de gestion de contexte consiste à conserver le temps d'une session les données propres à l'utilisateur contrairement aux variables d'application qui ne sont rien d'autre que des variables globales. Toutefois, les variables de session spécifiques à un utilisateur ne sont envisageables que si l'utilisateur peut être identifié. Une des fonctionnalités de base du serveur d'applications est de gérer automatiquement cette identification, suivant une des trois méthodes : le cookie, l'URL long et la variable cachée. Ceci permet au serveur d'applications de créer un espace mémoire dédié à chaque utilisateur. C'est à ce niveau, généralement dans un objet session, que vont être stockées les informations spécifiques à chacun des utilisateurs. Un serveur d'applications particulièrement étoffé sera celui qui proposera nativement tout un ensemble de fonctions permettant de gérer le plus finement possible ces sessions utilisateur : définition d'un time-out, lancement d'un événement en fin de session, etc. |
La sécurité |
|
Si la sécurité au niveau HTTP n'est pas une fonctionnalité qui concerne directement le serveur d'applications, ce dernier se doit de faciliter sa mise en place. En effet, il est important de noter que la phase de cryptage/décryptage des pages est particulièrement coûteuse en temps, et peut considérablement pénaliser les performances. Cette problématique de dégradation des performances est donc importante. Pour cela, et étant donné que l'ensemble des pages d'une application n'a pas à être sécurisé (ou exceptionnellement), il est important de pouvoir déployer des applications utilisant à la fois les services sécurisés et également les services non sécurisés. C'est à ce niveau qu'interviendra le serveur d'applications, qui doit permettre de déployer une même application s'adressant à deux ports HTTP différents. Enfin, à ce niveau, l'outil de développement peut également offrir des facilités pour mettre en place une même application à deux niveaux. Dans le cas idéal, les outils de développement possèdent dans les propriétés de chacune des pages HTML dynamiques une case à cocher précisant si la page doit être sécurisée ou non. L'atelier de développement propose également de saisir les ports de chacun des deux modes afin de réduire au maximum cette tâche lors de la phase de déploiement. Au-delà de la gestion de la sécurité par cryptage des informations, les outils doivent également proposer un système d'authentification. Cela passe généralement par une validation côté serveur, avec contrôles effectués dans des annuaires LDAP, des SGBDR, ou tout autre source de données permettant d'identifier les utilisateurs. |
L'administration |
|
Tout serveur d'applications de bonne facture est livré avec un outil d'administration qui se présente sous la forme d'une interface web ou d'une console. En laissant de côté les fonctionnalités élémentaires de cet outil, il doit favoriser le réglage du serveur d'applications. Ce réglage est nécessaire afin d'adapter et d'ajuster les points sensibles de l'application en cas de montée en charge importante. Dans le cadre d'une architecture multi-serveurs, l'outil d'administration doit proposer un paramétrage avancé au niveau du répartiteur de charges comme le choix de l'algorithme de répartition par exemple. Concernant la fonctionnalité de disponibilité applicative au niveau session, là encore l'outil doit fournir une interface proposant différentes solutions de sauvegarde. Au niveau du pooling de connexions, un outil d'administration doit permettre de dimensionner l'accès à la base de données en spécifiant par exemple un nombre de connexions au démarrage, le nombre maximum de connexions ouvertes en tout, etc. Si l'application repose sur une technologie objet, le déploiement des composants dans le serveur d'applications s'opère également depuis cette interface. Enfin, la présence d'un outil de statistique est toujours une fonctionnalité intéressante. En effet, la génération de graphes d'utilisation à partir des logs HTTP, SQL ou d'échange entre instances d'objet offre un premier retour sur la sollicitation des différents modules de l'application. |
La productivité |
|
En phase de développement, la productivité est étroitement liée à la maturité de l'outil de développement, mais aussi à la qualité de l'interface entre ce dernier et le serveur d'applications. Ainsi, l'atelier de développement doit offrir aux développeurs le moyen de réaliser des applications web fiables dans un minimum de temps et d'effort. Pour ce faire, un atelier de développement incomplet doit au moins pouvoir s'interfacer de la manière la plus transparente possible avec les autres outils de production. Le développement d'une application étant rarement le travail d'une seule personne, une interface avec les outils de gestion des développements en équipe tels que PVCS ou VSS s'imposent. De la même manière, dans le cadre d'un projet utilisant la technologie objet, un pont vers les outils de modélisation tels que PowerAMC ou Rational Rose est de rigueur. A partir de là, les équipes de développement possèdent une bonne base d'outils pour démarrer leur projet. Pour revenir à l'atelier de développement à proprement parler, une des fonctionnalités couramment utilisées lors de la réalisation d'un site web concerne l'éditeur HTML WYSIWYG qui permet la génération des interfaces graphiques. Sa présence évite l'écriture simple mais fastidieuse du code HTML. Tout au long de la phase de développement, l'atelier doit fournir des fonctionnalités simplifiant la tâche de l'utilisateur et augmentant la productivité du projet. Ainsi, comme toute application web transactionnelle se connecte forcément à une base de données, une manière de répondre au besoin précédent est d'offrir des assistants capables de se greffer au SGBDR et de permettre la saisie de requêtes dynamiques, la saisie de jointures ou encore la sélection de procédures stockées. De plus, l'intégration d'un éditeur SQL dans l'atelier de développement offre le moyen de tester les requêtes en temps réel. Enfin, l'outil doit envisager des fonctionnalités avancées en terme de débogage. Effectivement, la possibilité d'effectuer du pas à pas sur le code applicatif, de poser des points d'arrêt, d'entrer ou non à l'intérieur du code des fonctions ou des méthodes exécutées, d'interroger et/ou de modifier les valeurs des variables en temps réel procure un gain de temps considérable en phase de développement. |
