Vision des ESBs par un architecte d’entreprise
— Article 2 – Approche orientée « service » —

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

Si l’on regarde de plus près dans les logiciels ESB, on s’aperçoit que « l’approche orientée services » de la définition précédente est très souvent faussée. Ceci est principalement dû aux premiers ESBs sortis qui étaient concrètement des EAIs complétés par des technologies « web-service ».

L’approche orientée « service », dans le cadre d’une solution d’architecture permettant l’intégration d’application d’un système d’information, sous entends :

• le couplage lâche entre le consommateur de service et son fournisseur : un consommateur de service n’est pas impacté par une modification du fournisseurs de service, tant que son interface n’est pas touché. Et même plus, il n’y a pas de raison qu’un consommateur de service soit impacté par la modification d’une interface induite par un nouveau besoin d’un autre consommateur (cf. versionning de services),

• l’élection d’endpoint : Afin de respecter le principe de couplage lâche un consommateur de service (une application) ne doit pas connaître la localisation du fournisseur de service (une autre application). Ceci implique qu’un consommateur de service ne doit jamais indiquer explicitement la localisation (l’endpoint) du fournisseur de service auquel il l’adresse. L’ESB doit déterminer cet endpoint en fonction du service demandé et de divers autres critères (charge du fournisseur de service, disponibilité du fournisseur, nature d’implémentation du service, partitionnement de données¹, …),

• le changement d’implémentation de service : Comme un système d’information vit, une ressource applicative, existante aujourd’hui dans le SI, implémentée avec un logiciel ou une technologie du marché actuel se verra remplacer un jour ou l’autre par un autre logiciel ou une autre technologie. Le service utilisé pour intégrer cette ressource applicative évoluera de la même manière. Pour ne pas impacter les consommateurs de ce service d’intégration, il suffit que :

  • l’interface soit conservée, c’est le minimum du minimum,

  • les consommateurs ne précisent pas « l’ endpoint » du fournisseur de service, cf « l’élection d’endpoint »

  • le service soit déployable unitairement,

• le versionning de service assure le couplage lâche en cas de modification de l’interface de service. Un fournisseur de service délivre son service à plusieurs consommateurs. Il est possible que pour une raison fonctionnelle dûment justifiée il soit nécessaire de faire évoluer l’interface du service à la demande d’un des consommateurs. Cette évolution n’est pas nécessaire pour les autres consommateurs. Il suffit alors de créer une nouvelle version du fournisseur de service. Le consommateur qui en a besoin utilise la nouvelle version du fournisseur de service. Les autres consommeront l’ancienne sans avoir été impactés.