Azure Service Bus

Overview
What is Azure Bus?
Azure Service Bus communication options
What is a Queue?
Implementing Queue in Service Bus
Monitoring Queues in Service Bus

Overview

Today when you write an application, your application needs data. This data can be from some backend system or from some external source. This backend system can be other applications or services. Also, the communication pattern has changed. Applications are no longer limited with simple request-response patterns and need more robust message exchange patterns, triggered by multiple events. This gives rise to a question of the type of communication method you use for your application. The traditional method is not enough and hence an advanced “Messaging System” is needed. Also, your application needs some sort of infrastructure which is difficult to maintain and ensure available. Here is when Azure PaaS computing model of Service Bus comes into the picture.

Need for Service Bus Architectural Pattern

Traditionally a business requirement is addressed as a separate process and usually, you will find duplication of functionality at some stage. As in the example above, considering an application that has an Email, Calendar and Play Store functionality each is storing login and user details separately. This will create a lot of complexity and inefficiency. Login and User details will have to be synchronized every time for any changes. Also, a user will have to create separate accounts for each process and will have to remember the same for access.

To fix the issue, the approach is to identify the common tasks and implement them by decoupling the functionality from each process and build a separate standalone application for authentication and user details.

As you can see in the figure above, the shared task for maintaining account related information is separated from the individual processes and is implemented as a service. This Asynchronous messaging scenario called, “Message Bus” is more efficient and highly scalable. It is defined as:

“A Message Bus is a combination of a common data model, a common command set, and a messaging infrastructure to allow different systems to communicate through a shared set of interfaces”

– Enterprise Integration Patterns

What is Azure Service Bus?

Azure Service Bus messaging is a reliable system to deliver information. It is flexible enough such that your applications or services may interact with each other either it be running in the cloud or on-premises. Azure Service Bus is also a multi-tenant messaging system i.e. a single service is shared across by multiple users. There are multiple communications options in Service Bus like Queues, Topics, Relays and Event Hub. You may use one or all four types of communication option depending on the type of application you are designing.

Azure Bus communication options

As mentioned earlier, there are four different messaging options available in Azure. Below is a brief description of each of them.

1. Queues

   1. Messages are Ordered (i.e. First In, First Out (FIFO))
      1. Ordered at arrival (broker assigns strongly monotonic sequence number to each msg)
      2. Time stamped on arrival (authoritative clock)
      3. Stored in SQL; once accepted, the message is as safe as any data in the SQL deployment
      4. Multiplexing with sessions
   2. Two models: Pull and Forward
      1. Pull – delivers messages on request, allowing concurrent readers
      2. Forward – delivers messages to single forward destination
   3. Poison Message Detection
   4. Dead Letter Queues
   5. Queue forwarding

2. Topics

   1. All features of Queues, plus
   2. Multiple, Independent Subscriptions
      1. Named, durably created (optional)
         1. Quota: Up to 2000 concurrent subscriptions
         2. Reco is to start partitioning much, much earlier
      2. Rules with filter conditions on msg headers
         1. Quota: Up to 2000 rules per subscription
         2. Optional action set/modify message props
         3. Each rule hit yields a message
   3. Topic ‘tail’ and subscription ‘head’ are fully protocol compatible with Queues

3. Relays

   1. Relays support bi-directional communication
   2. No ports required, used outbound connection
   3. WCF bindings
      1. No libraries for non-Windows application
   4. On demand creates relay
      1. Relay deleted when connection is dropped

4. Event Hubs

   1. Large-scale data intake
   2. Used for applications require High throughput and Event processing
   3. Partitioned ordered sequence
      1. Data is retained in partitions
      2. Events cannot be deleted, removed as per retention policy
      3. 4 partitions by default can be from 2 to 32 partitions

What is a Queue?

Imagine you walk into a mall and after your shopping, you go towards the checkout counters. At the counter, you find other customers waiting in a “queue” for their turn to be addressed by the cashier. The first customer in the queue is addressed first by the cashier. The concept is the same in the Service Bus queue. A sender sends a message to the Service Bus queue and the receiver addresses the message.

Delivery Options

1. Receive and Delete
   1. Fastest. Message lost if receiver crashes or transmission fails.
2. Peek Lock
   1. The message is locked when retrieved. Reappears on broker when not deleted within lock timeout.
3. Session + Peek lock
   1. The message is locked along with all subsequent messages with a same session-id ensuring order.

Message Model

1. Brokered messaging properties are not SOAP headers
2. System properties have special meaning to the broker or set by the broker
3. Properties are key/value pairs that may very well carry payloads
4. It’s not uncommon to have messages with empty message bodies
5. Message bodies are useful for a single opaque payload not exposed to the broker (e.g. encrypted content)

Implementing Queue in Service Bus

More about implementing Queues in Service Bus

Monitoring Queues in Azure Bus

More about monitoring Queues in Service Bus

Learn more about Netreo.