Develop message-based solutions in Azure

Last Updated on December 13, 2020 by

Develop message-based solutions is part of Connect to and consume Azure services and third-party services topics. The total weight of this in the exam will be 25-30%. This training post is designed to help and provide readers with a better understanding of the topic mentioned.

Disclaimer: This is not a training article to help complete the Microsoft Azure AZ-204, but it provides a good insight into the areas within these topics. Labs and hands-on work are essential to passing most Microsoft Azure exams.

Develop message-based solutions:
implement solutions that use Azure Service Bus

Develop message-based solutions:

Azure Service Bus

Azure Service Bus is a fully managed enterprise integration message broker. Service Bus is most commonly used to decouple applications and services from each other and is a reliable and secure platform for asynchronous data and state transfer. Data is transferred between different applications and services by using messages. A message is in binary format, which can contain JSON, XML, or just text.

A namespace is a scoping container for all messaging components. Multiple queues and topics can reside within a single namespace, and namespaces often serve as application containers.

Some common messaging scenarios are:

  • Messaging: transfer business data, such as sales or purchase orders, journals, or inventory movements.
  • Decouple applications: improve reliability and scalability of applications and services (client and service do not have to be online at the same time).
  • Topicsandsubscriptions: enable 1:n relationships between publishers and subscribers.
  • Massage sessions: implement workflows that require message ordering or message deferral.

Comparing cloud messaging options

RequirementSimple queuingEventing and PubSubBig data streamingEnterprise messaging
ProductQueue storageEvent GridEvent HubsService Bus
Supported advantages•Communication within an app •Individual message •Queue semantics / polling buffer •Simple and easy to use •Pay as you go•Communication between apps / orgs •Individual message •Push semantics •Filtering and routing •Pay as you go •Fan out•Many messages in a Stream (think in MBs) •Ease of use and operation •Low cost •Fan in •Strict ordering •Works with other tools•Instantaneous consistency •Strict ordering •Java Messaging Service •Non-repudiation and security •Geo-replication and availability •Rich features (such as deduplication and scheduling)
Weaknesses•Ordering of messaging •Instantaneous consistency•Ordering of messaging •Instantaneous consistency•Server-side cursor •Only once•Cost •Simplicity
TypeServerlessServerlessBig dataEnterprise
Each of the messaging services that are used in the cloud have distinct use cases.


  • žMessages are sent to and received from queues
  • žEnables you to store messages until the receiving application is available to receive and process them
  • žSupports a brokered messaging communication model ž
  • A general-purpose technology that can be used for a wide variety of scenarios

Queue-based load leveling

Use a queue that acts as a buffer between a task and a service it invokes, to smooth intermittent heavy loads that can cause the service to fail or the task to time out. This can help to minimize the impact of peaks in demand on availability and responsiveness for both the task and the service.

Refactor the solution and introduce a queue between the task and the service. The task and the service run asynchronously. The task posts a message containing the data required by the service to a queue. The queue acts as a buffer, storing the message until it’s retrieved by the service. The service retrieves the messages from the queue and processes them. Requests from a number of tasks, which can be generated at a highly variable rate, can be passed to the service through the same message queue. This figure shows using a queue to level the load on a service.

Topics and subscriptions

žImplements publish/subscribe (pub-sub) model

  • žReceivers subscribe to a topic, and they can even filter down by interest ž
  • A sender publishes messages to the topic ž
  • Asynchronously, receivers get their own copy of the message ž

Subscriptions are independent, which allows for many independent “taps” into a message stream

In contrast to queues, in which each message is processed by a single consumer, topics and subscriptions provide a one-to-many form of communication, in a publish/subscribe pattern.

Messages, payloads, and serialization

žMessages carry multiple things

  • žMetadata about the message itself (in key-value pairs)
  • žPredefined Broker properties ž
  • The message binary payload ž

Message payload is not visible to Service Bus at any point

  • žSerializes as opaque, binary content ž
  • Can be deserialized by using client SDK libraries ž
  • Gives you the flexibility to explicitly define how you want to serialize content

Messages carry a payload and metadata, in the form of key-value pair properties, describing the payload and giving handling instructions to Service Bus and applications. Occasionally, that metadata alone is sufficient to carry the information that the sender wants to communicate to receivers, and the payload remains empty.

The object model of the official Service Bus clients for .NET and Java reflect the abstract Service Bus message structure, which is mapped to and from the wire protocols Service Bus supports.

A Service Bus message consists of a binary payload section that Service Bus never handles in any form on the service side, and two sets of properties. The broker properties are predefined by the system. These predefined properties either control message-level functionality inside the broker or map to common and standardized metadata items. The user properties are a collection of key-value pairs that can be defined and set by the application.

Develop message-based solutions:
implement solutions that use Azure Queue Storage queues

Develop message-based solutions:

Azure Queue storage

Azure Queue storage is a service for storing large numbers of messages that can be accessed from anywhere in the world via authenticated calls using HTTP or HTTPS. A single queue message can be up to 64 kilobytes (KB) in size, and a queue can contain millions of messages, up to the total capacity limit of a storage account.


The Queue service contains the following components:

URL format

Queues are addressable by using the following URL format:

The following URL addresses a queue in the diagram:

Storage account

All access to Azure Storage is done through a storage account.


A queue contains a set of messages. All messages must be in a queue. Note that the queue name must be all lowercase.


A message, in any format, of up to 64 KB. The maximum time that a message can remain in the queue is seven days.

Code examples – create and get messages

To insert a message into an existing queue, first create a new CloudQueueMessage. Next, call the AddMessage method. A CloudQueueMessage can be created from either a string (in UTF-8 format) or a byte array. 

You can peek at the message in the front of a queue without removing it from the queue by calling the PeekMessage method.

You can get an estimate of the number of messages in a queue. The FetchAttributes method asks the Queue service to retrieve the queue attributes, including the message count. The ApproximateMessageCount property returns the last value retrieved by the FetchAttributes method, without calling the Queue service.

More topics on Connect to and consume Azure services and third-party services:

Develop an App Service Logic App

Develop Event-Based solutions

Implement API Management

Microsoft Azure AZ-204 exam topics:

If you have covered the current topics in Connect to and consume Azure services and third-party services then you can have a look at the other topic areas:

View full documentation Microsoft Azure: AZ-204 exam content from Microsoft

Leave a Reply

Your email address will not be published. Required fields are marked *