Windows Azure Service BusAnton Boyko.NET developer
Service Bus Relay
OnewayNetOnewayRelayBindingAll TCP and HTTP listeners use one-way as internal control channel60KB message-size limitOne-way onlyNo rendezvous overhead
Backend
NamingRouting
Fabric
solution. a b
FrontendNodes
outbound
connect one-way
net.tcp
outbound connect bidi socket
MsgMsg
NATFirewall
Dynamic IP
NLB TCP/SSL HTTP(S)TCP/SSL HTTP(S)
RouteSubscribe
Rendezvous(TCP & HTTP)
NetTcpRelayBindingWebHttpRelayBindingBasicHttpRelayBindingWS2007RelayBindingRendezvous HandshakeBi-Directional Net.Tcp Full DuplexNo message size limit
solution. a b
NLB
outbound socket rendezvous
HTTP/SocketForwarder
outbound
socket connect
Ctrl
Ctrl
TCP/SSL or HTTP
Backend
NamingRouting
Fabric
FrontendNodes
solution. a bBacken
dNamingRouting
Fabric
FrontendNodes
Hybrid ConnectSpecial Mode of NetTcpRelayBindingTcpRelayConnection-Mode.HybridStarts as relayed connectionPerforms NAT probing and behavior predictionEstablishes direct connection and upgrades if possibleUpgrade driven by trafficTakes large transfers off the RelayNo transfer charges, lower latency
relayed connect
NAT Probing
CtrlNAT Probing
NAT Traversal Connection
Upgrade
Upgrade
relayed rendezvous
Oneway RendezvousCtrl Msg
TCP/SSL HTTP(S)
Service Bus Messaging
Relay vs. Message Broker
The Relay routes messages ‘straight through’ with feedback path and network backpressure into sender
Route
AuthN/Z Backpressure Feedback Relay
Query FilterPull
AuthN/Z Broker
Brokers hold messages for retrieval and querying
Push vs. Pull
‘Push’ is a sender initiated activity that results in delivery of a message to a receiver without the receiver explicitly asking for one or a particular message
Intermediary
Broker
‘Pull’ is a receiver initiated activity that delivers stored messages to the receiver in a context that the receiver controls. The context is decoupled from the ‘Push’ style send operation
Ways to PullReceive and DeleteFastest. Message lost if receiver crashes or transmission fails.
Peek LockMessage is locked when retrieved. Reappears on broker when not deleted within lock timeout.
TransactionalLocal model
Broker
Broker
Broker
Broker Message
MessagesProperties are key/value pairs that may very well carry payloadsIt’s not uncommon to have messages with empty message bodiesMessage bodies are useful for a single opaque payload not exposed to the broker (e.g. encrypted content)
Body
Properties
Queues
Load LevelingReceiver receives and processes at its own pace. Can never be overloaded. Can add receivers as queue length grows, reduce receiver if queue length is low or zero. Gracefully handles traffic spikes by never stressing out the backend.
Offline/BatchAllows taking the receiver offline for servicing or other reasons. Requests are buffered up until the receiver is available again.
Queue
Queues
Load BalancingMultiple receivers compete for messages on the same queue (or subscription). Provides automatic load balancing of work to receivers volunteering for jobs.Observing the queue length allows to determine whether more receivers are required.
Queue
TopicsTopic Sub
SubSub
Message DistributionEach receiver gets its own copy of each message. Subscriptions are independent. Allows for many independent ‘taps’ into a message stream. Subscriber can filter down by interest.
Constrained Message Distribution (Partitioning)Receiver get mutually exclusive slices of the message stream by creating appropriate filter expressions.
Subscription FiltersFilter conditions operate on message properties and are expressed in SQL’92 syntax InvoiceTotal > 10000.00 OR ClientRating <3ShipDestCtry = ‘USA’ AND ShipDestState=‘WA’LastName LIKE ‘V%’
Filters actions may modify/add/remove properties as message is selectedSET AuditRequired = 1
Service Bus Best PracticesClient object lifecycle management• Cache QueueClient, SubscriptionClient, TopicClient• Close clients when no longer needed. Close() method may throw an
exception. Wrap it with try/catch.
Handling transient errors• Implement consistent retry pattern• Consider Transient Fault Handling Framework (EntLib6)
Reliable message handling (Peeklock)• Always finalize successfully processed message by calling Complete()• Always abandon unprocessed message by calling Abandon()• Ensure message is processed within designated lock period
Service Bus Best Practices (cont.)Improve Performance• Reuse client objects• Choose Service Bus client protocol over HTTP• Use asynchronous send/receive• Use ReceiveAndDelete when appropriate• Use multiple queues
Storage Queue vs. Service Bus QueueStorage Queue• TTL 7 days max• Max queue size 100 TB• Max message size 64 KB• Authentication via
symmetric key• No WCF integration
Service Bus Queue• TTL unlimited• Max queue size 5GB• Max message size 256 KB• Authentication via
ACS claims• WCF Integration out-of-the-
box
more details http://msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspx