|
|
Les Serveurs
d’applications |
Présentation RIO Janvier 2002 |
|||
|
3.
Positionnements |
Page précédente Sommaire Page suivante
3.1 Quel serveur d'applications pour quel besoin ?
|
Trois catégories de serveurs d'applications Type Scripting : Type Objets : Orientés Objets : |
|
Dans le domaine des architectures web, aujourd'hui de nombreux serveurs d'applications se disputent le marché et, à écouter les éditeurs, chaque offre répond aux besoins du client. Dès lors, toute la difficulté est de les classer et de déterminer leur champ de fonctionnalités. Une connaissance approfondie des produits permet de regrouper l'ensemble des serveurs d'applications sous des catégories différentes. En effet, trois types de solutions sont dégagés : les serveurs d'applications de scripting, les serveurs d'applications objet et les serveurs d'applications orientés objet. L'usage de scripts offre des caractéristiques communes aux serveurs d'applications de scripting, quel que soit le langage choisi au final. Tout d'abord, la simplicité est une des qualités premières de ce type d'outil. Effectivement, du côté des équipes de développement, les langages de scripting sont simples à appréhender et à mettre en œuvre. Même si une distinction est toujours possible entre les différentes technologies de scripting, celles offrant une syntaxe proche du HTML et les autres, d'une manière générale, les serveurs d'applications de scripting répondent aux critères de simplicité et de rapidité. Un autre élément fort qui leur est propre concerne leur tarification d'entrée de gamme. Pour synthétiser, les caractéristiques fortes d'un serveur d'applications de scripting sont la simplicité, la rapidité et un prix abordable pour tous. L'élément différenciateur se situe au niveau de l'ouverture du moteur vers les technologies orientées objet et vers l'existant de l'entreprise. A ce niveau, c'est donc l'évolutivité qui entrera en compte dans le choix initial d'un serveur d'applications de scripting. Les serveurs d'applications objet font partie de la seconde catégorie. De part la nature même du langage, ces outils sont difficiles à appréhender. Ainsi, la puissance du modèle objet avec tous ses avantages impose des compétences expérimentées dans le domaine et du temps en phase de conception. En effet, tout projet web démarre par un long travail de modélisation des composants avant d'écrire le premier morceau de code. Ce travail complexe apporte cependant de nombreux avantages sur le long terme. Une application correctement modélisée permet de séparer l'application en plusieurs modules spécifiques aux différentes couches de l'application. Cette approche modulaire n'impose pas, lors d'un changement, la modification du code en plusieurs points, seul le composant concerné étant à corriger. De plus, cela facilite la réutilisation des composants en développement et en déploiement. Les serveurs d'applications objet sont les mieux placés pour tirer parti des fonctionnalités de répartition de charges et de reprise sur incident dans un contexte multi-serveurs. Incontestablement, la distribution des objets assure davantage de fiabilité et de disponibilité à l'application. En résumé, les inconvénients principaux d'un serveur d'applications objet sont le temps important de modélisation des objets et la complexité du langage en raison des concepts délicats à assimiler. Du côté des points positifs, on trouve la réutilisation des composants et les possibilités de répartition modulaire. Ici, le respect des standards est l'élément différenciateur technique garantissant la réutilisation des composants à partir d'autres applications. Les serveurs d'applications de la troisième catégorie, ceux orientés objet, se positionnent à cheval entre les deux autres catégories. Plus précisément, ils utilisent des langages objet pour faire du scripting. C'est le cas par exemple des applications réalisées en JSP et servlets. Elles sont codées en Java, mais ne mettent pas à profit les capacités objet du langage. Cette catégorie offre pour seul avantage la possibilité aux équipes de se former doucement à Java. C'est une étape intermédiaire permettant de faire le pas entre le scripting et l'objet, offrant une architecture évolutive pour se diriger vers des structures nécessitant une orientation objet plus forte. L'autre type de produit qu'il est possible de placer dans cette catégorie comprend les serveurs d'applications de type scripting qui proposent également le langage Java comme solution de développement. Ne respectant pas les standards J2EE, et conçus pour répondre à des problématiques relationnelles, ceux-ci permettent de faire le pas vers le monde de l'objet mais restent confinés à des contextes relationnels.
|
|
Des besoins différents |
|
Toute application web est étroitement liée au public à atteindre. Un site internet s'adresse à l'ensemble des internautes de la planète tandis qu'un site intranet est destiné à un public ciblé, habituellement les collaborateurs de l'entreprise. Entre les deux, l'application extranet pourra s'ouvrir à des partenaires de l'entreprise. D'une manière générale, les projets destinés à être visibles sur l'un ou l'autre des réseaux sont de natures différentes et présentent des caractéristiques distinctes. Par exemple, un site internet peut potentiellement être soumis à des problèmes de montées en charge très importantes. Si pour un site statique ce point ne présente pas d'inconvénient particulier, il en va tout autrement dans un contexte transactionnel où le serveur d'applications doit offrir les solutions pour absorber de la meilleure des façons la charge. Autre point important, l'aspect sécurité va bien évidemment prendre de l'importance à partir du moment où chacun pourra, depuis son navigateur, accéder potentiellement à une application accessible à tous. Les problèmes d'accès personnalisé, de paiement en ligne ou bien de sécurisation des informations seront primordiaux dans un tel contexte. Toujours dans la même situation, une " dotcom " qui souhaite vendre un produit en ligne aura une contrainte plus forte que toutes les autres : le temps. Chaque jour supplémentaire passé à appréhender l'environnement, à développer le site ou encore à déployer l'application est un jour de perdu pour la jeune société. Ainsi, l'objectif prioritaire de ce type de société est de trouver l'environnement qui pourra bien entendu répondre aux besoins minimaux requis, mais surtout dans les plus brefs délais. A l'inverse, un contexte intranet présente d'autres caractéristiques fortes, telle l'intégration de l'existant. Ce point, généralement inconnu des dotcoms qui partent de zéro, constitue un handicap majeur pour le portage des applications transactionnelles vers le Web. Le premier aspect concerne bien entendu l'accessibilité aux informations et aux systèmes existants, et dans cette optique le serveur d'applications se doit d'offrir les passerelles nécessaires. Mais assez rapidement, la centralisation des applications portées sur le Web va pousser la réutilisation de composants serveur, notamment objet. C'est à ce moment que vont apparaître des écueils majeurs telles que la cohérence, l'intégrité et la persistance des données. Dans une telle situation, le serveur d'applications aura pour fonctionnalité de base d'implémenter de manière complète et automatisée le mapping objet-relationnel. Comme on peut le constater, il existe de nombreux types de solution et les réponses que doivent fournir les serveurs d'applications sont donc tout autant diverses et variées. |
|
Le bon choix ! |
|
Pour cette raison, il est très difficile a priori de pouvoir choisir le bon serveur d'applications pour répondre de la manière la plus adaptée à son propre besoin. En plus des caractéristiques techniques, qui s'adressent à la fois à la partie développement et à la partie serveur, on retrouve des contextes politiques qui représentent bien souvent des critères discriminants. Par exemple, la pérennité ou le coût d'un produit peuvent évincer une offre d'un projet respectivement très ambitieux ou particulièrement petit. Si l'on reprend la catégorisation qui a été réalisée pour distinguer les serveurs d'applications, on peut de manière générale dire que : Les serveurs d'applications de type scripting conviendront parfaitement à des contextes de réalisation d'applications isolées. La forte productivité offerte dans un premier temps, ainsi que la simplicité de développement, prédestinent ces solutions à des problématiques fortes de time-to-market. On pourra ainsi trouver des sites web très peu transactionnels, ou encore des applications intranet isolées faisant référence de manière ponctuelle à l'existant de l'entreprise. Les serveurs d'applications orientés objet, de leur côté, sont bien souvent utilisés en étape intermédiaire pour le passage d'un mode scripting à un mode objet. Quand l'application de type scripting devient difficile à maintenir, non réutilisable et n'offre plus de garanties suffisantes en termes de portabilité et d'évolutivité, le passage le plus simple pour aborder l'objet consiste à retenir une solution orientée objet. Avec une modélisation toujours relationnelle, et donc une conception préservée, les équipes de développement pourront s'attaquer à l'objet, et notamment à Java, de manière progressive. Enfin, les serveurs d'objets seront tout particulièrement retenus dans des contextes de refonte de systèmes d'informations ou pour des sites web hautement transactionnels. Dans ces deux situations, seules les possibilités offertes par les serveurs d'applications objet en matière d'ouverture, de réutilisation ou encore de disponibilité des applications permettront de répondre aux attentes des équipes de développement, mais également des utilisateurs finaux. |
3.2 Du L3G au progiciel intégré
|
Réaliser des sites web
dynamiques |
|
Comme présenté lors 1erdu chapitre, différents types de produits permettent l'exécution d'applications transactionnelles web. Des solutions simplifiées telles que les L3G jusqu'aux progiciels intégrés, couvrent, sous des approches et à l'aide de moyens différents, ce besoin. Le rôle de ce chapitre est de présenter les avantages et inconvénients de chacune de ces gammes de produits, sachant que ceux-ci répondent plus ou moins bien à chacun des contextes d'entreprise. Les choix, souvent effectués à partir des discours marketing plus ou moins fallacieux des éditeurs, se révèlent donc parfois peu judicieux d'un point de vue stratégique, et aboutissent même dans certaines situations à un échec pur et simple du passage vers les technologies web. |
|
Les solutions rudimentaires : L3G, C, Perl, J2SE, servlets |
|
Les solutions d'entrée de gamme sont celles proposant les éléments de plus bas niveau technique permettant l'exécution d'applications transactionnelles web. Les L3G constituent bien entendu la base même de ces offres qui permettent, via du développement de masse, de réaliser ses propres applications. Initialement, le langage C était utilisé pour créer des CGI permettant de générer dynamiquement les pages HTML. Trop compliqué et peu adapté, l'utilisation de ce langage dans ce contexte a quasiment disparu. Le Perl, de son côté, profite toujours de son interface de qualité avec le serveur HTTP Apache, et de ses spécificités sur les traitements liés aux chaînes de caractères. Mais c'est surtout Java que l'on retrouve aujourd'hui, notamment dans les moteurs de servlets, pour répondre aux premiers besoins rencontrés. Les moteurs de servlets s'appuient sur les API de J2SE pour proposer de nombreuses briques techniques prêtes à l'emploi. Par exemple, la gestion de contexte et les méthodes associées sont partiellement fournies. Le moteur de servlets s'appuie également sur la JVM pour l'exécution du code. Un dérivé possible passe par l'utilisation de pages JSP, qui, in fine, sont transformées en servlets à l'exécution. Les JSP permettent de simplifier la tâche des développeurs qui peuvent insérer le code Java au sein de pages HTML. Enfin, certains éditeurs de serveurs d'applications fournissent des moteurs de servlets améliorés, comprenant par exemple des fonctionnalités de répartition de charges. Ces produits, mis en retrait par les éditeurs qui préconisent plutôt l'utilisation de solutions d'entreprise, suffisent pourtant parfois à répondre à la plupart des problématiques sans avoir l'obligation d'investir massivement vers une technologie objet. D'un point de vue général, ces solutions présentent comme principal atout le coût. Peu onéreuses car moins riches en termes d'API et de fonctionnalités proposées, elles offrent néanmoins certains avantages indéniables. Pour les équipes de développement qui ne connaissent par encore l'objet, elles permettent de simplifier la réalisation d'applications transactionnelles web. De plus, dans le cas de moteurs de servlets, les équipes peuvent goûter à Java et appréhender selon une logique relationnelle ce langage devenu aujourd'hui incontournable. Enfin, en terme de temps de réponse à l'exécution, les moteurs de servlets s'avèrent aujourd'hui particulièrement performants puisque les couches techniques et métier utilisées nativement sont réduites à leur forme minimale. Les points faibles restent majoritairement la faible productivité en terme de développement, les outils proposés à ce niveau se révélant la plupart du temps insuffisants. De plus, en terme de possibilités techniques, de nombreuses fonctionnalités sont à développer soi-même, souvent via du codage de bas niveau demandant une expertise très poussée. Enfin, en terme d'évolutivité de l'architecture, les solutions d'entrée de gamme n'offrent pas les éléments permettant de s'adapter facilement à tous types de contextes d'entreprise, ni à des problématiques de sites générant un trafic trop important. |
|
|
|
Les Solutions rudimentaires : |
|
|
|
Forces
Faiblesses
|
|
Les serveurs d'applications |
|
Les serveurs d'applications sont majoritairement issus de trois origines différentes. En premier lieu, on retrouve les environnements dérivés des outils client-serveur. A partir d'un atelier de développement, l'éditeur a alors proposé des extensions permettant de produire des applications fonctionnant selon le principe des architectures web. Pour pouvoir exécuter celles-ci, il a alors fallu adapter la partie serveur de traitements déjà présente dans l'architecture client-serveur, ou créer un véritable serveur d'applications de toutes pièces. Le second groupe de serveur d'applications provient d'éditeurs créés avec l'arrivée massive du Web. Ces sociétés ont alors développé en parallèle des environnements dédiés au développement et au déploiement d'applications transactionnelles web. On retrouve, majoritairement, les offres intégrées issues des start-up du Web. Enfin, la troisième catégorie de serveur d'applications comprend les
offres rudimentaires enrichies d'outils, de briques techniques et de
possibilités pour couvrir des besoins plus importants au niveau du
développement et de l'exécution des applications. D'un point de vue général, les serveurs d'applications comblent la majorité des lacunes des offres rudimentaires. Le principal atout des serveurs d'applications concerne donc un apport important en terme de productivité, grâce aux ateliers de développement proposés et l'enrichissement des API, ainsi qu'en terme d'évolutivité. A ce niveau, la capacité de faire de l'objet, bien souvent de manière standardisée, offre des avantages considérables pour la distribution, la répartition de charges, la réutilisabilité et la disponibilité des applications. |
|
|
|
Les Serveurs d’applications : |
|
|
|
Forces
Faiblesses
|
|
Les frameworks métier |
|
Les frameworks métier sont des packages proposés par les éditeurs pour répondre à des problématiques bien spécifiques. Appelés souvent " solutions " par les éditeurs pour se démarquer de la connotation technique du terme " serveur d'applications ", il faut bien se rendre compte qu'il ne s'agit généralement que d'un serveur d'applications doté de quelques API et/ou outils supplémentaires. Les briques fournies sont celles permettant de réaliser plus facilement certains types d'applications. Par exemple, une offre d'e-commerce fournira les frameworks de mise en place des catalogues de produits, des interfaces avec les solutions de paiement en ligne, de la personnalisation ou encore de la sécurisation des informations. L'ensemble de ces briques ou produits peut être développé ou récupéré via l'acquisition d'offres tierces, mais ceci peut se révéler coûteux et prendre un temps certain. En d'autres termes, ces produits packagés, qui correspondent à un serveur d'applications enrichi, se révèlent particulièrement utiles dans la mesure où les fonctionnalités proposées répondent parfaitement à la problématique rencontrée. Sinon, le coût d'acquisition n'est pas justifié. Quoi qu'il en soit, et quelles que soient la qualité et la richesse du framework, c'est toujours le serveur d'applications qui exécutera les traitements, et les notions de disponibilité, de performance et d'intégration avec l'existant seront toujours dépendantes de la qualité du serveur d'applications. |
|
|
|
POINTS FORTS & POINTS FAIBLES DES FRAMEWORKS METIER |
|
|
|
Faiblesses
|
|
Les progiciels intégrés |
|
De nouveaux acteurs apparaissent sur le marché des réalisations d'applications transactionnelles web. Il s'agit des acteurs ayant une offre progicielle pour la gestion de la relation client (GRC, ou CRM pour Customer Relationship Management). En ouvrant leur produit pour s'adresser au Web (outils d'IRM, pour Internet Relationship Management), ces éditeurs profitent d'un besoin accru en personnalisation, avec la notion de " one-to-one ". Ces offres, qui pour certaines d'entre elles proposent déjà des services de gestion de catalogues, sont particulièrement appropriées dans certains contextes. D'un point de vue général, les outils d'IRM concurrencent les solutions de serveur d'applications enrichies de framework métier. Les avantages des solutions d'IRM concernent le degré de complexité des réalisations, ne nécessitant pas de développement. Ainsi, par paramétrage d'un moteur, un responsable marketing par exemple peut définir ses règles de personnalisation et mettre à jour son application. Ce n'est pas toujours aussi simple, mais c'est possible dans certains cas. L'inconvénient majeur provient du manque de souplesse de ce type de solution qui n'offre pas la possibilité de retoucher les briques techniques et métier livrées avec le produit. Pour aller au-delà de ce qui est proposé nativement avec le produit, il faut redéfinir une partie du moteur, ce qui se traduit par un développement d'expertise particulièrement poussé. En d'autres termes, le progiciel répondra à l'attente de ses utilisateurs à partir du moment où celui-ci propose nativement les fonctionnalités souhaitées. Sinon, il vaudra mieux se retourner vers une offre plus ouverte. Par exemple, il est possible de faire l'analogie avec la réalisation de pages HTML. L'outil Word de Microsoft permet simplement, par la fonction " Enregistrer au format HTML ", de générer une page HTML à partir d'un document Word. Ceci est particulièrement simple et ne nécessite aucune connaissance de la syntaxe du HTML. Par contre, si la page générée ne correspond pas à ce qui était prévu (utilisation d'une version du HTML trop récente, mise en forme inadaptée...), il faudra utiliser un autre outil ou connaître parfaitement le HTML. A l'inverse, l'utilisation d'un produit comme Dreamweaver demandera une expertise plus poussée pour créer sa première page. Par contre, la retouche finale pour une version optimisée ne nécessitera pas une connaissance parfaite du HTML, et se fera à partir du même produit. |
|
|
|
POINTS FORTS & POINTS FAIBLES DES PROGICIELS D'IRM |
|
|
|
Faiblesses
|
|
Le serveur d'applications: la solution la plus utilisée |
|
D'un point de vue général, on constate que le serveur d'applications représente un élément quasiment incontournable pour les applications transactionnelles web. A la fois présent de manière simplifiée dans les solutions d'entrée de gamme, et véritable brique technique de chaque solution métier, le serveur d'applications se taille la part du lion. Il faut dire que l'ensemble des solutions de serveurs d'applications, ainsi que ses dérivés, permet de répondre aux spécificités de chacune des entreprises. D'un coût infime, voire nul, jusqu'à une solution beaucoup plus onéreuse mais proposant le maximum de briques techniques et métier, chacun peut trouver dans l'offre pléthorique des serveurs d'applications une solution adaptée à son besoin. |
|
|
|