Le bus de services, plaque tournante des échanges

Ludovic Arbelet, Frédéric Bordage et Philippe Davy

01 Informatique

le 12/03/2007 à 07h00

envoyer
par mail

imprimer
l'article

Une fois chaque application exposée sous la forme d'un ou plusieurs services, l'entreprise doit rationaliser et optimiser leurs échanges. Les raisons en sont multiples. Il s'agit de garantir et de différencier les temps de transport des messages via des accords sur le niveau des services (SLA ou Service Level Agreement), d'assurer la capacité à monter en charge de l'architecture, et de fournir une vision synthétique de l'activité du système d'information (BAM ou Business Activity Monitoring).

Ce rôle est souvent dévolu à un bus de services, ou ESB (Enterprise Service Bus). “ Mais ce peut être aussi un EAI ou un moniteur transactionnel ”, souligne Henry Peyret, analyste chez Forrester Research. Ce point de passage obligé, par lequel transitent les messages, constitue de plus en plus souvent la colonne vertébrale du système d'information.

“ L'ESB aide les services à coopérer, tout en restant faiblement couplés, précise Marc Boullier, directeur technique de Vistali. Le système reste ainsi adaptable et flexible. ” Quand l'usager d'un service l'appelle via un ESB, celui-ci garantit la possibilité de remplacer un service par un autre. Et ce, sans modifier la mise en œuvre de l'usager du service. “ Un ESB est aux services ce qu'un ORB est aux composants. C'est la colle qui rend les services interopérables, administrables, et maîtrisables ”, déclare Marc Boullier.

A l'inverse d'une application traditionnelle, un service n'est qu'une façade – une interface dépourvue d'état qui expose une application. Outre leur fonction de MOM (middleware orienté message), des ESB se différencient en se chargeant des dimensions techniques, jusque-là encapsulées directement dans les applications. “ Gestion des transactions, sécurité, transformation de messages, annuaire de services, etc. ”, énumère Sami Jaber, directeur technique de Valtech Toulouse.

Vers la fusion entre ESB et BPM ?

La plupart des SOA s'orientent vers une architecture Rest (Representational State Protocol). Cette approche consiste à relier les services à l'aide de simples messages XML, qui circulent sur différents protocoles standards : HTTP essentiellement, SMTP, FTP, et d'autres dans une moindre mesure. Le rôle de l'ESB est ici d'isoler la gestion du transport des messages des services. L'interface du service reste la même, mais, par exemple, le protocole de transport peut changer. L'ESB autorise donc l'utilisation, en toute transparence, de différents protocoles et logiciels (MOM, EAI, etc.) afin de transporter un même message entre deux services hétérogènes.

Les éditeurs sont aussi tentés d'intégrer à leur ESB un moteur de BPM (Business Process Management). Les experts ne sont pas tous d'accord avec cette approche. Pourtant, elle marque une évolution majeure dans les architectures d'entreprise : la logique métier et les services techniques qui l'accompagnent (sécurité, etc.) se déplacent au centre du modèle en couche.

“ On est enfin parvenu à isoler au milieu de l'architecture, entre les consommateurs finals et les services qui exposent les données, les processus métier de grosse granularité ”, remarque Sami Jaber. Ce qui permet notamment de gérer de façon distincte deux infrastructures techniques évoluant à des rythmes différents, sous diverses responsabilités.