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.

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.

Use of the ESB

⇑ Fig 1: A visual comparison of ESB (left) and Peer-to-peer/Bit-Torrent communications (right)

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.


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.


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.