Enterprise Service Bus (ESB)

Session Conveyer: Ray Houston

Ray opened the session and asked the following question to the people attending

“Why would you need an ESB?”

At first the answers where focusing on scalability and the database (access) and how it is possible to scale up or out. It was said that to scale one doesn’t necessarily need an ESB but that this can be solved by the database alone. But then Ray pointed out that this is not about databases. He is looking at an application where the database is not the centerpiece but (only) one element of the whole solution.

Some of the different answers were

• When one needs better scalability
• We want to segregate the database access
• To better support command-query-separation (CQS)
• Usage of an ESB can help to further decouple the solution and make it more flexible
• To facilitate deployment and make it more flexible. That is when having an application which is split up in different (bound) contexts with clearly defined boundaries it is easier to upgrade only a part of the application (e.g. one bound context) instead of upgrading the whole solution
• Big monolithic applications tend to have one single generic model with its own specific problems

It was then asked what are the key characteristics of an ESB

An ESB is a communication channel between loosely coupled applications or application services. It provides a reliable, scalable, durable message exchange infrastructure. Messages are queued and can be replayed in case of failure of the transmission or the failure of a subscriber. The messages are queued if the subscriber (temporarly) is not available.

Ray then asked how the initial data population of decoupled systems having their individual data store is normally implemented.

The first answer was that the initial setup should be an ETL process (extract-transform-load). Depending on the specific context it has to be decided what data is to be included in the initial load. Not always all (historical) data is needed.

Another method of re-creating data is to use Event Sourcing (see Fowler). There all messages which are ever produced by the system are recorded and stored (e.g. as a BLOB) and can then be replayed (via ESB) to bring a system from a well known state A into another state B.

Another possibility would be to create an adapter which allows us to publish the content of any database table to the ESB. But it was then remarked that this kind of solution should be rather avoided.

Each system has its own isolated storage. The update of disparate systems is not in real-time. Things happen as they happen…

Is it an anti-pattern to share message objects in different bound contexts?

Each bound context should be able to reconstruct messages without having access to the same types as the publisher. A sound contract must be established between the involved parties. Part of the contract is the schema of the messages. If the serialization format is XML then anybody can de-serialize messages.

There are currently three well known OSS ESBs. These are

• NServiceBus (Udi Dahan)
• MassTransit (Dru Sellers and Chris Patterson)
• Rhino Service Bus (RSB) (Oren Eini)

NServiceBus seems to be the most mature product with a broad installation base and rather good documentation. MassTransit on the other hand has some andvantages in that is not tied to a specific IoC container. There exist adapters for all the major IoC containers. It’s easy to implement a customized adapter. Further on MassTransit offers a “Fluent Interface” for the configuration of the system. MassTransit can be used with different message queuing systems like MSMQ and ActiveMQ.

Rhino Service Bus is a very lightweight implementation of a service bus. One of the main targets of the author was to minimize the necessary configuration and setup to the max. Convention over configuration.

It is important to clearly distinguish Message Broker systems like MS Biztalk Server from ESBs. An ESB has no single point dependency. Although normally there is a central subscription manager which is responsible for registering all messages a publisher publishes and register all subscribers of certain messages, once the registration is established the system can operate even if the registration manager is down.