 |
|
| |
 |
Michael Tartar
Manager des projets d'intégration
BearingPoint |
|
Michael Tartar
"Les premiers référentiels de Web Services apparaissent dans les grands comptes"
L'un des spécialistes français du XML fait le point sur les usages de grande envergure des Web Services, et sur la maturité des briques proposées, notamment en termes de standardisation.
25/08/2004 |
| |
|
|
JDN
Solutions. Les Web Services restent encore largement cantonnés à l'intégration "point à point" ?
Michael Tartar. C'est vrai. Mais dans certains cas, certes encore assez rares, ils peuvent être associés à une architecture multi-points. Il s'agit d'une couche intermédiaire de routage qui a pour but de masquer la localisation du service demandé. Elle permet de répondre à une requête d'un service émetteur en le mettant en lien avec un service cible sans pour autant que le premier sache où le second se situe au sein du système d'information. C'est le modèle de l'annuaire de services.
Un tel middleware combiné à des Web Services peut être un bon moyen de consolider des informations gérées par plusieurs briques du SI. J'ai récemment mis en uvre un projet basé sur une solution de ce type qui visait à agréger des données de ressources humaines (disponibilité, congès, etc.) en provenance de différents départements. L'idée était d'optimiser la gestion des personnes de façon transversale.
Ce middleware permet aussi de pallier aux difficultés réseau ?
Dans cette configuration, le middleware est également un bon moyen de gérer l'asynchronisme nécessaire aux contraintes d'un système décentralisé. Ce procédé assure l'orchestration des appels de services en fonction de la disponibilité de chaque infrastructure sous-jacente impliquée sachant par exemple que certains petits sites ne sont accessibles que par le biais de liaisons ADSL. D'autres éléments (comme la compression des flux) doivent éventuellement être mis en uvre au regard des contraintes techniques de transport.
Mais ce niveau intermédiaire n'est pas encore standardisé, à la différence des appels de services en tant que tels ?
Un langage XML a été proposé dans ce domaine : le BPEL. Il propose une manière de décrire des règles de routage de manière standardisée. Je constate néanmoins qu'il n'existe pas vraiment de convergence des plates-formes autour d'une implémentation commune de cette méthode.
Une fois une spécification élaborée, il faut toujours un peu de temps avant de comprendre comment en tirer partie. Dans le monde de l'informatique, ce décalage est équivalent à celui qui existe entre recherche fondamentale et recherche appliquée. Dans un premier temps, les manières d'implémenter sont généralement différentes, le rapprochement se fait ensuite. Au final, un compromis est trouvé. Ce qui donne naissance à une couche d'abstraction de plus haut niveau s'affranchissant des contingences d'exécution.
Dans le cas du BPEL, l'idée est d'aboutir à une couche de modélisation de règles métier portable d'un moteur de routage à un autre, à la manière d'une application Java entre serveurs d'applications J2EE.
Quelles sont les autres applications que vous observez ?
Une première étape vers un déploiement plus étendu peut passer par la mise en uvre de Web Services mutualisables. Dans le domaine du Web, cette démarche consisterait par exemple à concevoir un référentiel de services exploitables ensuite sur plusieurs sites, dépendant de départements différents avec des contraintes techniques propres. Cette approche peut être intéressante pour un grand groupe possédant des offres ou bouts d'offres et de services potentiellement exploitables pour plusieurs cibles marketing, surtout quand ses cibles sont gérées par le biais de plates-formes Web hétérogènes.
|
|
 Les Web Services nécessitent d'adopter une vision transverse" |
|
Comment gérer le changement dans le cadre d'un tel projet ?
Il est conseillé d'adopter dans un premier temps une approche départementale, puis dans un second temps transverse. La difficulté initiale consiste à modifier la vision des unités métier. D'une logique d'investissement vertical vers un marché particulier, elles doivent être capables d'adopter une vision transverse de l'entreprise, et comprendre l'intérêt qu'elles peuvent avoir à partager leurs ressources applicatives ou leurs contenus, sous forme de services, avec d'autres départements.
Pour réussir, un tel projet de déploiement implique l'existence d'une coordination transverse forte qui sait s'imposer et apporter un accompagnement. C'est le rôle de la direction générale. Le choix des premiers départements à migrer vers une telle architecture est une question de politique stratégique. |
| |
Propos recueillis par Antoine CROCHET-DAMAIS, JDN Solutions |
|
|
PARCOURS
|
|
|
| |
Michael Tartar, Diplômé de l'Epita (option Génie logiciel) et de l'IAE de Paris (CAAE-MBA option contrôle de gestion).
2001 Consultant chez Andersen, spécialiste des technologies XML.
2003 Manager des projets d'intégration chez BearingPoint.
|
|
|
|
|
|
|
Dossier 