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.
|
[