Tuesday, January 17, 2012

New Article: Windows Azure Queues and Windows Azure Service Bus Queues - Compared and Contrasted

by ValeryMizonov via Windows Azure on 1/17/2012 6:35:00 PM

We have been getting requests from customers for guidance when to use each of the two cloud-based queuing services offered today on Windows Azure: Windows Azure Queues and Windows Azure Service Bus Queues.

To address this, we have put together an article that analyzes the differences and similarities between the two services. By using this information, you can compare and contrast the respective queuing services and be able to make a more informed decision about which solution best meets your needs.

Following is the high-level technology selection considerations section from the full article on MSDN.

Technology Selection Considerations

Both Windows Azure Queues and Service Bus Queues are implementations of the message queuing service currently offered on Windows Azure. Each has a slightly different feature set, which means you can choose one or the other, or use both, depending on the needs of your particular solution or business/technical problem you are solving.

When determining which queuing technology fits the purpose for a given solution, solution architects and developers should consider the recommendations below. Further details can be found in the next section.

As a solution architect/developer, you should consider using Windows Azure Queues when:

• Your application needs to store over 5 GB worth of messages in a queue, where the messages have a lifetime shorter than 7 days.
• Your application requires flexible leasing to process its messages. This allows messages to have a very short lease time, so that if a worker crashes, the message can be processed again quickly. It also allows a worker to extend the lease on a message if it needs more time to process it, which helps deal with non-deterministic processing time of messages.
• Your application wants to track progress for processing a message inside of the message. This is useful if the worker processing a message crashes. A subsequent worker can then use that information to continue where the prior worker left off.
• You require server side logs of all of the transactions executed against your queues.

As a solution architect/developer, you should consider using queues in the Windows Azure Service Bus when:

• You require full integration with the Windows Communication Foundation (WCF) communication stack in the .NET Framework.
• Your solution needs to be able to support automatic duplicate detection.
• You need to be able to process related messages as a single logical group.
• Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.
• The time-to-live (TTL) characteristic of the application-specific workload can exceed the 7-day period.
• Your application handles messages that can exceed 64 KB but will not likely approach the 256 KB limit.
• Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.
• Your solution must be able to receive messages without having to poll the queue. With the Service Bus, this can be achieved through the use of the long-polling receive operation.
• You deal with a requirement to provide a role-based access model to the queues, and different rights/permissions for senders and receivers.
• Your queue size will not grow larger than 5 GB.
• You can envision an eventual migration from queue-based point-to-point communication to a message exchange pattern that allows seamless integration of additional receivers (subscribers), each of which receives independent copies of either some or all messages sent to the queue. The latter refers to the publish/subscribe capability natively provided by the Service Bus.
• Your messaging solution needs to be able to support the “At-Most-Once” delivery guarantee without the need for you to build the additional infrastructure components.
• You would like to be able to publish and consume message batches.

 Read the full article on MSDN.