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!

3 réflexions sur “L’acheminement de messages dans Petals ESB : #3 Le transport

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s