Azure Service Bus: The on-ramp to Azure! | Serverless360
← Return To Home

Service Bus: The on-ramp to Azure!

This blog is an extraction of the session “Service Bus: The on-ramp to Azure” presented by Ashish Chhabria, Product Manager in Azure, Service Bus at Integrate Remote 2020.

Introduction

Microsoft Azure Service Bus is a fully managed enterprise integration message broker. Service Bus can decouple applications and services. Service Bus offers a reliable and secure platform for asynchronous transfer of data and state.

In this blog, we’ll explore some of the exciting stuffs of Service Bus.

The Ideal Message Broker?

Whenever we try to build an application, we will think about functional and non-functional requirements. Below image briefly explains it.

The ideal Message Broker

Now let us do some comparison between Service bus and other MQs in the market.

  • Service bus can be integrated with Azure Security with Private link and BYOK (Bring Your Own Key) encryption in which we cannot do it with other MQs.
  • It can be integrated with other Azure Services such as Event Grid, Logic App, Functions and Monitoring where you cannot do the same with other MQs.
  • It is a fully managed PaaS and it’s very useful for business applications.
  • It provides you High Availability and disaster recovery, but you cannot expect the same behavior with other MQs.

 The only thing missing is the Stable SDKs, but it wouldn’t impact the usage of Service Bus Queues.

 Service Bus vs Other MQ's

Native Support for JMS 2.0

This is an excellent news, native support for JMS 2.0 over AMQP and this can be utilized in Service Bus Premium. It provides you the following capabilities.

  • Full Parity – Closing the gap on their JMS implementation
  • Zero *code change – Bring your existing JMS and Spring applications
  • Utilize existing EAI Connectors – popular integration connectors can connect seamlessly
  • [Bonus] Large Messages – support for message payloads up to 100 MB (for both JMS and non-JMS clients)

How did they achieve it?

They observed the Qpid project and they were able to build some sample applications that connects with Service Bus. And then,

  • They analyzed the AMQP Frames
  • They made some changes to Service side to Service Bus to respond to these AMQP frames.
  • They also introduced Service Bus specific JMS Connection factory.

Roadmap to full JSM Parity

The main aim of Service Bus is to achieve full parity. They are trying it since the start of Service Bus Queue.

40% Parity – Before June 2020

  • Connect to pre-created entities
  • No support for Temporary entities
  • No support for Subscribers
  • No support for Queue/Topic Browsers

80% Parity – Public Preview June 2020

  • Auto Create entities over AMQP.
    • Queues/Topics
    • Temporary Queues/Topics
  • Client-Affine Subscriptions (scoped to a “client-id”)
    • Shared/Unshared durable Subscriptions.
    • Shared/Unshared non-durable Subscriptions
  • Message Selectors
  • Delivery Delay (scheduled messages)
  • Queue and Topic Browsers (Peek)

Full Parity – GA and Beyond

  • Durable terminus (link recovery)
  • “NoLocal” features for subscribers
  • RBAC support for JMS clients

How can you use it?

This is just going to be straight forward. Let’s say you have an existing java or spring application; you can just import azure-servicebus-jms and provide the respective Service Bus Configuration and that’s it the magic occurs.

 How to Use

Here comes the demo with some Realtime example.

Demo Application

The scenario is very simple. Whenever the user places an order, the request goes to the respective ‘order request topic’ which then goes to subscription with address selector, based upon the city the store manager accepts the order. Once it is accepted, the responses will be sent over to the response queue which will update the status of the order.

He ran this demo with Active MQs and later he replaced the same with Service Bus. The difference after replacing with Service bus are the entities will be created on the fly, so it is automatically created over AMQP. And this functionality is achieved with a minimal code change.

Modernization begins with Azure Service Bus

Basically, Service Bus targets two scenarios, lift and shift or Modernize. But now they are thinking to make it as both modernize as well as lift and shift.

 Lift Shift and Modernize

Let’s say we have on premises stuffs such as compute, storage, database and message brokers. When we go onto the cloud it can be replaced with IaaS/PaaS Compute, IaaS/PaaS Storage, PaaS Database and PaaS Message Brokers respectively. And they recommend Service bus as their top cloud message broker.

Below are some the key differences between Service Bus and other MQ’s regarding the Deployments & Disaster recovery and Usage & Management.

Service Bus vs Other MQ's - General

Spring Azure is getting bigger and better and below are some of the interesting stuffs which you can take into notice.

Spring Azure

More Updates on Service Bus

The following are some more updates on Azure Service Bus.

  • Service Bus Explorer on the Azure Portal – Preview now available for all namespaces
  • Bring your own key (BYOK) encryption – Native integration with Azure Key Vault to encrypt your data with your key
  • Private Endpoints – Service bus in the cloud, through a local endpoint

Conclusion

In this blog we explored about some of the interesting updates on Azure Service Bus. The main key takeaways are,

  • Native Support for JMS 2.0
  • Trying to achieve Full Parity
  • Azure-servicebus-jms maven package which can be used in your respective spring or java application to do the magic.

Service Bus is becoming more powerful day by day and once it achieves its full parity, it is going to be one of the most performant message broker.