Il était une fois dans une galaxie pas si lointaine, trois planètes majeures : Microsoft, Mainframe, Unix, le dernier étant un ensemble de plusieurs planètes ayant du mal à se parler. Nous sommes à une époque avant les années 2000, aucun transport ni échange n’existe entre ces mondes. Les habitants vont tenter de nouer la communication pendant plusieurs années. Certains réussissent, mais le chemin est encore long et fastidieux. Nous allons vous raconter cette aventure :
La guerre des intégrations :
Tout a commencé avec le boom des années 2000, qui accélère les besoins d’intégration dans les SI. Dans les années 2000 à 2004, des formats émergent, comme XML, SOAP. Pour faciliter le pont avec le legacy, les EAI arrivent avec leurs descendants les ESB (Entreprise Service Bus).
L’ESB contre-attaque :
A partir de 2004, ils deviennent matures, notamment avec tous leurs connecteurs, Mainframe, base de données, SAP… Le monde Java y est très présent, et oriente tous les standards, avec JMS, JPA, JTA, JCA… (Gestion de messages, des transactions…) et les ESB deviennent le standard de l'intégration.
Le retour du Web :
Vers 2008-2009, le web et ses standards arrivent, avec des formats plus souples, comme le JSON et le REST. On revient au basique, au pourquoi on a fait le http, on s'éloigne un peu de la complexité du SOAP, JSON est préféré au XML.
Pourquoi les ESB ont émergés ?
Les ESB sont arrivés dans une période de tentative de standardisation des patterns d'intégration. C’est Gregor Hohpe et son livre Enterprise Integration Patterns qui standardise nomme et fait émerger les standards du marché, qui sont toujours d’actualité. Il y présente les quatre niveaux de l'intégration :
Les quatre niveaux de l'intégration :
Du plus technique en bas avec l’intégration par la donnée, jusqu'à quelque chose de beaucoup plus métier, les processus. Processus qui sont des enchaînement d'actions parfois humaines,l'IHM qui va être la partie agrégation d'écrans.
Partons d’un exemple pour essayer d’y voir plus clair : Attention, le connecteur ne fait pas le moine.
Une application A qui communique avec une application B. Pour cela l’appli A génère un fichier et le passe à l’application B via un batch. Ce qui est important c'est le format des messages. Est-ce qu’on est dans une intégration par le service, ou par la donnée ?
Si ensuite on décide de passer par un web service à la place du batch, est ce que l’on a changé de type d'intégration ?
La réponse n’est pas dans la technologie ou dans le connecteur. Sans valeur ajoutée métier, on reste sur une intégration par la donnée. L'intégration par le service nécessite un métier, et sort juste de la simple implémentation technique, on ajoute des valeurs et des contrôles métiers.
C’est quoi un ESB ?
On peut découper un ESB (Entreprise Service Bus) en plusieurs couches. D'abord la couche transport, qui va s’occuper de toute la partie de gestion des messages, un bus, une file de message (JMS, kafka…).
Vient ensuite la couche de transformation, qui va permettre de manipuler le format de la donnée (Transcodification, EIP). Nous avons après la couche de gestion des processus, BPM, (message flow, parallel, inclusive). Il y a ensuite deux couches transverses, avec en premier la couche des connecteurs qui gère les différents protocoles standards, les connecteurs progiciels, les bases de données. Vient ensuite la couche administration, qui s’occupe de la partie déploiement, de la configuration et du monitoring technique.
Un cas d’usage d’un pattern d'intégration :
Voilà comment est-ce qu'on faisait dans les années 2000. Prenons un cas d'usage simple, avec un back office bancaire et un site web qui veulent afficher le solde d’un compte. Le pattern était de mettre un ESB devant le mainFrame pour faire la traduction des données du back-office de comptes
Il est aussi capable de gérer la partie transaction si besoin de garder un lien fort entre deux objets. Par exemple une partie débit et une partie crédit. Il va synchroniser avec le mainframe les commits et les rollbacks.
C'est aussi l'ESB qui va pouvoir s’occuper de la partie orchestration de workflow, comme la gestion des étapes d’une demande de crédit, l'envoi des notifications aux applications concernées.
C'est donc un outil un peu couteau suisse qui est capable de s'adapter à beaucoup de cas d'usage, et il permet de capitaliser sur l'existant, sans recoder des fonctionnalités techniques.
Les huit vérités qu’on ne vous a jamais dit sur les ESB :
L’outil ne fait pas l’architecture. On est passé de EAI à ESB et maintenant API management, les produits sont parfois même restés les mêmes en changeant simplement de noms.
La promesse de l'intégration sans code n’a jamais été tenue sur le terrain. C'est peut être le cas au début, mais on finit toujours par revenir à du code plus ou moins simple à valider, à tester et à maintenir.
Un ESB est un outil de développement. Vu qu’on met du code dedans, il doit être maintenu par une équipe avec les compétences requises et doit avoir un responsable applicatif, que ce soit au build comme au run.
L’ESB ne réduit pas la complexité du SI. Voilà par exemple la promesse typique que peuvent donner des vendeurs de middlewares :La réalité est plutôt :C’est un peu des spaghettis mis dans une boite. La complexité reste la même, mais vient se mettre dans un seul outil. C'est une seule équipe qui va gérer cette complexité. En fonction des cas cela peut être avantageux ou non. Et vous avez une application en plus dans votre SI.
L’ESB est un bon outil d’industrialisation de flux. Même si on a eu la main un peu lourde sur les ESB, mais il y a aussi des belles réussites. Ça fonctionne, c’est même à ça que ça sert.
Le coût de mise en place d’un ESB est élevé. C'est un outils complexe, Il faut former les développeurs et les opérateurs, prendre en compte le temps de prise en main, et potentiellement les coûts de licences et du support.
Les promesses du monitoring et du rejeu. L’un des projet les plus coûteux sera le monitoring et l’autre le rejeu des flux. Le monitoring technique des composants ne vous permet pas de comprendre ce qui s’est passé dans un flux logique/métier. Même si la solution le permet techniquement, les rejeux font partis d’une logique métier, qui doivent s’adapter à chaque cas. Pour monitorer des centaines de flux métier, il faut faire des projets entier de monitoring et ça peut coûter cher.
Mutualiser à priori est une optimisation prématurée. Le coût d'investissement dans un ESB ne rentabilise qu'au bout d'un certain temps. Attention à ne pas vouloir aller trop vite. Parfois il est être plus efficace dans le cas de peu de flux de se passer de l'ESB. Sur la partie organisationnelle, le risque est placé sur l'équipe qui gère l'ESB qui va concentrer tous les problèmes de l'entreprise.
Take Away :
Est-ce que c’est un problème d’avoir un ESB dans votre SI en 2020? De manière générale la réponse est non, surtout si vous avez un existant qui ne vous coûte pas trop cher. c’est comme toute technologie plus ou moins récente, si vous avez un FTP ou un ancien CRM, le problème est similaire. Il peut être bon de capitaliser sur l’existant.
Pour le lancement d’un projet à forte composante d'intégration, l’ESB peut être un couteau suisse, notamment si le sujet est transverse à plusieurs domaines, avec par exemple des ERPs différents, un mainframe, des flux déjà existant ou de la GED (Gestion Electronique de Documents).
Pour tous les autres cas, les ESB ont été construits à la base parce qu'il manquait des standards de communication entre systèmes. Il y en maintenant suffisamment, il vaut mieux préférer les standards d’aujourd’hui, des API type REST, avec une intégration native entre applications sans intermédiaire si possible.
