Le paradoxe
du marché des serveurs d'applications
Par le JDNet
Solutions (Benchmark Group)
URL : http://www.journaldunet.com/solutions/0207/0207xx_appserv.shtml
Mardi 23 juillet 2002
Demandez donc à un analyste de vous
donner sa vision de l'architecture des systèmes d'information
tournés vers l'e-business. Il y figurera très certainement,
en position centrale, un serveur d'application (web), assurant le
lien entre les sources de données (bases, services applicatifs),
en "amont", et les clients (navigateurs et autres clients
légers) en "aval". Ce serveur d'application manipulera,
selon les cas, des composants applicatifs objets (COM, CORBA, EJB),
mais également des messages XML-SOAP s'il comporte une couche
de support des "Web Services". Mais quel est son rôle
exact, par rapport à un outil d'EAI, un langage de programmation
ou un serveur web ? Comment le définir, et comment les outils
du marché se positionnent-ils par rapport à une définition
générale ? Pourquoi, enfin, lui accorde-t-on cette place
prépondérante qui le fait apparaître, finalement,
comme la véritable grande révolution technologique de
ces dernières années, révolution comparable à
ce qu'à pu être l'émergence de la logique client-serveur
lorsque les mainframes constituaient l'essentiel de l'informatique
d'entreprise ?
Construction d'application
Définir le serveur d'application comme un outil de construction
d'applications centralisé permet de circonscrire assez précisément
son "périmètre de compétences". En
effet, là où un middleware (orienté message,
ou courtier d'intégration manipulant des composants) fait communiquer
des applications entre elles, le serveur d'application bâtit
(comme son nom l'indique), des applications nouvelles en agrégeant
et combinant des composants déjà intéropérables
grâce à l'EAI. Cette vision des choses fait comprendre
pourquoi cette approche est véritablement novatrice, en tirant
parti des réseaux sur lesquels sont distribués les composants
(qui peuvent être considérés comme des services)
ou les bases de données, pour le développement d'applications
spécifiques dans une gamme très étendue.
Une large gamme de fonctionnalités...
Pourtant,
plusieurs conceptions très différentes des serveurs
d'applications ressortent du marché. Stricto sensu,
un serveur web assorti d'un langage de script comme PHP, Perl (comportant
en standard ou via des librairies additionnelles des moyens
d'accès aux bases de données, aux services Web via
SOAP, etc.) est un serveur d'application. Mais les produits des éditeurs
leaders de ce marché qui peut encore être considéré
comme émergent (d'après l'étude Benchmark Group
"Intranet des grandes entreprises : contenus, pilotage, solutions"
sortie en mai 2002, seul un grand compte de l'échantillon sur
deux dispose d'un serveur d'application, et 30% n'ont pas prévu
d'en mettre en place) sont beaucoup plus sophistiqués, incluant
connecteurs applicatifs, encapsulation ou support direct de divers
modèles de composants objets métier, moteurs de composants
comme les servlets par exemple, technologie de caches, répartition
de charge, environnement de développement, outils de gestion
de contenu, et pourquoi pas gestion du workflow métier, sauvegarde
par réplication, déploiement d'application "à
chaud" (sans rédémarrer le serveur)... La liste
des fonctionnalités possibles est très longue.
Troisième conception du serveur d'application: celle de Microsoft,
pour lequel c'est avant tout le système d'exploitation qui
réunit l'appareillage nécessaire pour réaliser
les différentes tâches que nous venons de décrire.
... définissant
pour une large part le marché
Le
marché des serveurs d'application se divise entre les outils
intégrés à des plates-formes plus larges (IBM
Websphere, Oracle 9i, ou dans une certaine mesure compte-tenu de ce
qui précède, Microsoft.Net) et des outils émanant
d'éditeurs dont le serveur d'application est le coeur de métier.
Le nombre de ces derniers risque fort de se réduire dans un
mouvement de concentration d'ailleurs déjà amorcé
(ainsi de SilverStream, racheté par Novell, ou de HP, abandonnant
son offre middleware peu de temps après avoir racheté
BlueStone).
Quant aux grands acteurs, l'alternative J2EE / .NET (qui dépasse
d'ailleurs la simple question du serveur d'application) domine les
débats, et sera certainement le facteur-clé d'évolution
du marché dans les mois qui viennent. L'autre point d'importance
est le développement des serveurs d'application libres comme
alternatives aux produits commerciaux destinés avant tout aux
grandes entreprises. Les logiciels libres tirent naturellement parti
des standards ouverts (spécifications J2EE, XML) que l'on retrouve
dans les principaux serveurs d'applications. Leur attrait semble réel,
car des acteurs comme IBM ou Macromedia incorporent du code opensource
dans leurs produits (Websphere, JRun).
Un
choix restreint malgré l'ouverture ?
Dans ce contexte, on peut voir un paradoxe dans la constatation de
la "démocratisation" - via les logiciels libres
en particulier - de ce choix technologique majeur (pour les entreprises
déployant des applications web en Intranet, notamment) qui
repose en partie sur l'idée de construire à partir de
sources hétérogènes, et la concentration du marché
correspondant autour d'éditeurs qui mettent en avant le "tout
intégré". Un peu dommage, car le saut technologique
induit par le serveur d'application risque fort de continuer à
ne pas être appréhendé à sa juste valeur,
dans le sens où sa spécificité est de moins en
moins mise en avant, et sa fonction "tirée" vers
l'intégration et la gestion de processus métier. En
pratique, si pour les grandes entreprises cela ne fera pas de différence,
les entreprises de taille plus réduite risqueront fort de passer
à côté, non pas faute d'offre adaptée -
aussi bien libre que commerciale -, mais d'un certain "brouillage
des cartes" entre middleware d'intégration - perçu
comme lourd et coûteux - et serveur d'application proprement
dit.
[Jérôme Morlon, JDNet]
Pour tout problème de consultation, écrivez au Webmaster
Copyrights
et reproductions . Données
personnelles
Copyright 2006 Benchmark Group - 69-71 avenue Pierre Grenier
92517 Boulogne Billancourt Cedex, FRANCE
|
|
|