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.

6 Responses to “ESB & démarche SOA”


  1. 1 Médéric Morel 09/01/2010 à 13:18

    Le cas d’utilisation de l’ESB dans le projet ne se rapproche-t-il pas de celui d’un ETL traditionnel ? Qu’est-ce que l’ESB apporte de plus qu’un ETL dans ce cas ? Médéric Morel

  2. 2 Erix 09/01/2010 à 16:39

    La cas A quant à lui se rapproche d’un modèle MOM, de type MQ-Series ou JMS. L’ESB est censé apporter dans ce cas un découplage entre les besoins de la couche client et les services métiers disponibles, en évitant des appels en dur des services depuis l’application cliente. En réalité, le couplage existe toujours, à travers les "noms de service" transportés sur le bus. Idéalement, il faudrait un véritable système d’intermediation de services métiers qui irait réellement plus loin que ce que les ESB d’aujourd’hui proposent, non ?

  3. 3 youen 09/01/2010 à 18:27

    Pour compléter le propos de l’article. Dans le projet B l’ESB est bien utilisé comme un EAI, c’est un dire que l’on construit des flux qui traitent les données au fil de l’eau. Les avantages sont donc :
    * intégration au fils de l’eau/temps réel le long de la journée (l’ETL est orienté traitement batch),
    * la possibilité de réutiliser des demi flux (connectique et format de message propre à référentiel existant),
    * la possibilité de monitorer les instances de flux (1 donnée à synchroniser à un instant t). L’ETL est lui orienté traitement en masse de type batch et sera intéressant quand il faut synchroniser un grand nombre de données dans une plage de temps réduite. Youen Chéné
    Logica Consulting Management 😉

  4. 4 Jean 21/01/2010 à 17:19

    Beaucoup d’idées reçues, justement, dans ce billet, et une vision extrêmement naîve de la SOA, qui vise au contraire à résoudre la problématique de la mise en oeuvre des systèmes distribués. Dans l’architecture A, l’ESB ne résoud rien du tout, et complexifie au maximum l’architecture proposée par l’exposition (déjà faite) des services Web en insérant une couche supplémentaire, véritable pot de pus de règles métiers transverses à cacher sous le tapis d’un bloc applicatif tout aussi transverse dont personne n’a la responsabilité. Mieux vaudrait écrire "MOM" sur le schéma.
    Quant au moteur BPM, c’est certainement plus vendeur que moteur de Workflow.

  5. 5 adolphe 28/07/2010 à 14:24

    La remarque de Jean met en évidence un point : sous le terme générique d’ESB, on pourrait bien trouver dans ‘produits’ ou des ‘solutions’ bien différentes les unes des autres……

    Dans le modèle A, ce qui pourrait légitimer l’utilisation d’un ESB n’est pas tant dans la mise en oeuvre des échanges ( qui sera finalement rendue très simple par l’ubanisation préalable ), mais bien tout ce qui va autour ( évolutivité, monitoring,…. et la nécessité à venir d’intégrer un nouvel ‘objet’ non encore urbanisé ou non urbanisable ).

    Par contre, le pot de pus que prévoit Jean risque bien de déborder si l’utilisation d’un ESB ne sert qu’à cacher la misère ( et ne pas réfléchir aux formats pivot par exemple ).

    Au final, opposer architecture SOA et solution ESB revient à comparer la soupe et la marmite, ce qui n’a aucun sens.

  6. 6 Arnaud 11/08/2010 à 16:44

    @Jean :
    « l’ESB ne résoud rien du tout »
    Le schéma proposé ici est largement simplifié, car le but de ce billet n’est pas de détailler un projet SOA mais de montrer deux utilisations qui pouvait être faite d’un même produit.
    Pour répondre concrètement, et contrairement à ce que vous affirmez (sans rien connaitre de ce projet), l’ESB apportent des solutions ;
    il effectue par exemple la composition de services métier, permet de facilement transformer des requêtes XML/Http (à destination d’un partenaire) en requêtes SOAP bien plus simples à gérer pour les développeurs Java, l’abstraction d’accès aux services qu’il permet facilite les migrations entre les environnements et le monitoring qu’il fournit est loin d’être un luxe.
    Je concède que cette solution n’est pas parfaite et que vous pourrez toujours trouver à y redire, mais vous ne pouvez pas affirmer qu’elle n’a aucune utilité.

    « Mieux vaudrait écrire « MOM » sur le schéma »
    Je ne pense pas, un MOM n’assure pas les fonctions décrites ci-dessus

    « un bloc applicatif tout aussi transverse dont personne n’a la responsabilité » -> D’où tirez vous cela ? Ai-je parlé de la maintenance et/où de la gouvernance de ces éléments ?
    Pour continuer, cette couche contient effectivemment des règles métier, et les éléments déployé dans l’ESB sont sous la responsabilité du projet qui l’a développé,
    et par extension, sous la responsabilité de l’équipe de TMA qui assure la maintenance du projet en question.

    « Quant au moteur BPM, c’est certainement plus vendeur que moteur de Workflow »
    Lorsqu’on modélise des processus métier en BPMN, que chaque étape de ce processus correspond soit à un appel de service soit à une action humaine, alors je parle effectivemment de BPM, parce que ce n’est plus un simple workflow.

    Pour conclure, vous pouvez trouver les ESB inutiles, mais ce n’est pas une raison pour dire n’importe quoi et lancer des propos dédaigneux

    @adolphe :
    Effectivement, le terme ESB cache des produits ou solutions bien différentes les unes des autres, et je suis totalement d’accord avec vous sur le fait que l’ESB ne doit pas juste servir à cacher la misère.
    Son utilisation requiert une méthodologie bien définie, qui doit notamment intégrer des formats pivot.

    Je comprend en revanche mal votre remarque « opposer architecture SOA et solution ESB » : Je ne voit pas où il s’agit d’une opposition dans ce billet ;
    extrait de l’introduction du billet : « 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 »


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s




Mises à jour Twitter

Erreur : Twitter ne répond pas. Veuillez patienter quelques minutes avant d'actualiser cette page.

Entrer votre adresse e-mail pour vous inscrire a ce blog et recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 29 autres abonnés

Catégories

Statistiques

  • 64 124 hits

%d blogueurs aiment cette page :