Brokered Messaging in Windows Azure
•Download as PPTX, PDF•
2 likes•2,459 views
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.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Brokered Messaging in Windows Azure
Similar to Brokered Messaging in Windows Azure (20)
More from Neil Mackenzie
Recently uploaded
Recently uploaded (20)
Brokered Messaging in Windows Azure
- 1. Brokered Messaging in Windows Azure NEIL MACKENZIE SATORY GLOBAL
- 2. Who Am I? Neil Mackenzie Windows Azure MVP Book: Microsoft Windows Azure Development Cookbook Blog: http://convective.wordpress.com/ Twitter: @mknz
- 3. Content Messaging overview Concepts Service Bus (digression) Brokered Messaging API Demo
- 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. 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. 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. 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. 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. Queues S Queue R S R S Multiple Competing Senders Receivers
- 10. Topics & Subscriptions Topic R Subscriptions S R R S R S R R Multiple Senders Rules Independently (filters & actions) Competing Receivers
- 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. Aside: Service Bus Namespaces Format: [namespace].servicebus.windows.net/[ServicePath] Examples: gress.servicebus.windows.net/services/echo gress.servicebus.windows.net/interestingtopic gress.servicebus.windows.net/news/subscriptions/subscriber Namespace: gress Topic name: news Subscription name: subscriber
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 http://bit.ly/s2Zagg
- 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. Comparison With Azure Storage Queues Feature Azure Queues Brokered Messaging API REST, .NET .NET, REST, WCF Authentication Storage Service HMAC Service Bus ACS Maximum queue size 100TB 5GB Maximum message size 64KB 256KB Maximum message TTL 7 days 10,675,199 days At most once delivery No Yes At least once delivery Yes Yes Maximum message lock 7 days 5 minutes Hosted service affinity Yes No Receive behavior Non-blocking Long polling (<24 days) Throughput 5,000 msgs/second 800-3,000 msgs/sec See: http://bit.ly/tY96CZ
- 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. 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 http://bit.ly/t5jUdm
- 30. References Alan Smith: Developers Guide to AppFabric http://bit.ly/uB0aHS Rick Garibay: Code magazine article http://bit.ly/sRm9iK Clemens Vasters: Build 2011 http://bit.ly/t5ip6k Neil Mackenzie: blog post http://bit.ly/oZdewm MSDN documentation http://bit.ly/v9dcPD
Editor's Notes
- Pull messaging
- Load leveling & load balancing
- At most once & at least once semantics.
- http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.servicebus.tokenprovider.aspx
- http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.servicebus.namespacemanager.aspx
- http://msdn.microsoft.com/en-us/library/windowsazure/hh367521.aspx
- http://preps2.wordpress.com/2011/09/17/comparison-of-windows-azure-storage-queues-and-service-bus-queues/
- http://windowsazurecat.com/2011/09/best-practices-leveraging-windows-azure-service-bus-brokered-messaging-api/
- CAT:http://msdn.microsoft.com/en-us/library/windowsazure/hh528527.aspxhttp://msdn.microsoft.com/en-us/library/windowsazure/hh528527.aspx
- @alansmith@rickggaribay@clemensv@mknz