|
|
Les Serveurs
d’applications |
Présentation RIO Janvier 2002 |
|||
|
1. Introduction |
Page précédente Sommaire Page suivante
1.1 Qu'est-ce qu'un serveur d'applications ?
|
Le serveur d'applications
comme réponse à un besoin |
|
Il serait bien prétentieux de prétendre pouvoir formuler, de manière pertinente et reconnue par tous, une définition universelle de l'élément de l'architecture technique connu sous l'appellation "serveur d'applications". Ce terme, galvaudé bien avant d'avoir été compris par tous, ne représente pas le même produit suivant l'interlocuteur. Dans la littérature et la presse spécialisée, au sein des sociétés de service et des web agencies ou encore auprès des consultants en nouvelles technologies, le terme serveur d'applications signifiera à tour de rôle un serveur d'objets, un moteur d'exécution pour le Web, un outil de développement, d'administration, de déploiement et d'exécution, un serveur de traitements, une solution d'e-commerce, etc. Dans cette présentation, le choix qui a été effectué est de catégoriser le serveur d'applications en fonction du besoin. La définition de celui-ci a été élaborée à partir des questions " Qu'attend-on d'un serveur d'applications ? Qui a besoin d'un serveur d'applications ? ". Les réponses à ces interrogations se trouvent directement sur le terrain, aux contacts des entreprises qui souhaitent s'orienter vers le Web. Ici, par web, on entend toute application ou site transactionnel s'appuyant sur le protocole HTTP, qu'elle soit de type internet, intranet ou extranet. Globalement, la réponse à une telle question est de proposer "un environnement de l'architecture qui fournit les briques techniques nécessaires à l'exécution d'applications transactionnelles web". En détaillant les fonctionnalités attendues pour couvrir ce besoin, on arrive à la conclusion qu'un serveur d'applications doit :
Le premier module que doit proposer le serveur d'applications concerne l'interface avec le serveur HTTP. Pour le développeur, ceci se traduit par l'absence de développement pour envoyer une chaîne vers le serveur web, afin de se concentrer sur le contenu et non pas sur la façon d'envoyer la page web. Celle-ci sera de type HTML ou l'un de ses dérivés, de type XML, bien que ce format ne soit pas encore nativement reconnu par la majorité des navigateurs, ou encore de type WML pour les clients WAP. Le moteur d'exécution des traitements représente la condition indispensable pour réaliser des applications dynamiques. Il est intéressant à ce niveau de noter qu'il est possible de créer un exécutable indépendant, mais que ce mode de fonctionnement ne facilite pas la couverture des autres points décrivant un serveur d'applications. Avec l'arrivée massive de Java et de J2EE côté serveur, ce moteur d'exécution est aujourd'hui majoritairement la machine virtuelle Java (JVM). Le troisième point concerne l'ouverture vers l'existant. Cet aspect est important dans la mesure où les données et les traitements à réutiliser sont généralement présents dans d'autres éléments de l'architecture. Le serveur d'applications doit donc permettre l'accès aux SGBDR, aux ERP, aux composants d'applications externes, aux moniteurs transactionnels, aux systèmes centraux, etc. J2SE, nouvelle mouture du JDK, propose déjà certaines API permettant de s'ouvrir vers l'extérieur. Egalement, un serveur d'applications doit être adapté pour répondre aux problématiques techniques inhérentes à l'architecture centralisée. A ce niveau, on retrouve entre autres la gestion de contexte nécessaire pour différencier les utilisateurs, la répartition de charges et le pooling de connexions pour offrir des solutions palliatives aux montées en charge, ou encore la fonctionnalité de reprise sur incident pour rendre l'application disponible à tout instant. Enfin, la possibilité de développer des briques techniques et métier pour améliorer le rendement constitue un élément essentiel d'un serveur d'applications. En effet, celui-ci est initialement prévu pour permettre aux équipes de développement de s'affranchir de l'ensemble des problématiques techniques des architectures web. Cependant, des contextes particuliers de l'entreprise impliquent parfois une amélioration du moteur, ou la nécessité de développer une fonctionnalité non prévue dans le serveur d'applications. Pour cela, il doit être possible d'enrichir ou de passer outre les fonctionnalités du serveur d'applications, afin de modeler son environnement à un contexte bien spécifique. L'ensemble des fonctionnalités attendues pour un serveur d'applications est présenté de manière plus détaillée dans le chapitre 2.2. |
|
Quels sont les
environnements qui peuvent répondre au même besoin ? |
|
La grande majorités des serveurs d'applications respectent les cinq principes énumérés ci-dessus. Certains omettent un de ces éléments (par exemple ouverture vers le serveur HTTP), mais l'ajout d'un module élémentaire permet de pallier ce manque. D'un point de vue général, deux autres types de produits sont assez proches de la définition qui est faite dans ce document d'un serveur d'applications. Ces deux autres solutions, qui permettent de répondre plus ou moins bien à la réalisation d'applications transactionnelles web, sont les moteurs de servlets et les outils d'IRM. Les solutions de e-commerce, de B2B ou encore de personnalisation, proposées par la majorité des éditeurs, ne sont que des briques métier, c'est-à-dire des frameworks prêts à l'emploi, ajoutés au serveur d'applications du même éditeur. Leur objectif est donc d'accroître la productivité lors de la réalisation d'applications dédiées, mais ces offres s'appuient toujours sur un serveur d'applications sous-jacent. Les moteurs de servlets ne peuvent pas être considéré comme des serveurs d’applications à part entière : Les lacunes les plus importantes de ce type d'outils concernent le manque de richesse des API proposées, limitant les possibilités d'ouverture vers l'existant et ne fournissant pas suffisamment de briques techniques pour le support des technologies web. Par exemple, les moteurs de servlets se reposent principalement sur J2SE, mais ne fournissent pas une gestion poussée des sessions, sont souvent assez peu performants en terme de reprise sur incident, et n'accèdent pas aux ERP, aux moniteurs transactionnels, aux MOM, etc. Toutefois, même en considérant que le moteur de servlets constitue la brique minimale d'un serveur d'applications, ces moteurs, sont néanmoins inclus dans des offres plus performantes en terme de fonctionnalités, tel que, les moteurs de servlets Tomcat ou encore JServ. Il en va de même pour les versions d'entrée de gamme d'autres éditeurs de solutions basées sur J2EE. L'autre catégorie de produits pouvant répondre aux problématiques de réalisation et d'exécution d'applications transactionnelles web est constituée par les outils d'IRM (Internet Relationship Management). Ces produits permettent, via la définition de règles et le paramétrage d'un moteur, de répondre plus simplement à certaines problématiques comme la réalisation d'applications de gestion de contenu, de modules personnalisés, etc. La différence majeure entre les serveurs d'applications et ce type de solutions, apparentées à des progiciels, concerne l'absence de souplesse des développements. Il est en effet très difficile de réaliser des briques techniques ou même des fonctionnalités métier à partir du moment où celles-ci ne sont pas implémentées dans l'outil. Ceci se traduit par des difficultés importantes dès qu'il s'agit de s'ouvrir vers l'existant, de répondre à certaines spécificités des architectures web, voire même de mettre en place des fonctionnalités répondant à un besoin métier spécifique. |
|
|
|
Le serveur d'applications fixe les limites des réalisations en termes d'exécution et de richesse fonctionnelle. A ce niveau, les axes développement, déploiement et administration sont omis. Afin d'être le plus complet possible, la présentation des différentes solutions se fera en étudiant l'ensemble des serveurs d'applications couplés avec les outils de développement et d'administration fournis par le même éditeur. A ce niveau, il convient de noter que les éditeurs de serveurs d'applications souhaitant respecter les derniers standards en vogue, tel J2EE, préconisent parfois l'utilisation d'un atelier de développement d'une offre tierce. Cette approche est pénalisante à plus d'un titre, et présente comme principal inconvénient d'obliger les entreprises à passer par deux interlocuteurs différents pour le support et la maintenance : l'éditeur de l'IDE et l'éditeur du serveur d'applications. De manière plus complète, le serveur d'applications doit donc idéalement :
Ces deux aspects constituent aujourd'hui une problématique
importante des serveurs d'applications. En effet, en séparant la partie
développement de la partie déploiement, notamment à cause de l'arrivée de
standards côté serveur, l'intégration entre l'outil de développement et le
serveur d'applications s'est évidemment fortement dégradée. Pour cette
raison, il est important de prendre cette problématique très au
sérieux. |
|
|
|
|
1.2 A quoi sert un serveur d'applications ?
|
Rappel : Qu'est-ce
qu'une architecture web ? |
|
Les environnements
web dynamiques, qu'ils soient de type transactionnel ou non, correspondent à
des architectures presque entièrement centralisées. Contrairement aux
architectures de type client-serveur n-tiers dont une partie importante des
traitements fonctionnels et métier se trouvent réalisés sur le poste client,
les architectures web délèguent la quasi totalité des traitements
fonctionnels à une partie centralisée de l'architecture. Dans ce contexte,
c'est le serveur d'applications qui prend cette nouvelle charge de
traitements pour l'ensemble des postes client. L'importance et l'intérêt du serveur d'applications présent au cœur
de toute architecture web dynamique proviennent de cette centralisation des
traitements. Le serveur d'applications devient le moteur
applicatif, c'est-à-dire le principal responsable du fonctionnement de
l'application. |
|
Qu'entend-on par "
application web " ? |
|
Quelle différence peut-on faire côté client entre une application de type web (internet, intranet ou extranet) et une application de type client-serveur ? Une première réponse est apportée par les logiciels du poste client dont le rôle est fondamentalement différent. Dans le cas des architectures client-serveur, la partie client de l'application est responsable de l'exécution de traitements fonctionnels au moins partiels, alors que dans le cas des architectures web, le navigateur n'a pas de rôle fonctionnel majeur. On précise cependant qu'il est possible de faire exécuter du code au sein même des navigateurs (langage de scripting client). Sachant que l'utilisateur peut désactiver l'exécution du moteur de code, il est fortement conseillé de n'utiliser ces langages du côté client que pour des contrôles de saisie ou pour des fonctionnalités applicatives mineures. Au-delà du logiciel client, c'est l'utilisation même des applications qui diffère selon que l'on soit en architecture client-serveur ou en architecture web. Le terme " utilisation " désigne la manière dont l'application est sollicitée, parcourue, manipulée, ouverte, accédée, fermée ou encore " naviguée ". D'une manière générale, une application web correspond à toute application utilisable depuis un navigateur web qui respecte le protocole HTTP dans son mode de fonctionnement technique. Il s'agit précisément des applications basées sur des interfaces de type HTML ou XML. Les éléments supplémentaires pouvant venir s'insérer au sein des applications, comme les images, les applets de type cosmétique ou les autres éléments, sont considérés comme appartenant au DOM (Document Object Model) et leur ajout ne dénature pas le fonctionnement technique des architectures web. Ces différents éléments enrichissent certaines fonctionnalités en faisant partie intégrante de ce type d'application web. En revanche, tout autre type de fonctionnement technique n'est pas considéré comme une architecture web, et ne nécessite donc pas forcément l'usage de l'un des serveurs d'applications. Nous ne traitons pas ici des dialogues dérivés permettant d'établir des connexions permanentes entre un navigateur web et un serveur d'applications de type client-serveur n-tiers. Cela concerne, par exemple, les applications client-serveur Java dont l'initialisation et l'utilisation se font à travers un navigateur web, mais dont l'architecture technique correspond à celle d'une architecture de type client-serveur n-tiers. De même, tout fonctionnement technique autre qu'un dialogue " client HTTP-serveur HTTP " n'est pas considéré comme une application de type web. Le fonctionnement technique des applications web repose avant tout sur deux notions fortes :
De plus, on ne discutera pas ici des avantages et des inconvénients inhérents au choix de ce type d'architecture. On précise cependant que ces deux points techniques ont d'une part contribué au succès des applications web, et d'autre part, permis aux serveurs d'applications de s'imposer comme l'interlocuteur indispensable à toutes architectures ou applications web. |
|
Quel est le rôle exact du
serveur d'applications ? |
|
Le serveur d'applications trouve sa place au sein des
architectures web dynamiques. En dehors des architectures à pages statiques ne
nécessitant l'utilisation que d'un serveur web, et des scripts CGI, toutes
les autres architectures, transactionnelles ou non, des plus simples aux plus
complexes, requièrent la présence d'un serveur d'applications. Son rôle
est de fournir la dynamicité nécessaire aux applications. Sa place
exacte se trouve entre le serveur HTTP qui reste le garant du dialogue
standardisé avec le client, et entre le reste de l'architecture (partie
appelée parfois le back-office) qui peut être plus ou moins riche et complexe.
Dans la grande majorité des cas, le back-office des architectures se compose
de SGBD, d'ERP (Progiciel de Gestion Intégré), de middleware d'accès divers,
d'EAI (Enterprise Application Integration) ou de tout système existant tels
que les mainframes et les serveurs centraux. Notons, que certains serveurs
d'applications peuvent aussi fournir, tout ou partie des éléments du
back-office.
Le rôle technique d'un serveur web pur (serveur HTTP) est de délivrer au client web (client HTTP) les réponses aux requêtes émises par ce dernier, en lui fournissant des éléments statiques (pages HTML, images…). En revanche, dès que le contenu à délivrer est dynamique (c'est-à-dire élaboré à la demande), c'est le serveur d'applications qui prend le relais en laissant le serveur HTTP devenir un simple intermédiaire entre lui et le navigateur. Le dialogue qui s'instaure alors entre le navigateur et le serveur d'applications est bien toujours un dialogue régi par le protocole HTTP. La principale fonctionnalité apportée par le protocole HTTP réside dans sa simplicité. Ce principe repose sur le paradigme de requête-réponse. Le concept d'aller-retour lié à ces requêtes-réponses réglemente complètement l'utilisation d'une application web. En formalisant ce mécanisme au travers d'une application web de type HTML, on peut aller plus loin, en disant que le client émet dans tous les cas une demande de page web, que son contenu soit statique ou dynamique. Du point de vue de l'utilisateur, la notion de page est donc fondamentale et elle gouverne purement et simplement toute perception et toute idée que l'utilisateur se fait de l'application qu'il manipule. A ce titre, on note que l'un des meilleurs indicateurs d'activité d'une application web se fonde sur la notion de " pages vues " avant de se baser sur la notion de transaction par exemple. Si l'utilisateur perçoit bien des pages web, c'est en réalité tout
simplement parce qu'il les reçoit. Que la page soit statique ou qu'elle soit
construite dynamiquement par le serveur, celle-ci sort du serveur et arrive
sur le poste client de la même manière qu'une page statique, pouvant ainsi
donner l'impression que toute page demandée est nativement statique. Ce
mécanisme est important car il impose que toute architecture web, aussi
complexe soit elle, doit avant tout, et in fine, construire ces pages avant
de les envoyer aux utilisateurs. C'est là un des rôles fondamentaux du
serveur d'applications. En d'autres termes, même si du côté back-office la
notion de page disparaît parfois au profit d'une gestion de contenu, c'est
bien le serveur d'applications qui doit gérer l'élaboration de ces pages à
renvoyer au navigateur. En synthétisant, la cinématique d'utilisation d'une application web s'appuie toujours sur une succession de pages sollicitées par le navigateur et renvoyées par le serveur. Quelles que soient les actions effectuées par l'utilisateur au sein de son navigateur, celles-ci conduisent à la demande d'une page pour finalement aboutir à son obtention, et cela de manière répétée. |
