Windows Azure Queues and Windows Azure Service Bus Queues

Service Bus QUeues (SB Queues) and Storage Queues (S Queues)

Comparison Criteria Windows Azure Queues Service Bus Queues
Ordering guarantee No Yes – First-In-First-Out (FIFO)(through the use of messaging sessions)
Delivery guarantee At-Least-Once At-Least-OnceAt-Most-Once
Transaction support No Yes(through the use of local transactions)
Receive behavior Non-blocking(completes immediately if no new message is found) Blocking with/without timeout(offers long polling, or the “Comet technique”)Non-blocking(through the use of .NET managed API only)
Receive mode Peek & Lease Peek & LockReceive & Delete
Exclusive access mode Lease-based Lock-based
Lease/Lock duration 30 seconds (default)7 days (maximum) 60 seconds (default)5 minutes (maximum)
Lease/Lock granularity Message level(each message can have a different timeout value) Queue level(each queue has a lock granularity applied to all of its messages, fixed for the lifetime of the queue)
Batched receive Yes(explicitly specifying message count when retrieving messages, up to a maximum of 32 messages) Yes(implicitly enabling a pre-fetch property or explicitly through the use of transactions)
Batched send No Yes(through the use of transactions or client-side batching)

Quoted from the resource below

Windows Azure Queues and Windows Azure Service Bus Queues – Compared and Contrasted
http://msdn.microsoft.com/en-us/library/windowsazure/hh767287(v=vs.103).aspx

Service Bus Queues vs Azure Storage Queues
http://social.msdn.microsoft.com/Forums/en-US/appfabricctp/thread/e88255a5-4b02-4f44-97a3-d2dad9aff320

 

 

Consider Using Queues in the Windows Azure Service Bus if

  • 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.

Consider Using Windows Azure Storage Queues if

  • 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 the transactions executed against your queues.
ref: http://alexandrebrisebois.wordpress.com/2013/10/20/windows-azure-storage-queues-vs-windows-azure-service-bus-queues/

Service Bus Samples
http://servicebus.codeplex.com/

Windows Azure code samples
http://code.msdn.microsoft.com/windowsazure

 

Cost comparison between Azure Service Bus Queues and RabbitMQ
http://www.mariuszwojcik.com/2014/07/11/cost-comparison-between-azure-service-bus-queues-and-rabbitmq/