Architecture

Integration – Pattern SOA demi-flux

Publié le : Auteur: Emmanuel Lesne Un commentaire
architecture

Au fil des missions et des clients, nous constatons souvent les mêmes erreurs au sein des méandres des ESB. Bien que cela me fasse du travail, je vous propose un patron de conception très pratique qui évite de nombreux écueils. Il s’agit du patron (pattern) Demi-Flux.
Il garantit :

  1. Un couplage faible entre les systèmes
  2. Une évolution des formats et des protocoles sans propagation au reste du SI
  3. Une bonne gestion des versions des contrats de service
  4. Un partage des responsabilités entre les équipes.

Il couvre de l’interface technique (format et protocole spécifique) jusqu’à une vision cohérente et compatible avec le Système d’Information. Ils sont mis en jeux dans des routes. La route comporte un départ, un chemin puis une ou plusieurs fins. La route est divisée en demi-flux.

Ils portent la responsabilité de réaliser une transformation d’une représentation spécifique vers une générale, et vice-versa. Il s’agit du découpage d’une route en plusieurs étapes. En général et en fonction des outils, on aboutit à des éléments opérationnels clairs, distincts et performants. 

L’élément clé est le bus d’entreprise (ESB). Il met en jeu ces demi-flux lors de ses coordinations et compositions de messages et de services.

Principes

Le pattern de demi-flux prend racine dans 3 principes simples:

  • les contrats de services sont exposés en modèle pivot
  • les contrats de services sont figés et versionnés
  • le bus de service expose les contrats

Par exemple, la diffusion d’un contrat de service A dans un système d’informations s’illustre de la manière suivante :

Demi-flux

Le contrat de service « A » est obligatoirement exposé avec des données fonctionnelles au format Pivot (cf. Schéma canonique), interface nommée « Ap ». Ce contrat devient la référence partagée entre tous les consommateurs. « A » n’est plus accessible directement ! Toutefois, si un autre consommateur nécessite une version différente (réduction du périmètre, problème technique, etc.) une vision dénormalisée « Ad » est ajoutée afin de faciliter l’utilisation du contrat « Ap ». Une version sécurisée « As » est identique (non représentée ci-dessus).

La route est alors le chemin parcouru entre l’appel au contrat « Ad » jusqu’au contrat « A ». Chaque demi-flux est la partie amont OU aval au format pivot. Dans l’exemple précédent, il y existe donc 2 demi-flux:

  1. Du contrat « Ad » au message au format pivot.
  2. Du contrat « Ap » jusqu’au contrat « A » au format natif.

Route et demi-flux

Au final, sans s’en rentre compte, de nombreux patrons SOA sont respectés. La liste non-exhaustive est la suivante:

Lien Nom Description
Canonical Schema Schéma canonique Représentation unique d’une notion fonctionnelle pour tous les services.
Canonical Expression Expression canonique Uniformise les contrats de service.
Concurrent Contracts Contrats concurrents Contrats de services spécifiques à une problématique, un consommateur ou une version.
Contract Centralization Centralisation des contrats Propose un point d’accès unique à un service.
Contract Denormalization Dénomalisation de contrats Adapte les contraintes fonctionnelles aux consommateurs et producteurs.

 

Malheureusement, dans la pratique, il est nécessaire de complexifier la mise en oeuvre car :

  1. peu de services ne respectent les modèles pivots à l’initialisation d’une approche SOA
  2. le bus ne doit pas gérer les états des services
  3. des enrichissements en contenu sont nécessaires (BD, fichiers, services, etc)
  4. les versions de services sont multiples.

Ces points aboutissent à une architecture plus complexe avec une séparation des responsabilités entre l’ ESB et un moteur d’orchestration BPEL. Ce dernier intègre nativement les gestions transactionnelles, les transactions longues, les reprises ainsi que la gestion des états. Il est mis à profit pour cela.

Le schéma suivant illustre l’exposition du service B. C est utilisé lors dans une orchestration ou une composition par le moteur BPEL. Remarquez que la partie SCA ne manipule que le modèle Pivot.

Vision générale complete

En diffusant des services uniquement par le bus, celui-ci peu être utilisé de manière optimal. Il met en jeu ses fonctionnalités majeures telles que la maîtrise des surcharges, la non contention des producteurs, la gestion des SLA, la sécurisation des contenus, les transformations de contenus et les médiations protocolaires.

En synthèse, le pattern demi-flux apporte 3 avantages majeurs:

  1. La mise en oeuvre de facto de bonnes pratiques SOA
  2. Un évolution maîtrisée des contrats
  3. Un usage performant en runtime.

Exemple n°1 : Intégration de référentiels ou gros systèmes

Cet exemple illustre le cas d’une intégration de 2 systèmes existants type SGBD ou ERP. Dans ce cas de figure, il faut se focaliser sur l’interconnexion, c’est-à-dire les interfaces de ces systèmes puis comment les relier entre eux. La route se compose alors de:

  1. Un connecteur A réceptionne les données ou messages du système A. Tout est spécifique à cette interface: protocole, format et interaction(s). Dans cet exemple, il se connecte au système et récupère une liste d’enregistrements SQL. Il transforme le contenu en format pivot.
  2. Le bus joue ensuite son rôle de routage et filtrage vers le consommateur B.
  3. B est manipulé avec un contrat au format pivot. Après transformation, un connecteur interprète le message, le transforme dans le format natif puis le diffuse au système cible B via un connecteur (autre formalise et protocole).

Exemple n°1: Interconnexion entre GS

Mais pourquoi faire tout cela alors qu’une route de A vers B serait plus directe et plus rapide à coder ?
Par exemple pour :
  • ajouter un système C qui serait aussi consommateur des messages provenant de A
  • ou bien faire évoluer B sans impacter A
  • … qui a dit que B n’était pas déjà utilisé par un autre consommateur ??
  • etc.

Exemple n°2 : Consommation d’un service

Ce 2nd exemple illustre la consommation plus classique d’un service par le système A. Ce service nécessite des informations provenant des systèmes B et C.

Que faire ? Publier un message au format de B et le transformer en C ? l’inverse ? Que se passera-t-il lorsque le format de B évoluera ? Si le système C n’est pas pérenne, comment minimiser les efforts et préparer l’avenir ? 
 

Le contrat de service doit être exposé au format pivot. Il n’est donc pas spécifique à B ou à C. Ce service est considéré comme nouveau, appelé D. Il portera sa version 1.0. Il encapsulera les changements des services B et C. Chacun possédant déjà leur propre version.

Exemple n°2 Service

La route comporte ainsi 3 demi-flux:

  1. Un demi-flux exposant le contrat de service D, de l’interprétation au routage vers B et C.
  2. Un demi-flux pour le contrat de service B
  3. Un demi-flux pour le contrat de service C.
Il y a donc 3 services proposés par le bus: le service D mais aussi le service B et C qui se retrouvent de facto avec des interfaces au format pivot. La gouvernance SOA devra alors déterminer si ceux-ci doivent être rendus publiques.

Quelques outils pour implémentation

Ce chapitre identifie rapidement quelques outils adaptés à cette mise en oeuvre. Seules les solutions complètes offrent une couverture complète ESB et SCA. Sans moteur BPEL, il convient de développer un socle similaire. Nous vous déconseillons fortement de réinventer la roue…

Editeur Solution Commentaire
Oracle ESB: Oracle Service Bus
SCA: SOA Suite
Les 2 outils sont distincts et apportent une réelle séparation des runtimes.
RedHat ESB: Fuse ESB
SCA: Fuse Services Works
Le produit Fuse Services Works est nouveau mais apporte une réelle complémentarité à l’excellent Fuse ESB.

Références