pequeña comparación de las opciones de mensajería de Windows Azure, con foco en Services bus Queues y ejemplos transaccionales

1. Windows Azure Queues and Windows Azure
Service Bus Queues

2. Introduction
 Windows Azure Queues, which are part of the Windows Azure
storage infrastructure, feature a simple REST-based Get/Put/Peek
interface, providing reliable, persistent messaging within and between
services.
 Service Bus Queues are part of a broader Windows Azure
messaging infrastructure that supports queuing as well as
publish/subscribe, Web service remoting, and integration patterns.
DPE
DPE
Partner Development Team
Technical Evangelism & Evangelism Team

3. You should consider using Windows Azure
Queues
 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.
DPE
Partner Development Team
DPE
Technical Evangelism & Evangelism Team

4. You should consider using queues in the WA Service
Bus

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.
 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.
 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.
DPE
Partner Development Team
DPE
Technical Evangelism & Evangelism Team
 You would like to be able to publish and consume message batches.

5. Foundational Capabilities
DPE
DPE
Partner Development Team
Technical Evangelism & Evangelism Team

6. Advanced Capabilities
DPE
DPE
Partner Development Team
Technical Evangelism & Evangelism Team

7. Capacity and Quotas
DPE
DPE
Partner Development Team
Technical Evangelism & Evangelism Team

8. Transactional
Messaging in
the WA
Service Bus

9. Transactional Messaging in the Windows Azure
Service Bus
Transactions in Brokered Messaging
DPE
DPE
Partner Development Team
Technical Evangelism & Evangelism Team

10. Transactional Messaging in the Windows Azure
Service Bus
Receiving Multiple Messages in a Transaction
DPE
DPE
Partner Development Team
Technical Evangelism & Evangelism Team

11. Transactional Messaging in the Windows Azure
Service Bus
Received from more than one subscription
DPE
DPE
Partner Development Team
Technical Evangelism & Evangelism Team

12. Transactional Messaging in the Windows Azure
Service Bus
Transactions with MSMQ and Azure Service Bus
Our event handler needs to do the following:
1.
Start a transaction
2.
Read the message from MSMQ
3.
Put the message on the Service Bus
4.
Commit the transaction
DPE
DPE
Partner Development Team
Technical Evangelism & Evangelism Team

13. Scenarios in
the WA
Service Bus

14. Messaging Scenarios in the Windows Azure Service
Bus
Session Message Using WCF Services
DPE
DPE
Partner Development Team
Technical Evangelism & Evangelism Team

15. Messaging Scenarios in the Windows Azure Service
Bus
Other scenarios

Advanced Filters

Async Messaging

DeadLetter Queue

Deferred Messages

Duplicate Detection

Message Buffer

Messages Prefetch

Request Response

Session Messages

Transactions
DPE
DPE
http://servicebus.codeplex.com/
Partner Development Team
Technical Evangelism & Evangelism Team

16. Q&A
DPE
DPE
Partner Development Team
Technical Evangelism & Evangelism Team