Principe du Demi-flux
Le patron de conception 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:
- Du contrat « Ad » au message au format pivot.
- 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énormalisation 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 :
- peu de services ne respectent les modèles pivots à l’initialisation d’une approche SOA
- le bus ne doit pas gérer les états des services
- des enrichissements en contenu sont nécessaires (BD, fichiers, services, etc)
- 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:
- La mise en oeuvre de facto de bonnes pratiques SOA
- Un évolution maîtrisée des contrats
- Un usage performant en runtime.
Middleware Solutions https://www.middleware-solutions.fr