|
Introduction J2EE - Applications d'entreprise
2.3.Implémentation de J2EE :
les serveurs d’application
Il est avant tout indispensable de
définir clairement ce qu'est un serveur d'application. En
effet, une confusion règne dans les esprits quant à la
notion de serveur d'application. Cette confusion a été
introduite en grande partie par les éditeurs de serveurs
d'application J2EE (Java2 Entreprise Edition) afin de s'approprier ce
marché. La notion de serveur d'application a en effet été
mélangée avec celle de serveur d'objet qui n'a
absolument rien à voir.
2.3.1.Qu’est ce qu’un
serveur d’application ?
Le serveur d'application est
l'environnement d'exécution des applications côté
serveur. Il prend en charge l'ensemble des fonctionnalités qui
permettent à N clients d'utiliser une même application :
- Gestion de la session
utilisateur : N clients utilisant une même instance
d'application sur le serveur, il est nécessaire que le
serveur d'application puisse conserver des contextes propres à
chaque utilisateur (par exemple, un panier de commandes). La plupart
des serveurs d'application génèrent un identifiant
unique pour chaque nouveau client et transmettent cet identifiant
lors de chaque échange HTTP par URL longs, variables cachées
ou cookies.
- Gestion des montées en
charge et reprise sur incident : Afin de gérer toujours plus
d'utilisateurs, le serveur d'application doit pouvoir se déployer
sur plusieurs machines et éventuellement offrir des
possibilités de reprise sur incident (même si dans la
grande majorité des cas, on se contente d'une gestion des
montées en charge au niveau réseau - boîtier de
répartition, DNS round-robin, reverse proxy ...).
- Ouverture sur de multiples
sources de données : C'est le serveur d'application qui rend
accessible les données des applications du système
d'information. Il doit donc pouvoir accéder à de
nombreuses sources de données. On s'attend également à
ce qu'il fournisse des mécanismes performants comme le
pooling de connexion base de données.
- ...
Le serveur d'application est donc
indispensable si l'on souhaite éviter de re-développer
l'ensemble de ces fonctionnalités (cas des GGI). Les moteurs
JSP/Servlets, Microsoft ASP, Cold Fusion, PHP ... sont à ce
titre des serveurs d'application (même si il sont intégrés
au ServeurWeb PHP/ASP).
2.3.2.Qu’est ce qu’un
serveur d’objet ?
Pour aborder la notion de serveur
d'objets, il faut comprendre qu'il existe deux méthodes pour
accéder aux données et aux traitements.
- La première consiste à
accéder directement aux sources de données. Cette
méthode de programmation n'empêche en aucun cas de
structurer ses développements.
- La deuxième méthode
consiste à s'appuyer sur des objets métier (client,
fournisseur ...) afin de masquer la complexité d'accès
aux données. Un objet AssuréSocial possédera
par exemple une méthode débit() et une méthode
crédit () qui à chaque appel iront modifier les
données dans une ERP (Entreprise Resource Planning), un
système de CRM (Customer Relation Ship Managment) ou une base
de données.
- Requête du client
- Le serveur web passe la requête
au serveur d’application
- Le serveur d’application
traite la requête par des appels au serveur d’objets
- Le serveur d’objet traite
les données avec les bases de données (en tout genre)
- Le serveur d’objet
retourne les objets au serveur d’application
- Le serveur d’application
renvoie le résultat au serveur web
- Le serveur web fait suivre le
résultat au client
Pour gérer ces objets, un
environnement d'exploitation est nécessaire : le serveur
d'objets. Ce serveur d'objets va devoir fournir des services tout à
fait différents de ceux des serveurs d'application :
- Gestion de la persistance des
objets,
- Gestion des transactions objets
métier
- Gestion des montées en
charge : ici les mécanismes n'ont rien à voir avec
ceux mis en oeuvre pour un serveur d'application. Il faut pouvoir
assurer la transparence de localisation, l'instanciation, ... des
objets métier ...
Bref, on le voit, on a à faire
à des techniques très différentes. Les
principaux serveurs d'objets à ce jour sont les serveurs EJB
(Enterprise Java Beans), Corba. Ils ne sont nécessaires à
ces développements que si l'on souhaite utiliser pleinement la
logique d'objets métier.
Il est donc important de ne pas
mélanger ces notions afin d'éviter de se faire
« prendre » comme 80% des acheteurs de serveurs
J2EE (incluant serveur d'application et serveur d'objets) qui
n'utilisent que le moteur de JSP/Servlets dont les coûts sont
beaucoup plus limités que l'ensemble J2EE (incluant le serveur
d'objets EJB).
Sur le terrain, on rencontre beaucoup
plus de développements sur des serveurs d'application seuls
que d'applications utilisant des serveurs d'objets. En fait, le
marché des serveurs d'application s'est fortement structuré
depuis une ou deux années. De plusieurs dizaines de
technologies il y a peu, seules trois technologies émergent
aujourd'hui : l'offre Java, l'offre Microsoft et l'offre PHP. Hormis
cas particulier, nous recommandons de ne pas sortir de ces trois
choix.
Les points clés d'une
architecture sont les capacités transactionnelles du serveur
d'application à délivrer des pages et à intégrer
une montée en charge… L'ergonomie au sens large est un
autre point clé. Les choix de design doivent prendre en compte
les contraintes du Web (taille des images, ...).
Le marché offre trois familles
de solutions de développement pour les serveurs d'application.
- Les solutions de scripting
peuvent être simples et productives mais plutôt
orientées vers les sites jetables, de type évènementiel.
Un site en ASP, PHP 3 ou ColdFusion peut être développé
très rapidement ; par contre, sa maintenance est compliquée
voire quasi-impossible.
- Les solutions orientées
objets techniques permettent de factoriser le code sans rentrer dans
la complexité des objets métier. Il est important
d'imposer des règles de développement précises
à ses équipes et prestataires. Les développements
JSP/Servlets/JavaBeans, PHP4/5, ASP/DCOM (et ASP.Net/DCOM)
permettent de tels développements.
- Les solutions orientées
métier sont plus complexes et plus coûteuses à
mettre en oeuvre. Elles nécessitent la mise en place de
serveur d'objets. On retrouve principalement sur ce marché
les serveurs d'EJB libres et propriétaires.
Pour ces trois familles de solutions,
des produits Open Source existent et sont de plus en plus adoptés
dans les administrations et entreprises (TomCat, JBoss, JonAS…).
|
|
 |
