Brokered Messaging in Windows Azure


Published on

An overview of the Brokered Messaging feature on the Windows Azure Platform. Brokered Messaging supports Queues, Topics and Subscriptions providing message-based sollutions for load balancing, load leveling and pub/sub scenarios.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Pull messaging
  • Load leveling & load balancing
  • At most once & at least once semantics.
  • CAT:
  • @alansmith@rickggaribay@clemensv@mknz
  • Brokered Messaging in Windows Azure

    1. 1. Brokered Messaging in Windows Azure NEIL MACKENZIE SATORY GLOBAL
    2. 2. Who Am I? Neil Mackenzie Windows Azure MVP Book: Microsoft Windows Azure Development Cookbook Blog: Twitter: @mknz
    3. 3. Content Messaging overview Concepts Service Bus (digression) Brokered Messaging API Demo
    4. 4. Messaging Facilitates service-oriented architecture Windows Azure Platform supports:  Direct  Push - WCF  Relayed  Push – Service Bus Relayed Messaging  Brokered  Pull – Service Bus Brokered Messaging
    5. 5. Brokered Messaging Windows Azure Service Bus Brokered Messaging  Provides persistent store for messages  Exposes  Send endpoint  Listen endpoint  Supports:  Structured message content  Serializable message body  Sophisticated message receipt semantics  Message sessions  Correlated messages
    6. 6. Scenarios Temporal decoupling  Senders and receivers don’t need to be active simultaneously Load leveling  Receiver processes messages at its own pace Load balancing  Scale up number of receivers to handle load Pub/Sub - Multicasting  Multiple subscriptions
    7. 7. Message Store Managed by Brokered Messaging Exposed through a service path on the Service Bus Access controlled through Service Bus ACS Maximum size of queue/topic 1, 2, 3, 4, 5 GB Maximum message size: 256KB Message comprises:  Header (name/value pairs) < 64KB  Body (serializable)
    8. 8. At-Most Once or At-Least Once Brokered Messaging supports:  At-most once semantics  ReceiveMode.ReceiveAndDelete  At-least once semantics  ReceiveMode.PeekLock (default) Message disposition with PeekLock:  Abandon  Complete  DeadLetter  Defer
    9. 9. Queues S Queue R S R SMultiple CompetingSenders Receivers
    10. 10. Topics & Subscriptions Topic R Subscriptions S R R S R S R RMultipleSenders Rules Independently (filters & actions) Competing Receivers
    11. 11. Rules, Filters and Actions Rule comprises a Filter and an Action  Filter uses Properties bag of a subscription to filter messages in the subscription  Action uses SQL92 syntax to modify the Properties bag of a subscription Filters:  CorrelationFilter - uses CorrelationId  FalseFilter - no messages  SqlFilter - SQL 92 syntax  TrueFilter - all messages (default)
    12. 12. Aside: Service Bus Namespaces Format:  [namespace][ServicePath] Examples:     Namespace: gress  Topic name: news  Subscription name: subscriber
    13. 13. Aside: Service Identity “Owner” – admin account for entire namespace Following claims used for each service path:  manage  send  listen Create specific service identity for service path Use minimal set of claims  e.g. only “send” claim needed for a send-only application SBAzTool  SDK sample – application to manage service identities
    14. 14. Token Providers TokenProvider exposes factory methods creating various authentication token providers:  Saml token  Shared secret token  Simple web token Uri serviceUri = ServiceBusEnvironment.CreateServiceUri( "sb", serviceNamespace, String.Empty); TokenProvider tokenProvider = TokenProvider.CreateSharedSecretTokenProvider( issuer, issuerKey);
    15. 15. Managing Queues, Topics and Subscriptions NamespaceManager exposes factory methods to create and delete:  queues  topics  subscriptions NamespaceManager namespaceManager = new NamespaceManager( serviceUri, tokenProvider); namespaceManager.CreateQueue("queueName");
    16. 16. Queue, Topic and Subscription Metadata QueueDescription, TopicDescription and SubscriptionDescription used to configure queues, topics and subscriptions. Properties (e.g.):  DefaultMessageTimeToLive (qts)  LockDuration (qs) (Max 300s, def 60s)  MessageCount (qs)  Name (s)  Path (qt)  RequiresSession (qs)
    17. 17. Client Classes MessagingFactory exposes factory methods to create the MessagingClientEntity derived objects used to send and receive brokered messages:  MessageReceiver  MessageSession  MessageSender  QueueClient  SubscriptionClient  TopicClient MessagingFactory messagingFactory = MessagingFactory.Create( serviceUri, tokenProvider);
    18. 18. Class: Brokered Message BrokeredMessage  Represents the brokered message to be sent to a queue or topic, or retrieved from a queue or subscription.  Comprises a header with various properties and a body created from a serializable class. Properties  Properties bag can be used, instead of the message body, to store the content of a brokered message  Very powerful technique enabling rules, filters and actions
    19. 19. Class: QueueClient QueueClient  Handles sending and receiving brokered messages for a queue.  Implements standard message disposition methods (Abandon, Complete, DeadLetter and Defer) when using ReceiveMode.PeekLock  Supports synchronous and asynchronous versions of all methods No support for rules, filters and actions
    20. 20. Class: TopicClient TopicClient  sends brokered messages to a topic.  Supports synchronous and asynchronous versions of all methods TopicClient sender = messagingFactory.CreateTopicClient("topicName"); BrokeredMessage brokeredMessage = new BrokeredMessage(serializableObject); sender.Send(brokeredMessage);
    21. 21. Class: SubscriptionClient SubscriptionClient  receives brokered messages from a subscription  implements standard message disposition methods (Abandon, Complete, DeadLetter and Defer) when using ReceiveMode.PeekLock  supports synchronous and asynchronous versions of all methods
    22. 22. Classes: MessageReceiver & MessageSender MessageSender  Abstracts functionality of QueueClient and TopicClient so that it can send messages to either queues or topics. MessageReceiver  Abstracts functionality of QueueClient and SubscriptionClient so that it can receive messages from either queues or subscriptions.  Easiest way to access the deadletter queue.
    23. 23. Class: MessageSession MessageSession  provides specialized MessageReceiver used to handle sessions  receives messages only for a particular session Sessions are supported only if queue or subscription created with RequiresSession property Session is a sequence of brokered messages with the same SessionId
    24. 24. Deadletter Subqueue Subqueue containing “failed” messages Messages are added to deadletter subqueue  When explicitly deadlettered  On message expiration (if configured)  On filter evaluation failure (if configured) Deadletter queue processed like any other queue Named by extending service path, e.g.:  /queue/$deadLetterQueue  /topic/Subscriptions/subscription/$deadLetterQueue
    25. 25. WCF Interface WCF implementation of brokered messaging uses:  NetMessagingBinding Binding:  Folds brokered message into a WCF message  Handles message polling for receiver See: Rick Hollander post on MSDN 
    26. 26. REST Interface REST interface supports:  Send  Receive  Filters  More senders and receivers than .NET API REST interface does not support:  Sessions  Client batching
    27. 27. Comparison With Azure Storage QueuesFeature Azure Queues Brokered MessagingAPI REST, .NET .NET, REST, WCFAuthentication Storage Service HMAC Service Bus ACSMaximum queue size 100TB 5GBMaximum message size 64KB 256KBMaximum message TTL 7 days 10,675,199 daysAt most once delivery No YesAt least once delivery Yes YesMaximum message lock 7 days 5 minutesHosted service affinity Yes NoReceive behavior Non-blocking Long polling (<24 days)Throughput 5,000 msgs/second 800-3,000 msgs/sec See:
    28. 28. Performance Throughput:  800-3000 1KB messages / second through connection  Scales down by number of subscriptions Control performance through:  Client-side batching (default: on - factory)  send/complete  Database access (default: on - client entity)  Server caching  Prefetching (default: off – client entity) Use multiple queues and topics if necessary
    29. 29. Best Practices Use:  Non-blocking asynchronous senders & receivers  Asynchronous programming model (BeginX/EndX)  Transient Fault Handling Framework  Single message factory (connection)  Single client entity (thread safe)  Client-side batching Do not use:  Default version of Task Parallel Library See
    30. 30. References Alan Smith: Developers Guide to AppFabric  Rick Garibay: Code magazine article  Clemens Vasters: Build 2011  Neil Mackenzie: blog post  MSDN documentation 