Service Bus Architecture

A Sample Use Case

1. Say you have an ‘Account Creation’ Service.
2. For users who want to create a new Savings account, you offer a RESTFul Service.
3. For  folks who are applying for a loan or a mortgage account, you have an older XML/SOAP service. 

The Standard Solution

Typically, you would need a point-point connection between the client and the SOAP service – and another one between the client and the RESTFul service. This can quickly become a maintenance nightmare, as each service would require it’s own error handling, audit logs etc.

The Service Bus Solution

The service bus is introduced to allow a single point of entry for all client calls. It allows the client to simply say ‘create an account’ without having the actual point-point connections to the different account creation services. The message arrives at the service bus – which routes it to the correct account creation service.

A ‘Service Bus’ is an additional messaging layer – a ‘router’ for messages, ensuring that the right message gets to the right destination.

The client  (web service consumer) only sends a message that says – Create a new account. Where this message ends up (SOAP endpoint or RESTFul  endpoint), is the responsibility of the service bus. This removes the point-to-point connection between these services.

There are further advantages to this approach:

• Scalability – This approach scalable as it allows the same message to be transparently handled by many service instances (e.g. in a load-balanced environment);
• Single Message – Multiple Receivers – are possible through the service bus (again, because we decoupled the point to point connection). If it so happens that the use cases are combined – so that both account creations (Loan and Savings account) can happen simultaneously, you do not need to change anything, except route that message to both the services that need it.
• Audit Logs – Monitoring messaging becomes centralized. No longer do you have to review different log servers for different services.

How does an ESB differ from SOA?

• SOA is an architectural pattern where you expose  ‘services’ in a coarse (SOAP) or fine (RESTFul) grained manner. It does not prescribe any implementation details. It is a lightweight interaction between systems that speak HTTP (the most common SOA use case).
• A service bus is an actual implementation – one that relies on a ‘bus’ construct. The ‘bus’ encompasses SOA as potential endpoints (see the figure above). 

How does a service bus differ from EAI?

An ESB’s primary function is to provide the connections between communicating applications – acting much like a router to control the data.  It is commonly used in enterprise application integration (EAI), so EAI, like SOA,  is also accommodated by the ESB pattern.

How does it differ from a message broker?

It doesn’t.  An ESB is a message broker by default. However, when people talk about message brokers, they typically talk about a hub-spoke model. A ‘bus’ is slightly different – in that it has different message relaying capabilities. Most importantly, transactional messages in a ‘bus’ are hard to lose – with queuing mechanisms built-in to ensure recovery of lost messages. In addition, rollbacks are also possible from a ‘bus’. However, a hub-spoke model has a slightly lower transactional reliability and usually no rollback capability.  Different broker implementations (WebMethods, Biztalk…) may specifically introduce hub-spoke message reliability as part of their core offering.

How does NServiceBus differ from MSMQ or Kafka or RabbitMQ?

NServiceBus actually uses different transports to accomplish it’s routing tasks. MSMQ is one such transport (and  the default one for NServiceBus). However, Kafka (Apache Kafka) and RabbitMQ are other possible transports that work with NServiceBus. Once you learn NServiceBus, it is relatively easy to switch transports, if your use case demands it.

Summary

Often, people tend to use the term service bus interchangeably with message brokers, EAI and SOA. While there is overlap between ESBs and Message Brokers, that is not the case for ESBs and SOA/EAI. Certainly ESBs accommodate most SOA and most EAI architectures, but are not specifically designed to do so. Also, ESBs have typically robust transactional handling (transactional integrity) capabilities.