Parallels between Enterprise Service Bus (ESB) and Azure Service Bus (ASB)

The goal of the following post is to compare the Enterprise Service Bus to a cloud messaging services such as Azure Service Bus (ASB).

Application Messaging in the Cloud

One of the most common requirements of a cloud-based application is to have the ability to interact and communicate with other applications and services. Whereas some cloud applications can achieve their goals with a simple messaging queue, the more sophisticated applications often need complex ways to communicate. Nevertheless, a simple queueing mechanism or a complex messaging implementation, the messaging service is the core cloud service, not that different from the traditional way messaging is implemented in the service-oriented architecture (SOA).

 

Enterprise Service Bus (ESB)

The Enterprise Service Bus became the most recognized standard for enterprise SOA–based applications.

“An Enterprise Service Bus is an open standard, message-based, distributed integration infrastructure that provides routing, invocation, and mediation services to facilitate the interactions of disparate distributed applications and services in a secure and reliable manner.” (Menge, 2007, p.2).

Figure 1 shows the main components of the ESB, depicting a simple container scenario. As we can see, the containers host the application adapters whose purpose is to connect the application to a bus and in such way simplify communication between other applications that may use a variety of web service technologies.

Figure 1 – Enterprise service bus – (Menge, 2007)

 

Microsoft Azure Service Bus (ASB)

The messaging service can be realized in many different ways.

“The SOA-based Enterprise Service Bus has a number of open-source and proprietary implementations. The Azure Service Bus is simply a cloud-based messaging service implementation by Azure.” (CCENG, 2017).

Microsoft Azure Service Bus is the technology that provides messaging, queuing, notification and connectivity capabilities in the service-oriented Azure cloud architecture. Its aim is to take the edge out of the complex task of communication in the cloud, while also making the service simple and available. Important to mention, that ASB can be consumed not only by the cloud applications but also those that reside outside the cloud. Microsoft touches on this in one of their statements: “Even though Service Bus itself runs in the cloud (that is, in Microsoft’s Azure data centers), applications that use it can run anywhere.” (Docs.microsoft.com, 2017).

As far as the cloud-bases communication in Azure Service Bus, it happens primarily with the help of three different types of communication:

  • Queues
  • Topics
  • Relays

The ASB architecture is depicted in Figure 2, which shows that the ASB end customer simply creates the namespaces and defines the type of communication that is going to be required for the application communication.

https://docs.microsoft.com/en-us/azure/service-bus-messaging/media/service-bus-fundamentals-hybrid-solutions/svcbus_01_architecture.png

Figure 2 – Overview of Azure Service Bus fundamentals – (Docs.microsoft.com, 2017).

The main purpose of Queues is to enable one-directional communication, in which each queue serves the role of a broker that lines all messages into a queue and keeps them until they are delivered to a recipient. Another form of one-directional communication is Topics. The main difference between topics and queues lies in the fact that topics allow many subscriptions and offer an option to filter messages based on the required delivery criteria. The third form of communications are Relays, which allows messages to pass bi-directionally. Relays differ from queues and topics primarily by not storing any of the messages, essentially acting as a pass-through to the destination application.

Pros and Cons

In my opinion, the main disadvantage of both ESB and ASB is the service bus architecture itself, which could present a single point of failure for all its customers.

“Since everything is talking to everything else through the ESB, consequences may be far reaching.” (Stackoverflow, 2017).

That said, Azure Service Bus has an advantage in easier (often visual) troubleshooting and monitoring, which somewhat alleviates this major problem of ESB.

 

 

References

Docs.microsoft.com. (2017). Overview of Azure Service Bus fundamentals. [online] Available at: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-fundamentals-hybrid-solutions [Accessed 25 Jun. 2017].

CCENG (2017). Cloud Computing Fundamentals and Cloud-Based Services Engineering. [online] Available at: https://elearning.uol.ohecampus.com/bbcswebdav/institution/UKL1/201760JUN/MS_CKIT/CKIT_523/readings/UKL1_CKIT_523_Week04_LectureNotes.pdf [Accessed 24 Jun. 2017].

Menge, F. (2007). Enterprise service bus. In Free and open source software conference (Vol. 2, pp. 1-6).

Stackoverflow (2017). Service Bus Architecture Pros and Cons. [online] Stackoverflow.com. Available at: https://stackoverflow.com/questions/4678568/servicebus-architecture-pros-and-cons [Accessed 25 Jun. 2017].

Facebook Comments