Alt.Net Paris session summary : "Build your own service bus" by Romain Verdier & Julien Lavigne du Cadet

Romain and Julien made a presentation/feedback about their experience in implementing their own Service Bus in ABC Arbitrage (thanks for the commodities). In addition to this summary, I encourage you to have a look at their (impressive Prezi) presentation.

They started with an overview of the context in which service bus notion is considered, reviewing some low-level concepts of MOM (Message Oriented Middleware) and giving a quick view on EAI/ESB concepts. These are the two exterme sides of the subject and set their implementation around two goals:

- add an abstraction layer to the MOM solutions, with lot of wanted conventions that help to simplify configuration, but keeping the power of these tools like interoperability, reliable message infrastructure...

- make far more simpler than EAI/ESB solutions and platform specific

Obviously, this subject is around Message driven architecture.

Next they went deeper in service bus concepts, that some solution they cited also implement. As they said, they did not invent anything.

First subject was about Message dispatching (how):

• send: a message to one conterparty waiting a response
• publish: a message to anyone who wants to pull it without any response

From these two methods, we see that there is two sorts of Message that they implements with two distinct Message concepts:

• Command that are sent -> tell someone to do something (note the imperative tense)
• Event that are published -> tell anyone wants to listen that something happened (note the passive tense)

Next, they talked about Sagas that allow to take care of long-running transactions. Their example of a trading application was judicious to understand it. Basically, it receives a "complex" trading order that will be decomposed in simpler orders (in order to accomplish the requested order without revealing the whole intention to the market...).

• A Saga is initiated by a Command or an Event
• It starts a process that send Command/publish Events
• It goes to sleep until waken by another Command or Event
• ...and it starts over, until the Saga determines it has reached its goal, then it ends.

They also quickly talked about some other (important) details like Pipelines for cross-cutting concerns, Time Service to manage Saga time out typically, Prototype Buffer for interoperable message serialization...

The main thing I would remind about implementation is the convention based aspect. It simplifies configuration (5 lines as they said) and hides some technical details, and then it allows to build the software with a bigger insight in Business value that any software should give to their users. It could be seen as a restrictive framework (just two concepts), but I truely think that it helps abstract from technical topics and focus on business value, and that these concepts are well suited to describe business goals.

Note that we did not talk about lots of related subjects like Event Sourcing, DDD...perhaps the next time :)...but we can say that Message driven architecture does not exclude other paradigms.