Le support de WS-notification* dans Petals ESB


Petals ESB

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 :

  1. 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.
  2. 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.
  3. 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!

Publicités

SOA4All Meeting @ Milan


Un article pas technique du tout (ou presque, enfin il n’y a pas de code), ca change un peu… Je suis de retour de Milan où j’ai passé quelque jours pour une réunion de travail (et à manger pâtes et pizzas…) sur le projet  SOA4All que je leade chez PetalsLink (pour ceux qui n’auraient pas encore compris..).

C’est la dernière ligne droite puisque le projet est dans sa dernière année (bien entamée), et il reste encore des choses intéressantes à faire. La plus ambitieuse est surement l’intégration finale de OW2 Petals ESB et de OW2 Proactive pour créer un Bus de Service Distribué et Fédéré via un Framework de fédération maison.
Un article sur les concepts de la fédération est disponible au téléchargement. Les premiers tests de déploiement sur le Cloud pour créer une fédération sur Internet entre différents providers (Amazon EC2, Grid5000, …) et de performance nous permettent d’être assez satisfait du prototype actuel.

Mais comme on est jamais assez satisfaits, la suite réserve encore et surement beaucoup de bonnes choses que ce soit pour SOA4All ou pour les projets de recherche a venir.

Petit tour sur le toit de la cathédrale - Duomo

Petit tour sur le toit de la cathédrale - Duomo

Petals ESB over XMPP #2


Dans l’article précédent, je parlais de l’utilisation de XMPP et de Google Talk pour faire communiquer des instances de Petals ESB. L’utilisation était seulement faite au niveau de la couche de transport de Petals (cf cet article sur la couche de transport) et ne couvrait donc pas tous les canaux de communication qui entrent en jeu (et en particulier ceux du registre de services).
Dans la continuité de mes travaux sur la fédération de bus de service, je me suis donc intéressé à la possibilité de faire communiquer des domaines distincts (un domaine étant un ensemble de noeuds au sein d’une institution par exemple) en utilisant XMPP non pas seulement pour la couche de transport mais aussi pour les communications du registre de service.

En pratique, les domaines sont complètement indépendants, ils ne sont aucunement connectés via Internet ou toute autre connection alternative. Dans cette première itération sur la fédération, il n’y a pas de notion de hierarchie en domaine et sous domaine. Un noeud d’un domaine peut demander à la fédération une résolution de endpoint et aussi envoyer un message à des endpoints de la fédération pour invoquer des services. Une vue de haut niveau sur deux noeuds dans deux domaines différents est la suivante :

Techniquement, l’intégration de la fédération intervient à plusieurs niveaux :

  1. Chaque noeud implémente le service de fédération qui permet de donner un point d’entrée à la fédération. Ce service expose une opération de recherche de endpoint et une opération d’invocation de service.
  2. Chaque noeud s’enregistre dans la fédération en donnant un callback (ici c’est le point d’accès au service exposé en 1 qui est publié dans la fédération).
  3. Un module de fédération permet de faire une recherche de endpoint dans la fédération. Dans le cas de Petals, c’est un module du routeur (cf cet article sur les modules) qui permet de faire cette recherche.
  4. Une implémentation au niveau fédération de la couche de transport permet d’aller invoquer un service de la fédération.

Une première approche simple (et pas forcément efficace) est de laisser le module de routage faire une requête à la fédération à chaque invocation pour trouver une liste de endpoints qui peut répondre à la requête, une version plus évoluée permettrait d’avoir un cache à un niveau intermédiaire (pas si évident en fait dans une approche très dynamique). A voir…

En attendant, un premier prototype permets de faire communiquer des noeuds appartenant à des domaines différents sans que ceux ci est une connaissance des autres noeuds (au niveau de Petals ESB, les noeuds des domaines ne sont pas renseignés au niveau du service de topologie). La vidéo qui suit montre deux noeuds, un sur mon laptop et un autre sur un serveur OVH. Je n’ai ouvert aucun port sur ma Box, sur mon laptop ou sur le serveur pour faire passer du trafic supplémentaire : C’est un des avantages à utiliser XMPP.
Le scénario est simple, un client sur mon laptop veut invoquer un service qui fournit une interface X. Cette interface X n’est fournie par aucun service localement (d’ailleurs on voit bien qu’il n’y a pas de endpoint sur le container coté client). Et la magie, il existe un endpoint dans la fédération qui fournit cette interface et il se trouve que cet endpoint est sur le container tournant sur le serveur OVH.
Et alors? Ca a l’air bête comme çà mais on arrive quand même à récupérer la référence du endpoint distant et à invoquer le service sans avoir besoin d’ouvrir quoi que ce soit, de faire du polling ou autre. Merci XMPP.
Comment? Pour dire simple, chaque noeud se connecte sur un serveur XMPP. En pratique c’est un peu plus compliqué et je laisse ca pour un prochain article!

Communication de noeuds Petals via XMPP


Dans le cadre de mes travaux de recherche sur la fédération de Bus de Service (et en particulier de Petals ESB dans un premier temps), je suis en train d’étudier la fédération via Jabber/XMPP. L’approche la plus rapide sans avoir l’utilité de monter un serveur Jabber est d’utiliser GoogleTalk comme support et ainsi profiter aussi de l’infrastructure de Google et de sa robustesse.

Les premiers tests n’ont rien a voir avec la fédération mais valident que l’on peut utiliser une couche de transport générique que j’ai développé (et que je détaillerais dans un futur article) pour rapidement implémenter un transport utilisant le protocole désiré, ici XMPP. Le schéma suivant donne une vision de haut niveau de cette architecture et du cas d’usage :

Description du scénario ci dessus:

  • Chaque noeud est connecté à GTalk avec un compte dédié
  • Un service est lié à Petals ESB, disons que c’est un Web service bindé avec le composant SOAP (Proxy Out)
  • L’endpoint ainsi présent dans Petals ESB est exposé sous forme de Web service par le composant SOAP sur l’autre container (Proxy In)
  • Tout client envoyant une requête au service via le Proxy In voit sa requête traverser les différentes couches de Petals jusqu’à arriver à la couche de transport. La communication avec le container cible se fait grâce à la notion de Chat de Jabber. Un Chat est créé entre le container 1 et le container 2 et le message contenant la requête est alors publié au container 2 via le Chat.
  • Le container 2 reçoit le message et le fait remonter jusqu’au service final. La réponse prends le chemin inverse.

On profite aussi de l’archivage des communications Gtalk :

Evidemment, passer par GTalk pour invoquer des services d’un même domaine est pénalisant et l’intérêt est assez limitée car la communication entre les noeuds ne se fait pas uniquement via la couche de transport (la recherche de endpoints passe par un canal différent par exemple). Et c’est la que la fédération du Bus va entrer en jeu. La suite donc au prochain numéro.

L’acheminement de messages dans Petals ESB : #3 Le transport


L’intro

Dans le précédent article de la série, j’ai présenté globalement les concepts de routage de message et comment la couche de routage de Petals ESB pouvait être étendue à moindre frais. Aujourd’hui, nous allons regarder de plus prêt pourquoi Petals est vraiment un Bus de Service Distribué avec un grand ‘D’ depuis qu’il est arrivé sur le marché des ESBs Open Source.

Blablabla et bla!

Dans l’article précédent, nous avons vu que la couche de routage était traversée par le message et que en sortie, nous obtenions toutes les informations nécessaires sur les endpoints et sur le contexte du message. Comment maintenant envoyer ce message au bon endpoint? Rien de pus simple, en effet, chaque endpoint contient les informations sur le service, son interface mais aussi sa localisation. Dans les données de localisation, le domaine, le nom du container et le nom du composant destinataire attachés au endpoint sont présentes. Rien de plus simple alors pour la couche de transport, il suffit de :

  • En fonction du nom de container, il est possible de retrouver les informations sur ce container en invoquant le service de topologie. Ce service de topologie est capable de retourner la liste des informations nécessaires pour contacter une instance distante.
  • Créer un client vers le container distant en fonction du protocole de transport
  • Envoyer le message et attendre une réponse si besoin. Si une réponse est retournée, celle ci est encapsulée dans le message d’origine et le message repart en direction de la couche de routage. La couche de routage peut donc effectuer des opérations sur la réponse en fonction de modules de routage présents. Le message est finalement adressé au consommateur de service.

Et alors?

Et alors, contrairement aux autres ESB JBI du marché, il n’est pas nécéssaire d’utiliser des Binding Components et de les configurer pour invoquer des services distants. Un exemple de ce que cela implique est donné dans cet article sur DeveloperWorks. Avec Petals, on a ce que l’on appelle une vision unifiée du bus de service qui est distribué.

C’est tout?

Techniquement, Il y a eu beaucoup de tentatives pour implémenter un transporteur de messages digne de ce nom. Dans Petals V1, on avait un transport JMS basé sur OW2-Joram. Dans Petals V2, c’était un projet OW2 mort appelé Dream qui servait de couche de transport. Aujourd’hui dans la v3, le transport est assuré par une implémentation maison basée sur NIO très performante.
La performance c’est bien mais moi je préfère l’extensibilité. C’est pourquoi je proposerais bientôt une alternative à la couche de transport actuelle. Cette couche est très bien quand on se place au niveau de l’entreprise (le ‘E’ de ESB). Actuellement je travaille sur des sujets intéressants ou je remplacerais le ‘E’ par un ‘I’ pour Internet et même par ‘FD’ pour ‘Federated Distributed’. Quand on parle d’Internet, on imagine facilement que l’on doit se confronter aux Firewalls, à échanger les messages sur HTTP, en XML avec des notions de présence etc etc… La suite bientôt!