Microsoft Azure Service Bus - Queue - Topic - Subscription
Queue provides a "first-in first-out (FIFO)" structure. A message in queue is consumed by only one consumer. The key benefit is temporal decoupling. In other words, producers send message to queue and consumers can consume message from queue in different times because queue stores messages wrt TTL (time to live). So producers does not wait any response from consumers and consumers does not reply producers message.
An other benefit is load leveling using competing consumer pattern. For example there are several message in the queue at the same time and your consumers is not enough to consume message, you can add new consumers to your system, then every consumer steal messages from queue at their own maximum rate and response time of your system become higher :).
Consumers and producers does not know each other because every client of system use Queue and connect to Queue, no one know and connect each other directly so it provides a fully decoupling. There are several message processing type in Service Bus Queue such as ReceiveAndDelete, PeerLock
"PeerLock" is a message processing type require two calls in consumer side, first one is Receive to get the message from Queue. When Receive() calls message disappear from Queue for a short time. Then consumers perform their operation for message then call second method which is Complete. When consumers perform their operations about message then call Complete to delete item from Queue permanently. If consumer cannot perform their operation because of exception or any other reason, consumers should call Abandon() to appear message in queue again. If user reads message but do not call Complete() or Abandon(), the message will appear automatically after a while.
ReceiveAndDelete is another message processing type which require only one call in consumer side. Consumer call ReceiveAndDelete() method to get message and message marked as consumed automatically so message will delete from queue. This cause an undesirable situation because your application will crash after get message. When your consumer application restart then crash and get a new message from queue because previous message (before crash) is marked as consumed. So you miss a message. Be careful when using this method.
Topics & Subscription
This is completely different from queue. Topics and Subscription provides Publish / Subscriber pattern. Producers send message for a Topic, and consumers subscriber topic(s). Service Bus creates virtual queues for each subscription. Producer send a message for topic, system automatically create identical copies of message and put in each consumer virtual queue. So each consumer get the message which published for subscribed queue.
I will mention detail of Topics & Subscription and Events Hub later...comments powered by Disqus