Service-Oriented Architecture and the Enterprise Service Bus Model

With any service-oriented solution, there is a certain challenge to configuring a setup that scales well with workload. Implementing an Enterprise Service Bus (ESB) model helps to alleviate the difficulties in doing such, by allowing any connected application to act as a service provider.

  A visual comparison of ESB
  Peer-to-peer/Bit-Torrent communications

An Enterprise Service Bus model is a model in which any of the connected applications can be assigned a server or client role, in turns, allowing for full utilisation of all connected devices for the current problem being solved.

The ESB model promotes agility and flexibility in application communication, reducing the amount of pre-configuration for a high-performance setup.

Unlike similar systems which employ peer-to-peer communication for distribution, such as bit-torrent, the Enterprise Service Bus model allows for a greater range of possible functions for each client connected to the bus. Such functions may be:

  • Message routing
  • Calculation processing
  • Request fulfilment

Effectively, the ESB architecture allows for a simple plug-and-play system when connecting additional applications to a system, utilising a simple but well-defined messaging structure to allow any connected application to make full use of the resources available.

Scalability

One of the core advantages of implementing an ESB architecture is the ability of the system to be easily scaled up. As individual nodes on the ESB do not care about what other nodes are connected to the system, very little to no configuration is required when adding additional resources or applications. Should you need to add data processing to an ESB that has already handled the data that you wished to process, it would be as simple as adding a data processing application into the existing ESB network and reading the data output to process it.

Zircon’s Use of the ESB architecture

Zircon was asked by a client to look into implementing an ESB into one of their existing products. In its current state, each device connected to the product required much configuration in order to be considered reliable, as it utilised two separate networks for redundancy. This meant that engineer time was taken up simply creating different configurations to ensure that communication between devices was seamless.

The plan was to implement an ESB system to allow the following advantages over the existing solution:

  • To allow devices to be hot-swapped in with minimal configuration, which would also allow for easier maintenance of the solution’s hardware.
  • To allow easier scaling of the solution, by adding additional hardware that could be immediately leveraged.
  • To increase the redundancy of the system by replicating stored data across multiple nodes, to prevent data-loss due to hardware failure, power failure, etc.

The ESB architecture proposed would also allow for easier future expansions to the system, as the data was already available in a known format, and older systems would not need to be updated in order to support new additions.

Summary

The Enterprise Service Bus architecture is becoming increasingly popular in solutions that need high maintainability and scalability and is a cornerstone of modern service-oriented computing solutions. Zircon has knowledge and experience of the ESB architecture, and it is now part of the multi-faceted toolbox that we use in order to provide solutions to our clients going forward.

More From The Blog

Do It Right First Time? Or, Fight The Fire Later?

Do It Right First Time? Or, Fight The Fire Later?

Do It Right First Time? Or, Fight The Fire Later?When I was a fledgling engineer, the company I worked for hired a new Technical Director.  I remember it vividly because one of his first presentations, to what was a very large engineering team, made the statement...

Standard[ised] Coding

Standard[ised] Coding

Standard[ised] CodingRecently I was handed a piece of code by a client “for my opinion”. A quick glance at the code and I was horrified! This particular piece of code was destined for a SIL0 subsystem of the safety critical embedded system that we were working on. Had...

To Optimise Or Not To Optimise …

To Optimise Or Not To Optimise …

To Optimise Or Not To Optimise ...Computers today are faster than at any time in history. For instance,  the PC on which this blog is being typed is running a multitude of applications, and yet, this concurrency barely registers as the characters peel their ways...

Test Driven Development: A Silver Bullet?

Test Driven Development: A Silver Bullet?

Test Driven Development: A Silver Bullet?Test Driven Development (TDD) is a software development process that started around the early Noughties and is attributed to Kent Beck. The basic concept with TDD is that a test is written and performed first (obviously fails)...

Ticking The Box – Effective Module Testing

Ticking The Box – Effective Module Testing

Ticking The Box - Effective Module TestingIn the world of software development one of the topics of contention is Module Testing. Some value the approach whilst others see it as worthless. These diametrical opposed views even pervade the world of Safety Critical...

Ruminations on C++11

Ruminations on C++11

This is a blog about the new version of C++, C++11. It has been many years in the making and adds lots of new features to the C++ language. Some of those features are already supported by commonly used compilers, a description of these features follows.