Petit résumé de la rencontre Alt.net Paris « Build your own service bus »

Posté par Mathias Kluba dans Comptes Rendus Paris | No responses yet

Pour ceux qui n’ont pas pu assister à la présentation « Build your own service bus », vous pouvez consulter la présentation en ligne ici:

Le format de présentation « Prezi » a vraiment eu le « Wow effect ». Je pense même que le fait d’imbriquer et regrouper les termes en fonction de leur catégorie et leur niveau de détail, rend cette présentation très compréhensible, même si elle est dépourvue de phrases ou de la piste son.

Mais pour vous aider à mieux la comprendre, voici un petit résumé de ce que j’en ai compris.

Act I.

Je ne sais pas si le « messaging » est quelque chose à la mode en ce moment, mais il est nécessaire pour une architecture asynchrone et distribuée.
C’est aussi peut-être pour cela qu’on en parle beaucoup en ce moment, puisque la « mode » du cloud nous pousse à réaliser une architecture distribuée, mettant en œuvre de nombreux services différents, et offrant de la « scalabilité » à la demande.

Chez ABC Arbitrage, le besoin est avant tout de découpler les systèmes, mais aussi de traiter un gros volume de données avec la possibilité de « scaler » au besoin.

Romain et Julien ont commencé à expliquer que le but de cette présentation n’est pas de vous convaincre d’utiliser le messaging, ni de vous vendre une solution en particulier, ni même de vous convaincre de re-inventer un ServiceBus comme ils l’ont fait.

Mais cette présentation est une bonne base sur la théorie des ServiceBus afin de vous permettre de mieux comprendre ceux existants, ou de connaitre les fondamentaux afin de réaliser le votre.

Au départ, ils nous ont expliqué brièvement ce qu’est le Messaging, ce qu’est un ServiceBus, et la différence qu’il y a avec les technologies de Messaging (bas niveau), les ESB et les EAI (très haut niveau).

Si vous cherchez « service bus » sur codeplex, vous en trouverez plein. Peut-être qu’il s’y cache une petite merveille, mais elle n’a pas percé pour le moment.
Parmi les plus « matures » et les plus connues, il y a:

• NServiceBus
• Masstransit
• Rhino ESB

S’ils sont venus à la conclusion d’inventer leur propre ServiceBus, c’est que ceux existants ne répondaient pas à leurs contraintes.

Le besoin de nos 2 acolytes était d’avoir quelque chose de simple, et qui ne dépendait pas d’une technologie de messaging en particulier (NServiceBus et Rhino ESB sont seulement compatible MSMQ « out of the box »).
D’ailleurs, aillant besoin de traiter des données en C++ sur des machines Linux, ils ont choisi la technologie Apache Qpid.
Ils ont alors développé un ServiceBus avec leur strict nécessaire en terme de fonctionnalité, avec une API nécessitant le moins de configuration possible (convention over configuration), avec une implémentation C# et une autre C++.

Act II.

C’est alors qu’on est entré dans le vif du sujet, et qu’ils ont commencé à nous expliquer plus en détails ce qui compose un ServiceBus, et comment est-ce qu’ils l’ont implémenté.

Les messages

Tout d’abord nous avons vu ce qu’est un Message, quels sont les types de messages possibles, de quoi est-ce qu’il est composé, etc.
Ils distinguent 2 catégories de messages:

• Les Commandes: Elles expriment une intention adressée à un destinataire unique qui se chargera de confirmer l’exécution, ce qui permet de simuler un appel « synchrone » comme en RPC
• Les Evénements: Ils informent 0 à n systèmes que quelque chose s’est passé (ou non !), sans attendre une quelconque confirmation de lecture.

Puis nous avons vu ce qui compose le message:

• un contrat
• une enveloppe
• une donnée sérialisée

Il existe de très nombreuses façons de sérialiser vos données, mais pour des raisons d’interopérabilité avec le C++, et de performances, le format « Protocol Buffers » a été choisi.

L’enveloppe quant à elle va contenir toute les méta-données spécifiques au Messaging, à savoir des adresses de destination, des informations de routing, etc.

Ceux qui les consomment: les MessageHandlers

Le chapitre suivant traite des « Handlers », c’est à dire, les composants du systèmes qui traitent les messages.
On voit donc ici rapidement comment déclencher un traitement à la réception d’un type de message donné.
Tout ceci avec une grande simplicité à l’aide des conventions.

Mais avant que le message soit envoyé/reçu, il peut être traité et enrichi dans la « Pipeline ».
C’est un peu comme de l’AOP, ou on va pouvoir traiter les aspects techniques transverses, spécifiques au Messaging, et donc enrichir l’entête du message ou d’effectuer un traitement particulier en fonction de celui-ci.
C’est alors qu’on peut choisir de chronométrer le temps de traitement d’un message, de le filtrer, ou de le router vers la bonne destination.

Les traitements long avec état: les Sagas

Cette dernière partie de la présentation traite du sujet sans doute le plus complexe, mais surtout le plus intéressant.
C’est en effet ici qu’on nous a expliqué comment effectuer des traitements avec état, de dérouler un Workflow en orchestrant l’envoi et la réception de certains messages.
La Saga est donc un Handler particulier qui effectue cela, et elle doit donc être créée suite à un message de début de traitement, et persisté afin de reprendre son traitement là ou elle en était suite à la réception d’autres messages.
Cela veut dire aussi que les messages sont alors identifiés à l’aide d’un « Correlation ID », afin de savoir quelle instance du Workflow faut-il reprendre.

Cela pose aussi d’autres problèmes, puisqu’il se peut que la Saga envoie une « Commande » pour effectuer un traitement, mais ce dernier pouvant échouer, la Saga ne recevra jamais de message de retour.
Il faut alors gérer les « Timeouts », pour passer le Workflow état « terminé ».

Cela est très bien expliqué dans la présentation, avec de magnifiques diagrammes de séquences.

Démo

Pour terminer, nous avions eu droit à une superbe démo d’une application de trading (WPF?) avec une courbe de prix d’une action (fictive) en temps réel.
Dans la démonstration, nous pouvions effectuer un achat d’un certain nombre d’actions à un prix désiré, l’application publie alors l’ordre dans le système, qui va effectuer l’achat si l’offre correspondante est trouvée.
On peut alors y voir une Saga qui s’occupe d’effectuer les achats par « paquet » afin de ne pas faire trop grimper le cour de l’action. Si le prix désiré n’est pas trouvé au bout d’un certain temps, et qu’il n’a pas été possible d’acheter le nombre d’actions voulu, nous avons alors la un bel exemple de gestion du Timeout.

Conclusion

Ma conclusion personnelle est que le Messaging est vraiment nécessaire aujourd’hui, car nous sommes de plus en plus dans des contextes distribués.
Réaliser un ServiceBus n’est pas si simple: il y a beaucoup de concepts, et même ABC Arbitrage a fait le choix de ne pas tous les implémenter.
Mais la complexité des certaines solutions existantes, et l’immaturité des autres, nous poussent souvent à la même conclusion: « Build your own Service Bus ».

Sans forcement vouloir inventer la solution parfaite, c’est en tout cas un très bon exercice, cela nous permet d’en apprendre plus sur le sujet, et nous préparer ainsi à des solutions plus complexes.

J’espère que cette petite présentation vous a plu, et que ça vous a encourager à assister à nos futures sessions d’ALT.Net !

Pour terminer, voici quelques liens utiles (en plus de ceux déjà présent dans l’article):

• http://blog.phatboyg.com/ le blog du créateur de Masstransit, aussi membre d’ALT.Net
• http://www.udidahan.com/ bien évidement le blog d’Udi Dahan, créateur de NServiceBus
• http://ayende.com/Blog/category/554.aspx le Blog d’Ayende autour de Rhino ESB. Très intéressant puisqu’il décortique NServiceBus et MassTransit afin de réaliser le sien
• http://distributedpodcast.com/ Si vous avez besoin de comprendre le Messaging et le ServiceBus, je vous conseil absolument d’écouter ces podcasts