Image via Wikipedia
Je profite de passer un peu de temps à aider les collègues de l’équipe produit sur le sujet des notifications dans Petals ESB qui est assez récent dans la suite Petals pour proposer un article sur une vision de haut niveau du support des notifications dans le bus de service distribué.
L’architecture et l’intégration
Je ne reviens pas ici sur l’architecture de Petals ESB basée sur JBI (il y a assez d’articles la dessus sur mon blog) mais je voudrais parler de l’architecture choisie pour fournir un support aux notifications dans Petals. Malgré tout le support JBI est important ici car cette intégration est basée sur l’aspect composants JBI de Petals. Pour rappel, un composant JBI est une sorte de plugin qui vient enrichir le container JBI en offrant des fonctionnalités supplémentaires en tant que connecteur protocolaire ou de moteur service (les fameux Binding Components et Service Engines).
L’intégration des notifications est donc exclusivement basée sur des composants JBI via des composants dédiés d’une part et via une intégration dans le Kit de Développement de Composants (CDK) développé au sein du projet.
Du point de vue des spécifications, il est choisit de fournir une implémentation des spécifications WS-Notification de chez Oasis. Une vision simpliste de cette spécification fait intervenir un broker (un intermédiaire intelligent) pour gérer et découpler les émetteurs de notifications et les destinataires. C’est sur ce broker que les émetteurs s’enregistrent, et c’est aussi sur lui que les destinataires informent qu’ils sont intéressés par uu/des types de notifications précises. Pour plus de détails, je vous recommande de jeter un coup d’oeil à la spec elle même ou à Googler le sujet.
Du point de vue de l’intégration, le broker est implémenté dans un composant JBI dédié, le petals-se-notification. Comme tout le travail se passe généralement dans les autres composants JBI, le CDK (qui est le support pour le développement des composants) propose une activation du support des notifications en tant que producteur. Cette activation implique un enregistrement envers le broker dès son démarrage. Malgré cette activation, si aucun producteur n’est enregistré au niveau du broker, il ne se passera rien! En effet, l’architecture actuelle force les consommateurs de notifications à informer le broker de leur interêt pour des notifications via un système de topics. Je passe vite la dessus mais en gros, lorsque le consommateur s’enregistre au niveau du broker, le broker va relayer cette demande avec un contexte associé aux producteurs de notifications. Une fois cette étape achevée, des échanges de messages standard provoqueront potentiellement des notifications envoyées au broker qui fera ensuite son travail de relai.
Les principaux points forts de cette intégration sont :
- la possibilité d’utiliser ce médium de notifications pour tracer les échanges entre consommateurs et fournisseurs de services standards. Ces informations peuvent alors être remontées vers une console de BAM par exemple.
- L’utilisation du canal JBI pour échanger les notifications. Pas de nouveau canal de communication à créer, tout passe par les couches de communications du bus de service. Comme Petals est un bus de service nativement distribué, cette approche est vraiment un point important.
- Le support rapide via un CDK qui fournit toute la mécanique nécessaire pour implémenter ses producteurs et consommateurs de notifications.
Cette intégration a bien sûr des points faibles. Premièrement, il faut absolument que le composant qui fait acte de broker soit présent et robuste pour pouvoir gérer les notifications venant de N fournisseurs en tant que point central. Ensuite, ce broker doit (pour le moment) être unique dans le contexte du bus. En placer un autre sur un autre noeud du bus n’est pas possible actuellement (enfin si c’est possible mais des messages seront perdus).
La suite?
De nouveaux projets sont au programme en cette fin d’année avec pour but (un des buts plutôt) d’aller vers une architecture full EDA intégrée dans le coeur du bus. Cela va normalement supprimer les points négatifs cités précédemment avec notamment la suppression des composants JBI et le développement d’un broker distribué se basant sur l’architecture distribuée de Petals. Cela fera bien sûr de la matière pour les prochains articles de ce blog courant 2011.
En attendant, un prochain article portera surement sur quelque chose de plus technique avec un peu de code, je conseille de faire tourner la démo (disponible ici) qui met en oeuvre Petals ESB, Petals View et les notifications. Elle éclaircira mes dires, car le blahblah c’est bien, passer à l’action c’est mieux!
