Introduction sur les ESB dans le domaine du développement web

Tout au long de cette publication, nous limiterons le périmètre à l'utilisation d'un ESB (Enterprise Service Bus) dans le cadre de projets numériques comme la réalisation d'une plateforme ou d'un écosystème web. Nous n'évoquerons pas son utilisation au sein d'un SI complet d'une entreprise même si certains concepts sont similaires lorsqu'il s'agit de la gestion des données au sein d'un environnement informatique comportant un nombre important d'applications ayant un fort taux de couplage entre elles.

Tout d'abord, nous allons parler de l'évolution de l'architecture de données d'une plateforme web à travers le temps. L'architecture de données étant un ensemble de règles qui déterminent toutes les étapes de la vie d'une donnée depuis sa récupération jusqu'au stockage ainsi que son affichage ou son utilisation.

Dans un second temps nous détaillerons les différentes problématiques liées aux architectures de données actuelles.

Ensuite nous nous présenterons le rôle d'un ESB, son fonctionnement ainsi que ses avantages pour répondre aux problématiques que nous aurons énoncées dans la section précédente.

Avant de finir nous présenterons l'ESB développé par MuleSoft nommé Mule ESB.

Pour finir, mon collègue dans une autre publication réalisera une série de tutoriels sur la réalisation d'applications utilisant mule ESB.

Faisons un petit saut en arrière, lorsque l'architecture de données d'un site web standard ressemblait à peu de choses près au schéma ci-dessous.

À cette époque l'architecture de données pour un site web était simple, les seuls flux de données étant :

• les interactions avec les bases de données ;
• les interactions avec le système de fichiers ;
• les données clients, fournisseurs ou partenaires saisies via des formulaires de manière manuelle.

Les sites pouvaient donc fonctionner de manière autonome et ne dépendaient pas de données tierces ou de services externes, car le besoin n'existait pas à l'époque.

De nos jours, nous développons des plateformes, voire des écosystèmes web. Le besoin a donc évolué et les interactions avec les fournisseurs ou partenaires se font de plus en plus en temps réel (via des web services par exemple). Le nombre de connexions avec des services différents ne cesse de croître, l'architecture de données évolue et peut désormais s'avérer complexe comme nous le présente le schéma suivant.

Prenons par exemple la plateforme web d'une grande marque dont le but est de présenter ses produits. Le développement est effectué par une agence web (représentée en jaune sur le schéma ci-dessus) dont nous prendrons le point de vue pour la suite de l'explication. La plateforme devra être localisée pour un grand nombre de pays.

Le développement de certaines parties spécifiques de cette plateforme est géré par des partenaires (représentés en vert) tels que :

• les pages externes concernant les points de vente et leur géolocalisation (via une redirection invisible vers un autre domaine ou serveur) ;
• la gestion, en SAAS, des commentaires utilisateurs et leur modération (via une inclusion JavaScript) ;
• la récupération et l'uniformisation des données clients pays en une base unique (base de données centrale).

Le client (représenté en bleu) dispose déjà d'une base de données utilisateur, ainsi que d'une autre plateforme web. Les deux plateformes vont avoir des interactions (échange de données) avec la nouvelle plateforme.

Sans oublier les réseaux sociaux (représentés en violet) dont l'interaction peut être non négligeable lorsque l'on parle de réseaux sociaux différents par pays. Par exemple la Russie ou la Chine n'utilisent pas Facebook, mais Vkontakte ou encore RenRen.

Ceci étant l'architecture de départ, il ne faut pas oublier que ce type de plateforme est en constante évolution et les besoins de connexion avec de nouveaux services sont fréquents. Par exemple une volonté de la part du client de rester innovant ou bien la vitesse d'apparition des réseaux sociaux.

Comme nous avons pu le voir dans la section précédente, suite à l'augmentation croissante du nombre d'interactions en tout genre, de nombreuses problématiques voient le jour :

• l'augmentation exponentielle de la complexité

En fonction du nombre d'interactions, la complexité liée à la maintenance et à l'évolution augmente exponentiellement. C'est une problématique importante pour les entreprises s'appuyant sur un nombre croissant de connexions avec des partenaires comme une partie de leur « business model ». Dans le domaine du numérique, l'évolution d'une plateforme web est également soumise à ce genre de problématique ;

• la multiplication des points d'erreur

Peu importe le type d'architecture, avec l'augmentation du nombre d'interactions, le nombre de points d'erreurs possibles augmente considérablement. Votre gestion d'erreurs sera spécifique à chaque interaction entre votre connecteur et le service externe. La mise en place de stratégie d'erreurs commune devient alors assez compliquée ;

• perte de modularité

Les architectures n'utilisant pas d'ESB en leur sein présentent un fort taux de couplage entre les différentes briques applicatives de la plateforme. Lors de l'ajout d'une nouvelle brique, celle-ci doit être liée à toutes les autres en utilisant de nouvelles connexions ayant un fort taux de couplage. L'intégration avec de nouveaux partenaires prend alors des semaines au lieu de jours et peut ne pas être faite du tout.

Le terme « Bus » de « Enterprise Service Bus » est une analogie du « Bus » interne d'un ordinateur sur lequel sont branchés le CPU, la RAM et les autres cartes. Sauf qu'à la place d'avoir des composants, nous avons un client et des services.

En termes d'architecture, nous pouvons le comparer à une configuration réseau nommé « Topologie en bus » qui est en soi l'organisation la plus simple d'un réseau dans lequel tous les ordinateurs sont reliés à une même ligne de transmission.

Le schéma ci-dessus est le même que le 2, sauf qu'il utilise un ESB au sein de son architecture de données. Comme vous pouvez le voir, désormais tous les composants externes à la plateforme sont raccordés sur l'ESB, qui expose ensuite des services à destination de la plateforme (via des API internes par exemple).

Votre ESB aura plusieurs rôles à jouer sur les données :

• transformation ;
• vérification ;
• routage ;
• agrégation.

C'est un point de passage central pour vos données qui vous permet d'en changer le format (XML, JSON, DTO…), de vérifier leur validité, de les agréger avec des données supplémentaires et enfin de les rendre disponibles ou de les router vers un service externe.

Le format de dialogue entre la plateforme web et l'ESB peut être standardisé afin que tous les services communiquent de la même manière avec les différentes briques de la plateforme.

Faisons maintenant un point sur les problématiques énoncées dans la section précédente.

• L'augmentation exponentielle de la complexité

La complexité ne disparaît pas pour autant avec une architecture incluant un ESB. Elle est déplacée au niveau de l'ESB lui-même et n'est donc plus dispersée à travers l'ensemble de la plateforme web. La complexité n'augmente plus exponentiellement pour chaque composant venant communiquer avec l'ESB, ce qui est déjà en soi un avantage considérable.

• La multiplication des points d'erreurs

La gestion d'erreurs est et sera toujours un point essentiel de tout projet. Dans le cadre d'une architecture utilisant un ESB, la gestion d'erreurs et le monitoring se fait en un point unique, ce qui procure un avantage non négligeable.

Cela facilite la mise en place d'une stratégie d'erreurs commune à l'ensemble de la gestion des données. Le monitoring de vos différents connecteurs vers des composants externes se fait aussi au niveau de l'ESB, ce qui vous permet d'avoir des métriques sur le taux d'erreur de vos connecteurs afin de pouvoir, le cas échéant, effectuer une revue de code pour en améliorer la stabilité.

L'ESB vous permet également de gérer les interactions de manière transactionnelle. En effet, si une erreur est relevée par un des éléments de la chaîne, on peut alors effectuer des « rollback » ce qui présente un avantage fort appréciable.

-Perte de modularité

Dans un cadre d'entreprise, le plus souvent l'architecture mise en place est pensée de manière modulaire, mais avec le temps et l'ajout continu de nouveaux composants la modularité de votre architecture peut diminuer pour devenir une architecture dite « plat de spaghettis », car vos différents composants deviennent dépendants entre eux et les connexions trop fortement couplées.

L'utilisation d'un ESB dans une architecture de données permet de garder toujours le même niveau de modularité quant à l'ajout de nouveaux composants externes nécessaires à la plateforme web.

Ce scénario est en partie générique quant à l'ajout d'une nouvelle interaction entre une plateforme web et un service externe.

Besoin : le client veut ajouter un nouveau réseau social sur sa plateforme.

1. Nous allons créer une application ayant le rôle de « connecteur » vers le nouveau réseau social. Cette application sera notre lien avec l'API du nouveau réseau social.

   De par ce fait, on minimise l'adhérence de notre code à celui du réseau social. Si son API évolue, seulement le connecteur sera amené à être modifié. Il hébergera donc aussi le code métier (vérification, agrégation, routage, transformation) afin de limiter le périmètre de toutes les éventuelles modifications fonctionnelles.

2. Une seconde application que nous allons appeler « façade » ou « interface » contiendra les signatures des différentes méthodes et en fera l'exposition vers notre plateforme. Elle peut également servir à certaines vérifications préliminaires des données. La communication entre cette application et le connecteur peut se faire de différents moyens comme JMS (Java Messaging Service).

Une telle architecture vous permet d'assurer une continuité de service même durant les maintenances ou les évolutions. Vous pouvez par exemple déployer une nouvelle version d'un connecteur et le tester en incrémentant la version au niveau de l'URL (http://api.com/2.0/facade) tout en gardant l'ancien connecteur fonctionnel (http://api.com/1.0/facade).

Dans cette partie, nous allons présenter l'ESB développé par Mulesoft nommé Mule ESB.

Il se décline en deux versions, une communautaire open source et une version commerciale entreprise. La version entreprise apporte la possibilité d'utiliser l'ETL (Extract Transform Load) nommé CloverETL ainsi que le « High Availability » qui offre la possibilité de mettre en cluster plusieurs instances de Mule ESB.

Sur le marché actuel un grand nombre d'ESB sont disponibles soit en open source comme Talend ESB, JBoss ESB, Open ESB ou propriétaires comme Oracle Enterprise Service Bus, WebSphere Process Server(IBM) pour ne citer que les plus grands.

La question qui se pose alors est pourquoi avoir choisi Mule ESB ?

Mule ESB est une plateforme d'intégration légère qui lui permet de s'intégrer parfaitement dans des projets numériques comme le développement de plateforme web. Il diffère des ESB comme ceux d'Oracle et d'IBM qui sont eux plus destinés à être intégrés dans des SI et proposent des environnements complets depuis le dépôt du code jusqu'au déploiement. Le prix de la licence pour la version entreprise est également plus abordable du côté de Mule ESB.

Il propose également son propre IDE nommé « Mule Studio » qui est une surcouche de l'IDE Eclipse. Une partie graphique a notamment été ajoutée afin de faciliter la création d'applications. De nombreux connecteurs sont proposés par l'éditeur ainsi que par la communauté et vous permettant de faciliter l'intégration avec un panel de services connus tels que Sharepoint, Salesforces, LDAP, Facebook, Twitter…

Une console d'administration nommée MMC (Mule Management Console) est également disponible. Elle a pour vocation d'être installée sur un serveur Tomcat et vous permet d'administrer vos serveurs mules ESB ainsi que les applications déployées sur ceux-ci.

Celle-ci vous propose un panel de fonctionnalités telles que :

• déploiement d'applications sur votre serveur ESB ;
• des métriques sur le statut de votre serveur et de vos applications ;
• gestion d'alertes sur un panel de condition (statut serveur, erreur application…) ;
• arrêt/démarrage de votre serveur ;
• gestion des clusters d'instance ;
• analyseur d'application (utile pour du débogage) ;
• gestion d'utilisateurs et de droits quant à l'accès à la console.

Comme nous avons pu le constater tout au long de cette publication, la mise en place d'un ESB au sein d'une architecture de données permet de faciliter et de contrôler l'ensemble des échanges de données nécessaires au bon fonctionnement de votre projet. L'ajout d'une nouvelle interaction avec un service externe suit un schéma générique et devient une tâche commune. La qualité de votre architecture de départ ne s'amenuise pas avec le temps et les modifications éventuelles.

En entreprise, dans le domaine du numérique, nous pouvons remarquer que certains clients veulent souvent faire une refonte de leur plateforme web simplement, car l'architecture de données est devenue incompréhensible et de ce fait la maintenance et son évolution sont un gouffre en termes de charge et de coût.

Avec l'utilisation d'ESB au sein de l'architecture de données, nous pouvons espérer que dans le futur les plateformes web seront moins sujettes à des refontes basées sur une problématique d'interactions trop nombreuses résultant en une complexité globale trop élevée. Néanmoins l'ESB étant un point de passage central, si le serveur ESB tombe, votre plateforme est coupée de tout.

L'équipe Developpement web tient à remercier DigitasLBi pour ce tutoriel.

Nos remerciements à infosam76 pour sa gabarisation et à ClaudeLELOUP pour sa correction orthographique.

N'hésitez pas à commenter cet article ! Commentez