|
Lorsqu’un commercial d’un fournisseur ou d’une
SSII présente une offre d’EAI à des dirigeants ou à des directeurs informatiques, il
appuie souvent son argumentation, j’en suis témoin, par la projection du
transparent suivant :
« Avant », c’est le « plat de spaghetti » :
chaque application doit gérer sa connexion à chacune des autres. « Après »
(avec l’EAI), chaque application est connectée au « bus » et à
lui seul.
Le commercial plaide la cause
de l’EAI avec la conviction du missionnaire en pleine évangélisation.
« Qui, s’exclame-t-il, préfère le plat de spaghetti ? »
« Pas moi en tout cas », répondent en chœur le dirigeant et le
DSI.
Chacun bien sûr préfère que
le système d’information soit en ordre. Mais par quel miracle ce « bus »
si simple arrive-t-il à remplacer le « plat de spaghetti »
d’autrefois ?
S’il y parvient, c’est
parce qu’il n’est pas simple du tout. D’abord il ne s’agit pas vraiment
d’un « bus », support passif de transmission, mais d’un routeur
qui assure activement des fonctions de commutation et d’autres encore. Les
soi-disant « bus » EAI assurent, entre autres fonctions, celles définies
par la norme « Corba » (« Common Object Request Broker
Architecture ») :
- routage des messages : le « bus » interprète l’étiquette
du message pour identifier l’adresse vers laquelle il doit l’orienter ;
- transcodage des données : si deux applications recourent à des
codages différents, le « bus » assure la traduction entre les codes ;
- gestion des flux : en puisant dans une gamme de synchronismes qui s’étend du temps
réel transactionnel jusqu’au traitement « batch », le
« bus » gère les délais de mise à jour selon les besoins
des diverses applications ; il comporte des files d’attente (« buffers ») ;
il traite la concurrence (lorsque deux utilisateurs veulent
modifier en même temps une même donnée) et la persistance (lorsqu’il
est nécessaire de conserver en mémoire la valeur d’une donnée qui vient
d’être modifiée).
Les fonctions offertes par le
bus soulagent d’autant les applications : pour ne prendre qu’un exemple, il
est plus simple pour une application d’envoyer les messages au « bus »
qui en assurera le routage que d’inclure elle-même un sous-programme de
communication. D’ailleurs on peut connecter au bus des « services »
(applications spécialisées dans la fourniture d’un service aux autres
applications : sécurité,
supervision, métrologie etc.) Il en résulte une économie d’échelle par
concentration du code naguère dispersé dans les applications.
On demande aussi parfois au
« bus » de présenter le système d’information sur l’interface
homme-machine de telle sorte que l’utilisateur dispose « sans couture »
des « vues » qui lui sont nécessaires (données, espaces de saisie,
traitements).
Le « bus » EAI est
donc un « middleware » très riche. Sa mise en oeuvre suppose que
les fonctions ci-dessus soient définies et paramétrées. L’utilité de l’EAI
est réelle – mon propos n’est pas de le dénigrer – mais sa présentation
par les commerciaux est d’une simplicité trompeuse.
Demandez d’ailleurs au
commercial qui cherche à vous vendre un EAI comment son produit gère les
routages, transcodages, synchronismes, concurrence, persistance etc. Le plus
souvent il n’en saura rien, le pauvre : ses seules armes sont le
transparent ci-dessus et son savoir-faire de vendeur professionnel.
Une fois le contrat signé
arriveront les spécialistes. Pour définir le « bus » ils poseront
une liste de questions qui dissipera aussitôt la première image, fallacieuse,
de simplicité.
|
