Le blog

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 :

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.

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

Lien	Nom	Description
	Schéma canonique	Représentation unique d'une notion fonctionnelle pour tous les services.
	Expression canonique	Uniformise les contrats de service.
	Contrats concurrents	Contrats de services spécifiques à une problématique, un consommateur ou une version.
	Centralisation des contrats	Propose un point d'accès unique à un service.
	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.

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).

• 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.

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.

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.

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...

Références

• http://soapatterns.org/