Service Bus
http://windowsazurecat.com/2011/07/exploring-topics-and-queues-by-building-a-service-bus-explorer-toolpart-1/
“Understanding Windows Azure AppFabric Queues (and Topics)”video on the AppFabric Team Blog.
http://blogs.msdn.com/b/clemensv/archive/2011/06/10/understanding-windows-azure-appfabric-queues-and-topics.aspx
The maximum size of a queue during the CTP is 100MB, whichis expected to rise to 1GB (or more) for production.The maximum message sizeis 256KB, but the use of sessions allows creating unlimited-size sequences ofrelated messages.
Queues functionality are accessible through the following APIs:
-The new messaging API available via the new Microsoft.ServiceBus.Messaging assembly
-WCF viathe newServiceBusMessagingBinding
-Anextension of the Service Bus REST API.
Service Bus
asyn service -messaging , disconnect - Queue & message
syn service - rely service(listener)
Why we need messaging system?
- Load Balance
- Flat the traffic
- Nightly Report, simple start consumer (or worker role) once a day, not necessary to keep on running
How to solve the message size limitation?
all messages belong to same session id go to the sameconsumer, so even message>256KB,but we define multiple messages belong tosame session, then the same consumer will receive all of them
Topic vs Queue vs Message Buffer
-Topic: Additional purpose of data process without change any architect
-just plugin new subscription
-e.g.:
-Audit
-Partition
-Filtercategory for business
-Routing
-rulescondition: base on message property
-Queue: LoadBalance
-Message buffer (not durable,store in memory): will replace by Queue
http://convective.wordpress.com/2011/09/21/windows-azure-appfabric-service-bus-brokered-messaging/
Intro to Brokered Messaging
The name brokered messaging is used to distinguish thefunctionality from direct messaging in which a producer communicates directlywith a consumer, and relayed messaging in which a producer communicates with aconsumer through a relay.Both direct messaging and relayed messaging aresubject to backpressure from the consumer being limited in how fast it canconsume messages, and this causes the producer to throttle message productionthereby limiting service scalability. By contrast, brokered messaging uses ahigh-capacity intermediate store to consume and durably store messages which can then be pulled by the consumer. The benefit of this is that the producerand consumer can scale independently of each other since the intermediatemessage broker buffers any difference in the real-time ability of the producerto send messages and the consumer to receive them.
ReceiveMode
A consumer can receive a message in one of two receivemodes: PeekLock (the default) and ReceiveAndDelete. In PeekLock receive mode, aconsumer receives the message which remains invisible on the queue until theconsumer either abandons the message (physically or through a timeout) and themessage once again becomes visible or deletes the message on successfulcompletion of processing.This mode supports at least once processing, sinceeach message is consumed one or more times. InReceiveAndDelete mode, aconsumer receives the message and it is immediately deleted from the queue.This mode provides forat most once processing since each message is consumedat most once. A message can be lost in ReceiveAndDelete mode if the consumer failswhile processing a message.
Main Classes
The QueueDescription, TopicDescription and SubscriptionDescription classes are usedwith the NamespaceManager factory methods to parameterize the creation ofqueues, topics and subscriptions. It is interesting to look at the propertiesof these classes since they provide a direct way of understanding thefunctionality exposed through queues, topics and subscriptions.
e.g.:
-DefaultMessageTimeToLive
-DuplicateDetectionHistoryTimeWindow
-EnableBatchedOperations
-EnableDeadLetteringOnFilterEvaluationExceptions
-...
The QueueClient class is used to send and receive messagesto a queue. The TopicClient class is used to send messages to a topic while theSubscriptionClient class is used to receive messages from a subscription to atopic. The MessageSender class and MessageReceiver classes abstract the sendingand receiving functionality so that they can be used against either queues ortopics and subscriptions. The MessageSession class exposes functionalityallowing queue and subscription receivers to receive related messages as a“session.” After some receiver receives a message in a session, all messages inthat session are reserved for that receiver.
These show two different ways of inserting information in amessage – either as serializable content in the message body or as messageproperties.
MessageSession
Service Bus Brokered Messaging supports sessions and sessionstate. A queue or subscription must be set up to support sessions through theuse of the RequiresSession property in the QueueDescription orSubscriptionDescription. Subsequently, each message may have a SessionIdassociated with it. The intent is that related messages share a SessionId andcomprise a session. A MessageSession receiver can then be created on the queueor subscription to receive messages with the same SessionId. A persistentsession state can be associated with the session. This can be used along withthe PeekLock receive mode to implement exactly onceprocessing of messagessince the session state can be used to store the current state of processingregardless of any failure in the session consumer.
Appfabric Queue vs Windows Azure Storage Queue
Additionally,
Appfabric Queue support
- At least Once : PeekLock
- Exactly Once : Session State
- At most Once : ReciveDelete
- FIFO: Session + Deferred Message
- Detection of duplicate messages
- Dead-lettered messages
- Transaction
- At least Once