Vision des ESBs par un architecte d’entreprise
— Article 1 – Un peu d’histoire —

Cet article est un des articles de la suite `Vision des ESBs par un architecte d’entreprise`.

Entreprise Application Integration

Au tout début des années 2000, apparaissaient les outils d’EAI (Entreprise Application Integration).

Ceux-ci avaient pour vocation de répondre à une problématique d’intégration d’applications en corrigeant les habitudes prises de liaisons point-à-point par la mise en place d’un « hub » d’intégration

Les différentes applications sont ainsi dé-corrélées. Elles ne connaissent qu’un seul interlocuteur : le « hub ». L’intégration se fait alors par des messages transitant d’une application vers le hub et/ou du hub vers une application. On parle de « demi-flux », et d’une intégration par flux, plutôt de nature « fil de l’eau ».

On retrouve dans ces outils différents composants :

  • des connecteurs ou adaptateurs en charge de transformer le langage des applications (protocole et format de données) dans un langage commun à toutes les applications,
  • des composants de médiation/traitement que l’on peut simplifier en les nommant EIP (Entreprise Integration Patterns). Ils assurent des fonctions de routage, transformation, …
  • un MOM (Message Oriented Middleware) : en charge d’assurer le transport des messages

Service Oriented Architecture

Dans le même temps est apparue l’« architecture orientée services ». Certains, dont je fais partie, diront que cela existait déjà depuis la décennie précédente sans se nommer ainsi, avec par exemple : Corba ou les services Tuxedo ; mais ceci n’est pas le sujet.

La SOA (Service Oriented Architecture) définit un modèle d’interaction applicative mettant en œuvre des connexions faiblement couplées entre divers composants logiciels. On entend par « service » une action exécutée par un composant « fournisseur » à l’attention d’un composant « consommateur », basé éventuellement sur un autre système. La connexion faiblement couplée implique l’utilisation d’interfaces d’invocation et de vocabulaires de description de données qui soient communs à l’ensemble des composants logiciels, tant du côté des fournisseurs que des consommateurs.

Cette architecture n’implique pas nécessairement l’utilisation des services Web dans des technologies SOAP ou WSDL mais peut être également mise en œuvre au sein d’un même processus Java notamment avec des conteneurs légers tels que Spring. Dans ce contexte, nous parlons de fournisseur de services et de consommateurs de services, les fournisseurs mettant à disposition des composants.

Dans un contexte d’intégration d’applications d’un système d’information, on parlera aussi de SOI « Service Oriented Integration » voir même de SOE « Service Oriented Enterprise ».

Entreprise Service Bus

Bien qu’il n’y ai pas de date précise, on peut situer la naissance des ESBs autour des années 2000/2005. Ces premiers ESBs étaient une association des concepts « EAI » et « web-service ». Le terme ESB était alors un peu galvaudé car loin de la SOA. Les discours marketing ont entériné cette variante de la définition de l’ESB.