Skip Navigation LinksAzure Developers Guide > Azure Service Bus > Brokered Messaging > Messaging Scenarios

Training Courses

All course material is in English, and courses are delivered in English. Feel free to contact me for further information.

Messaging Scenarios

Message based systems have many uses in the development of enterprise applications. Reliable and secure communication between applications is often critical, along with the need to handle dynamically varying load levels. There is also a rising demand for integration with web services and legacy line of business applications.

Secure Network Traversal

As the Service Bus messaging services are cloud-based, hosted at Microsoft data centers, it makes them ideal for scenarios where messages must be exchanged between applications hosted in different server rooms or organizations. This could include communication between cloud based applications, between cloud-based and on-premise applications, and also between applications hosted on-premise.


Often on-premise applications are located behind firewalls and proxy servers making direct communication challenging to implement. Outbound communication between these on-premise applications and the Service Bus brokered messaging entities allows for secure network traversal when enqueueing and dequeuing messages.

Load Leveling

Message queuing can be used to handle scenarios when a large burst of messages is created in a short time period and the messages can be processed in an asynchronous fashion.

Consider a scenario where a large retailer with many branches needs to process end of day transaction messages from cache tills. At closing time all the cache tills in all the branches will send a transaction report, all within a relatively short time period. If a direct service call model was used to process these messages there is a chance that the load would exceed the capacity of the service, resulting in service timeouts and possible loss of data. Providing an environment that has sufficient capacity to handle these large message loads may not be cost efficient and any such environment would be ticking over on idle for the majority of its lifetime.



As sales information sometimes does not need to be updated in the line of business systems before start of traiding the next day it may be optimal to process these messages asynchronously.


Creating a queue for the end of day transaction messages and an application to receive and process those messages would allow the messages to be processed during the hours after close of business.

Load Balancing

In the above scenario there will be times when the message load could be exceptionally high. Holiday shopping periods and in store promotions are good examples of this. Using a message queuing system makes it easy to balance the message load by adding additional instances of the receiving application.


Using a cloud-based technology such as Windows Azure Worker Roles allows instances of the receiving application to easily be provisioned and then removed when required. This provisioning can be automated if required.

Resilience against Service Failure

When a queue is used as an intermediary between two applications the system becomes somewhat resilient against the failure of the service that receives and processes the messages. Brief service outages and network interruptions are sometimes to be expected in real world scenarios where parts of the infrastructure are outside the control of the application. Queued messaging can handle these scenarios very well.

There may also be scenarios where there is a severe failure of the receiving application. This could range from a few minutes to several hours. Provided the queue has sufficient capacity to store the in-transit messages whilst the receiving application is restored to an operational state it is possible to recover from these scenarios with no loss of data.

End of Day Processing

In other scenarios there may be a trickle of messages during the course of the business day. Instead of providing a service that is available 24/7 to handle this load a queue could be used to accumulate the messages. At the end of the business day a service could be automatically provisioned that would process the messages accumulated on the queue, and then unprovisioned once the workload is complete. Cloud-based technologies are ideal for this scenario, as service provision is quick and can be automated. If the message processing service is only provisioned for one hour a day there could be a 96% saving in compute resources.


Anyone who has worked with BizTalk Server will understand the power of using asynchronous publish-subscribe messaging when developing integration solutions. In future releases Service Bus will include integration services, which will provide similar pipeline and transform capabilities similar to those found in BizTalk Server. In the current version the Service Bus messaging capabilities can be used in integration scenarios using .NET, WCF and REST based applications.

Speaking Engagements