|
|
| Accueil |
|
|
Les grandes fonctions du serveur d'applications
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.
|
|
|
