Retour d’expérience : Utilisation d’un ESB pour la constitution d’un système de gestion des évènements

L’ESB est devenu ces dernières années un élément quasiment incontournable des architectures SOA. David Macchion développe d’ailleurs dans son article de ce mois ci une analyse sur le choix de l’ESB et de son retour sur investissement, que je vous recommande.

Je vous propose ici un retour d’expérience pragmatique sur une utilisation de l’ESB qui sort des usages standardisés de simple médiation ou de réexposition de services.

Situation de l’enterprise :

L’entreprise est une grande compagnie dont le parc applicatif est très hétérogène : on y trouve une collection d’applications Mainframe qui compose le coeur de métier, des applications client-serveur, des applications web (et je ne m’étends pas sur les différentes technologies utilisées, les serveurs d’application, progiciels, etc).

La situation projet :

Le cœur de métier est éparpillé entre différents applicatifs qui ne communiquent pas entre eux. Or, dans le cadre de la création d’un nouveau poste de travail, il est nécessaire d’avoir une vision unifiée de tous les événements relatifs à un dossier client.

Afin de ne pas multiplier les appels vers les backend, principalement situés dans le Mainframe, pour aller récupérer ces événements, la création d’un dépôt central des événements a été décidée (je ne rentrerais pas ici dans le détail de ce système qui n’est pas l’objet de cet article).

Il faut ajouter à cela des besoins exprimés par d’autres applications d’exploiter ces mêmes événements en provenance des backends.

Ce dépôt d’événements doit bien entendu disposer de données de première fraicheur : la transmission des événements des backends doit donc se faire « au fil de l’eau ».

Une première idée :

L’entreprise dispose dans son catalogue applicatif d’une ESB embarquant un système JMS.
Une solution pouvait paraitre assez évidente au premier abord : le topic JMS ; chaque backend publie sur un topic ses événements puis chaque application consommatrice s’abonne au(x) topic(s) qui la concerne.

Problème : pour des questions de performances évaluées précédemment, utiliser les topics JMS est proscrit par la cellule architecture. Le timing du projet nous permettait difficilement de faire bouger les lignes sur ce sujet, et nous avons choisit de composer avec cette contrainte.

La solution développée :
Nous avons donc opté pour une solution basée sur des files JMS, et des composants développés dans l’ESB qui permettent de gérer le transit des messages entre les producteurs et les consommateurs d’événements.

Description des différents éléments du système :

• Le module d’entrée : Grâce à la connectivité de l’ESB, il a été très simple de créer deux canaux d’entrée : Un canal JMS et un canal web service SOAP. Ces deux points d’entrée permettent de faire transiter l’ensemble des événements, même si les structures XML des événements ne sont pas toujours les mêmes : une partie commune, l’entête technique est obligatoire (système d’origine, version de l’événement, etc), et la partie contenant les données métier de l’événement vient ensuite. Dans les XSD, cette partie métier est définie comme un CDATA (partie ignorée par les parseurs XML), ce qui permet d’y mettre n’importe quelle structure XML.

• Le module de validation : Comme décrit ci-dessus, le module d’entrée ne fait aucun contrôle sur les données métier de l’événement. Cette tâche est laissée au module de validation, qui à partir du numéro de version de l’événement détermine la XSD correspondante aux données métier de l’événement, et valide le format des données fournies. En cas de non-conformité, l’événement est mis de côté et l’origine de la non-conformité doit être déterminée manuellement par le backend émetteur.

• Le module de routage : Ce module se charge de vérifier les abonnements des applications consommatrices, et de router chaque événement vers les files JMS appropriées. Chaque application consommatrice dispose de sa propre file JMS.

Conclusion :

Au delà des aspects fonctionnels, deux points sont particulièrement importants :

• La performance : Suite à une campagne de test dans un environnement de préproduction, les temps varient entre 60 et 100 ms pour la transmission des messages entre le module d’entrée et la mise à disposition de celui-ci sur la/les files de sortie JMS. Ce temps est largement acceptable dans notre cadre d’informatique de gestion.

• Disponibilité : Tout le système de gestion des événements étant contenu dans l’ESB, la disponibilité du système repose entièrement sur celle de l’ESB. Celui-ci est en configuration haute disponibilité et satisfait l’exigence de disponibilité de la plateforme.

Classé dans:Articles