www.ghellab-youssef.francejoomla.net

Les serveurs d'applications dans les architectures n-tiers

Où et comment se situent les technologies Open Source ?

Introduction

Un serveur d'application ne correspond pas nécessairement à la définition proposée par le marché ou par les éditeurs. Il est important de rappeler les rôles respectifs des serveurs Web, d'application et d'objets dans une architecture 3 tiers.

Du côté du premier tiers, le tiers présentation, le choix à privilégier est l'utilisation des standards XHTML/JavaScript/CSS/DOM. Le navigateur va interpréter ces standards et gérer l'interface avec l'utilisateur (gestion de l'évènementiel graphique, IHM ...). Une autre possibilité consiste à reproduire une logique client-serveur qui nécessite de recréer une connexion permanente (RMI, IIOP, DCOM, etc.) entre le poste client et le tiers traitement. Dans la plupart des cas, ce choix est une impasse pour des raisons d'ergonomie, de complexité de déploiement sur différents types de navigateur, de passage de pare-feux ...

Si l'on s'en tient au choix HTML (se souvenir que la simplicité l'emporte toujours), la première brique que va rencontrer la requête utilisateur est un serveur Web. Son rôle est indispensable mais relativement limité sur le plan applicatif. Grossièrement, il transmet au client lui ayant fait une demande HTTP via URL, les fichiers statiques présents sur le disque dur (pages HTML, images, fichiers CSS, ...). Dès que l'URL porte sur une page dynamique c'est à dire nécessitant un traitement, le serveur Web aiguille cette demande vers la brique serveur d'application. Une fois, le traitement effectué, le serveur d'application renvoie la page HTML (ou autre format) au serveur Web qui se charge de la router vers le bon destinataire. Le marché des serveurs Web est largement dominé par Apache, un serveur Web issu du logiciel libre. Si on ajoute aux parts de marché d'Apache celle de Microsoft IIS, on couvre plus de 90% du marché.

A quoi correspond réellement un serveur 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 afin de s'approprier à tort ce marché. La notion de serveur d'application a en effet été mélangée avec celle de serveur d'objet, qui aujourd'hui s'est transformé en JBOSS pour les architectures orientées services (SOA - Services Oriented Architecture) qui n'a absolument rien à voir

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 tels que le pooling de connexion base de données.

Figure 1. La brique serveur d'application

Le serveur d'application est donc indispensable si l'on souhaite éviter de re-développer l'ensemble de ces fonctionnalités. Les moteurs JSP/Servlets, Microsoft ASP.NET, Cold Fusion, PHP ... sont à ce titre des serveurs d'application.

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 de l'entreprise. 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. L'utilisation de framework de type MVC (Modèle-Vue-Contrôleur) est notamment tout à fait recommandée. 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ébitQ et une méthode crédit () qui à chaque appel iront modifier les données dans une ERP, un système de CRM et une base de données.

Figure 2. La brique serveur d'objets

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 : le service de persistance permet de " redescendre " de la mémoire des instances d'objets non " commités ". En effet, si l'instance Durant de AssuréSocial doit libérer l'espace mémoire alors qu'elle fait encore partie d'une transaction, il est indispensable de stocker son contexte en fichier, en base de données objet ou en base de données relationnelles (dans ce cas, un outil de mapping objet relationnel est à implémenter),

•       Gestion des transactions objets métier : une transaction impliquant plusieurs instances de AssuréSocial nécessite une propagation complexe de la transaction aux sources de données.

•       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, Microsoft DCOM. Ils ne sont nécessaires à ses 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).

Il est clair que sur le terrain, on rencontre beaucoup plus de développements serveur d'application seul que d'applications utilisant des serveurs d'objets. Il est donc intéressant de dresser un rapide état de l'art de ce marché. 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.

Le monde Java

Le monde Java couvre à la fois les besoins de serveur d'application (JSP/Servlets/JavaBeans) et de serveur d'objets (EJB). Même si l'on constate que dans la grande majorité des cas, seuls les JSP/Servlets/JavaBeans sont utilisés. Une des caractéristiques du marché Java est que près de 80 % des ventes sont détenues par BEA et IBM, les autres acteurs ayant des parts de marché limitées. Certains acteurs du J2EE cherchent leur salut dans la fourniture de solutions fonctionnelles telles que les portails d'entreprise, la gestion de contenu ...

Le monde des logiciels Open Source est de plus en plus présent avec Resin - un des serveurs d'application actuellement les plus rapides du marché - JServ, TomCat, Orion, Enhydra, etc. Une stratégie intéressante pour les entreprises et administrations consiste à développer ses applications de manière indépendante de tout serveur d'application (possible si des règles de développement sont clairement définies dès le départ). Ainsi garde-t'on la possibilité de déployer sur un serveur d'application libre ou sur un serveur d'application commercial en fonction de ses besoins (besoins de rôle d'éditeur, performances, coût ...).

Malgré les qualités de ce langage, on ne peut s'empêcher de penser que Java est aujourd'hui survendu par les éditeurs et les intégrateurs. En effet, Java reste une technologie complexe à adopter. Selon Gartner, former un développeur L4G à Java coûte 50 KEuros et prend 10 mois. Ceci peut être payant si la structure s'y prépare correctement. Quoiqu'il en soit ce choix doit être fait en toute indépendance. Attention notamment à ne pas " suivre les bons conseils" des intégrateurs qui voient en Java une source de revenus récurrente (difficulté de prise en main par les équipes internes, évolution permanente, orientation gros projets ...).

.NET ne renvoie pas à un produit précis, car il s'agit avant tout d'une initiative stratégique qui va être portée par l'ensemble des produits de la firme. Microsoft a amorcé l'année 2002 avec une nouvelle architecture remplaçant l'architecture DNA (Distributed Network Architecture). .Net se caractérise par :

•       Une orientation Web Services

•       Une volonté de simplifier les développements

•       Un framework de développement prometteur et favorisant la réutilisation

Le projet .NET a démarré le 13 février 2002. L'orientation Web Services est native. .NET est perçu comme une belle technologie mais qui manque pour le moment de maturité et d'utilisation à grande échelle. Les compétences sont rares, la migration depuis DNA sera lourde et les utilisateurs vont s'interroger sur des migrations vers Java ou PHP. Un point sensible est l'adhérence forte entre .Net et le reste des offres Microsoft (messagerie, Pocket PC ...). Très vite un développement .Net impose des choix Microsoft en dehors du spectre du choix initial. Le risque de verrouillage est à étudier et nécessite de bien contrôler les choix de développement faits lors des projets.

PHP est le parfait exemple d'une des lacunes des projets Open Source : le manque de marketing. PHP pâtit en effet parfois d'une image de langage pour sites personnels. Depuis PHP 3 et 4, cette image est totalement erronée. PHP est par exemple, la technologie utilisée sur 7 des 10 plus importants sites français. PHP est également utilisé par de nombreux sites fortement transactionnels parmi lesquels de nombreux sites de bourse en ligne. A ce jour, PHP est le module Apache le plus installé (près de 45%) loin devant le second Perl (moins de 15%). C'est indiscutablement la technologie serveur d'application la plus utilisée sur le Web et notamment en France.