|
Le standard XML a intéressé
toute la communauté informatique dès le
début. Le problème, c'est que pratiquement
personne ne savait à quoi ce nouveau standard
allait pouvoir servir et comment on pouvait en tirer
profit. Évidemment, la première cible
désignée fut le remplacement du HTML.
Mais l'idée que
le XML puisse supplanter le HTML était un faux
débat. Certes, HTML présente des défauts
mais imaginer qu'on peut ainsi remplacer un standard
établi et bien répandu par une norme naissante
dénote une méconnaissance certaine des
réalités du terrain...
Une fois que le microcosme
a compris que le XML ne serait pas le remplaçant
du HTML, il a fallu trouver une autre " grande
ambition " pour le nouveau standard… et très
vite, XML a été positionné comme
le sauveur de l'EDI.
Le XML, avec ses qualités de métalangage,
présentait tous les critères requis pour
permettre la définition de dialectes sectoriels
facilitant les échanges interentreprises. Et
de fait, pendant les années 1998 et 1999 les
initiatives en ce sens se sont multipliées, à
tel point qu'on a pu dénombrer jusqu'à
plus d'une centaine de travaux de ce type !
C'est
alors qu'a commencé à apparaitre et à
se formaliser la notion de web services. Et là,
on a vu un phénomène inédit en
informatique : l'unanimité des acteurs !
Mais, bien sûr, cette unanimité n'est que
de surface et elle s'exprime surtout sur le niveau basique
des Web services (SOAP et WSDL). Dès qu'on s'intéresse
aux niveaux supérieurs de la normalisation des
Web services (sécurité, orchestration,
etc.), la bataille fait de nouveau rage !
Il semble donc bien que le XML ait enfin trouvé
sa voie avec les Web services en tant que mécanisme
de base d'une nouvelle classe de middlewares non-intrusifs
et adaptés à l'Internet.
Pourtant le niveau
de standardisation actuel des Web services n'est pas
encore suffisant pour permettre la mise en place de
traitements fonctionnels avec un déroulement
logique qui suppose forcément un routage, une
orchestration et même, éventuellement,
une gestion de l'intégrité transactionnelle...
Il est donc douteux qu'on obtienne des résultats
concrets en voulant à tout prix hisser les Web
services au même niveau de détails que
CORBA. Il ne faudrait pas oublier que c'est sa légèreté
qui a été le moteur du succès des
web services et que c'est précisemment la complexité
qui a tué CORBA...
Pourtant, une nouvelle
classe de middlewares est en train d'apparaitre: intégrant
les Web services en tant que mécanisme, ils offrent
un potentiel inédit aux applications d'entreprises
en terme de distribution et d'ouverture. Ces nouvelles
solutions se déclinent en deux catégories
distinctent : les bus de services et les bases de données
virtuelles.
Bus de services
En mixant les avantages des Web services, des connecteurs
Java (JCA), des middlewares messages (comme JMS) et
en combinant le tout dans une infrastructure d'intégration
et de gestion, on obtient un nouveau type de solution
d'intégration appelée ESB pour Enterprise
Services Bus. Cette nouvelle offre est évidemment
portée par une nouvelle génération
de start-up comme Cape Clear, Sonic software, Kenemea
et SpiritSoft (mais on retrouve aussi des éditeurs
connus comme Iona et Software AG dans ce nouveau wagon).
Les partisants de cette
nouvelle approche insistent sur les avantages en terme
de montée en charge et de tolérance aux
pannes d'une structure organisée en bus (les
modules sont présents sur chaque serveurs du
systèmes d'information et fonctionnent de manière
décentralisée) par opposition au principe
du hub qui caractérise les solutions des acteurs
habituels de l'EAI. Les ESB nous permettent également
de redécouvrir les vertus de l'invocation asynchrone.
Pour établir un dialogue entre des applications,
les avantages du fonctionnement asynchrone sont en effet
ceux du courrier électronique par rapport au
téléphone.
Les middlewares orientés
messages sont parmis nous depuis quelques temps déjà
(comme l'offre MQseries d'IBM disponible depuis au moins
quinze ans) mais connaissent un regain d'intérêt
depuis que l'infrastructure Java intégre son
propre MOM avec JMS (Java Messages Services) et que
les ESB les utilisent comme mécanismes de transport.
D'autres acteurs bien établis comme IBM ont déjà
annoncé leurs intentions de se lancer eux aussi
dans l'offre de solutions ESB et le Gartner Group présente
l'ESB comme une vague de fond.
Les ESB sont intéressants
pour faciliter les opérations d'EAI mais le renouveau
apporté par les middlewares XML ne se limite
pas à cela, il y a mieux...
Bases de données virtuelles
Un vieux rêve hante l'industrie informatique
depuis des décenies : comment proposer un accès
aux données quels que soient les formats et emplacements
et faire en sorte que la vue de cet accès soit
unifiée ?
Les bases de données distribuées ont été
la première réponse à cette aspiration
mais elles ont été abandonnées
à peine expérimentées. La faiblesse
de performance des requêtes distribuées
était un problème récurrent par
le passé. Des progrès récents dans
tous les domaines (SGBDR, réseau, etc.) ont effacé
ou au moins amoindri ce handicap à tel point
qu'on parle de nouveau de l'approche distribuée
qui est cette fois appelée "bases de données
fédérées" ou même "base
de données virtuelle" (et même aussi
EII pour Enterprise Informations Integration ).
Le champ d'actions et le
potentiel de ce "décisionnel temps réel"
est illustré par l'exemple suivant : un utilisateur
veut vérifier la valeur d'un actif ou d'un portefeuille
d'actifs. La base de données virtuelle va aller
puiser dans la base de données toutes les données
relatives à chacun des actifs, va ensuite faire
appel à un ou plusieurs services web extérieurs
qui vont en donner la valeur à l'instant t (son
cours de bourse s'il s'agit d'une valeur mobilière
ou sa cote s'il s'agit d'un autre type de bien) et enfin
calculer la valeur de l'ensemble comme si toutes les
données étaient disponibles en local.
C'est IBM qui a initié
ce mouvement avec le projet Xperanto qui reprenait,
entre autres, le projet Open Source Xquery. Un des grands
avantages de l'approche fédérée
: on peut attaquer des sources de données "non-database"
comme les documents (feuilles excel), les bases d'emails,
en plus des traditionnelles bases de données
relationnelles.
L'autre grand avantage de l'approche est que les données
restent dans leurs formats d'origines et à leurs
emplacement d'origines, là où elles sont
le mieux.
On évite aussi les opérations d'extraction-transformation-chargement
(assurées aujourd'hui par les outils d'ETL) qui
sont lentes, périodiques (et donc espacées
dans le temps) et propices aux erreurs.
De plus, une part
croissante d'informations est désormais stockée
dans des documents au format XML (ne serait-ce que les
documents MS Office !) ou dans des sites Web où
le format XML prend progressivement sa part. La capacité
à interroger des données dans ce format
va donc devenir incontournable.
On est donc face à
un mouvement qui, plutôt que de seulement s'attaquer
à la pratique du datawarehouse (qui, d'ailleurs,
devrait perdurer), va renouveller le domaine du décisionnel.
Au lieu d'être cantonné au domaine de l'analyse
sur des données "froides", le décisionnel
va pouvoir se développer et s'exprimer sur les
données "chaudes", les données
opérationnelles. Du coup, les applications dites
décisionnelles vont pouvoir elles aussi passer
à un statut directement opérationnel et
sortir du cadre classique requête/rapport.
On le voit, le XML commence
enfin à donner des résultats concrets
et utiles. Mais, plutôt que de le voir comme une
solution universelle et utopique, il vaudrait mieux
reconnaitre sa vraie nature : un mécanisme simple
aidant à l'échange entre machines, point.
|
