ESB & démarche SOA

Contrairement à une idée reçue encore largement répandue, l’utilisation d’un ESB ne va pas forcément de pair avec une démarche SOA. Cette idée vient sans doute du fait que la notion d’ESB a émergé dans le même temps que celle de SOA, et qu’une majorité de schémas d’architecture SOA contiennent un ESB en point central.

Soyons clair : Il est possible d’utiliser un ESB sans suivre de démarche SOA, et à l’inverse, il est possible de construire sa SOA sans utiliser d’ESB.

Cet article s’intéressera au premier point évoqué ci-dessus, à savoir l’utilisation d’un ESB hors d’un contexte SOA ; Afin de mettre en parallèle deux types de démarches – l’une SOA, l’autre non - j’utiliserais deux exemples de projets utilisant un ESB développés chez l'un de nos clients.

Projet A

Nouvelle application, basée sur l’architecture standard SOA définie par la société : division de l’application en trois couches principales :

• Une couche de présentation, développée en Java JEE avec le framework maison apportant les composants RIA, aujourd’hui incontournables pour réaliser une IHM graphiquement réussie
• Une couche de médiation, développée dans l’ESB sous la forme d’une dizaine de services qui effectuent les appels aux services métiers, avec routages selon le contenu, transformations (syntaxiques) et agrégations d’informations destinées à l’IHM.
• Une couche de services métiers, écris en Java et exposés sous forme de web services. Ces services assurent les traitements métiers ainsi que la gestion des interactions avec la base de données.
  

Cette application utilise également un moteur BPM, qui fait appel à un certain nombre de services de médiation. L’utilité première du moteur BPM dans cette application est la gestion des interactions humaines (processus de validation à plusieurs niveaux).

Projet B

Nouvelle application basée sur un portail open source, dans le but de fournir aux clients l’accès à leurs données, d’être informés des nouveautés de la société, ainsi que d’effectuer des demandes liées à leur compte client.

Cette application utilise en majorité des informations déjà présentes dans le système d’information, mais disséminées dans une petite dizaine de bases de données distinctes ; il n’était pas possible d’utiliser directement les bases existantes, pour des raisons de volumétrie d’une part, et à cause de données erronées existantes dans le système d’autre part.

Ce projet a donc sa propre base de données contenant l’agrégation des données contenues dans les autres systèmes de la société ; cette solution présente l’avantage de pouvoir filtrer les données fournies au portail, de ne pas surcharger les bases existantes, ainsi que d’optimiser les performances de l’application (base de données unique et dédiée). La solution technique retenue pour la réplication des données a été un ESB, afin de disposer d’une synchronisation en temps réel des données.

La différence d’approche :

Qu’est ce qui différencie fondamentalement la manière dont est utilisée le même ESB dans ces deux projets ?

Le projet A a été conçu à partir des besoins fonctionnels de l’application en termes de données et de traitements : Le processus métier, ainsi que les services avec leurs opérations et leurs interfaces respectives ont tout d’abord été modélisés, avant de concevoir les couches plus basses et l’implémentation jusqu’au modèle de données. On se situe donc dans une approche top-down, cohérente avec une stratégie SOA.

A contrario, dans le projet B, l’utilisation de l’ESB est focalisée sur la réplication des données contenues en base, et les besoins fonctionnels du portail ne transparessent que dans la nouvelle structure de données utilisée par l’application (par rapport aux référentiels existants). L’ESB ne sert pas à exposer des services mais uniquement à remplir une base de données, ce qui correspond à la vision EAI (Enterprise Integration Application) de l’intégration de données. Il est également à noter que cette application portail représente un nouveau silo dans le SI.

Le projet A est donc un vrai projet SOA, où l’ESB est utilisé comme point d’accès central vers des services métiers dont une partie est réutilisable, tandis que le projet B ne se sert de l’ESB que pour créer des flux d’intégration de données entre les référentiels internes et la base de données de la nouvelle application, ce qui n’a rien à voir avec de la SOA.