The ability to share data between decoupled systems is not a problem that is easily tackled. A distributed system is not a new concept but is a hot topic that continues to grow in popularity with the ever growing need to share data. As information continues to be the nucleus of our applications, the need to share and the way in which that information must be dispersed will continue to pose challenges.
Microsoft Azure’s Service Bus is a cloud service that helps facility the ability to share data between decoupled systems. In this article, we are going to learn how to leverage Azure’s Service Bus with Brokered messaging to distribute data between systems. However, if you are at all familiar with Azure services that provide support for distributed systems, you’ll know that Service Bus is not the only service of its type. Azure’s Queue Storage service also provides similar functionality and facilitates the ability to share data between distributed systems. So what queue service is right for you? These questions as well as the following topics are all areas we will be covering.

What is Service Bus

Simply put, Service Bus is the second message queuing platform build by Azure that provides Relay and Brokered messaging capabilities. It is a feature rich and matured service that can provides a means for decoupled systems to exchange information independently.

Azure’s Service Bus is one of the many Platform as a Service (PaaS) services and can be as simple as a single queue or highly complex message workflow with a near infinite number of interrelated queues, topics and subscriptions.

Service Bus vs. Queue Storage

As I have already pointed out, Service Bus is not the only message queue service Azure offers nor was it the first. But there are significant differentiating features between Service bus and Queue Storage, Azure’s first message queuing service. We are going to be doing a deep dive on the features Service Bus with brokered messaging offer, but it’s important that you are aware of when to use which service.

Microsoft has provided a compare and contrast document to help you make that decision. However, with the limited reasons for using the Queue Storage service, we can quickly summarize when Queue Storage would be the best chose. If you are in need of the least complex approach and your application meets the following needs, Queue Storage would be the best chose:
•Needs to retain more than 80 GB of data in queue
•Message time to live less than 7 days
•The ability to track message processing within a queue*

As you can see, message storage size and time to live are the two key differentiating points of Azure Storage Queue service. Naturally, the data retention aspect is of the Storage Queue service is due to the underlying Storage service. So, unless one of these points is a critical requirement, the Service Bus service is going to be a more feature rich and versatile option.

However, within the Service Bus service, there are more than one messaging capability. This article is focused on Service Bus with brokered messaging. But, brokered messaging is not the only messaging capability that Service Bus offers. Relay is another option that you will read about when investigating Azure’s Service bus, so let’s take a quick moment to distinguish the two.

Brokered vs. Relay Messaging

So far we have only mentioned “brokered” messaging with Azure Service Bus. But this is not the only messaging capability provided by Service bus. Instead of the pattern of queuing messages that we have been alluding to so far, Relay messaging provides the ability to “bounce” a message off of a service to an connected receiver. It requires that the receiver expecting the message is online and available. A strong point of Relay messaging is the ability to expose the service’s endpoint without the typical network firewall and infrastructure configuration hoop-jumping to make it available to external clients.

However, durability is not a strong point of Relay as it is with Brokered messaging. Brokered messaging supports the scenario of truly temporal decoupled systems where either message producer or consumers availability is not guaranteed. Therefore, messages that are not immediately delivered must live somewhere and that is where the “broker” comes into play. With Brokered messaging, the queue is the broker that retains a message created by a producer and where the consumer can retrieve the message when ready.

So while the exposure of service endpoints is one of Relay messaging strong points and queues provides the durability of Brokered messaging, queues coming more than one flavor. Therefore, we need to look at the different queue options before we get to the implementation of Service Bus Brokered Messaging.

Queues vs. Topics and Subscriptions

This can be confusing for someone just getting introduced to Service Bus Brokered Messaging, so I want to try and make this as clear as possible. First off, don’t lose sight of the fact that at the end of the day we are always talking about queues. A Service Bus Queue provides the simplest message delivery option. Messages in a Queue are organized by first in, first out (FIFO) and each message is expected to be processed by a single consumer. I like to visualize Queues as a single tube where a message is feed into tube and is consumed by a single consumer on the other end.

http://java.dzone.com/articles/everything-you-need-know-about-6