Service Bus Topic (Day 6 of 31)

List of all posts from this series: http://vunvulearadu.blogspot.ro/2014/11/azure-blog-post-marathon-is-ready-to.html

Short Description 
Service Bus allow us to communicate between different endpoints using publish/subscribe messaging communication model. This allow us to have a communication one-to-many, a message will received by multiple endpoints.
This is possible using the concept of topics and subscriptions. A topic represent the entry point for our messages into Service Bus. Each topic can have one or more subscriptions attached to it. A message that will enter in the topic will be received by all subscriptions.
If we make an analogy with queues, we could say that each subscriptions, is a different queue and a message that is send to the topic will be duplicated to all subscriptions related to it. One or more topic can be part of a namespace.

Main Features 
Max subscription number
In this moment each topic can have maximum 2.000 subscriptions attached to it. This mean that a message that is received by a topic can be distributed to maximum 2.000 endpoints automatically.
Death Letter Queue
A queue where messages that were not consumed with success by subscribers or expired can be send automatically. Can be used with success when we need to make auditing and support actions. In this way we can detect messages that were not consumed.
Time To Live
We can specify what is the default TTL of each message. Once a message expire it will be removed from topic and added to Death Letter Queue. This can be specified at topic level and/or at subscription level.
Duplicate Detection History
Topics are smart enough to detect duplicate messages and reject them. We can specify the time interval for how a message will be tracked and can be considered duplicate. When this option is activated we should be aware that the history of messages will consume a part of our available space on our topic and can affect the available space.
Topic State
There are 3 states that a topic can have:

• Enabled – Messages can be send to the topic and consumed by subscribers
• Disable – Messages cannot be send or consumed from topic/subscribers
• Send Disable – Messages cannot be send to topic, but subscribers can consume messages

Subscription State
There are 3 states that a subscription can have, similar with the one from topic:

• Enabled – Messages can be send/received by subscription
• Disable – Messages cannot be send/received by subscription
• Receive Disable – Messages cannot be send to subscription, but clients can consume existing messages 

Access
Access to Service Bus Topic can be made based on account key or using Shared Access Signature. When we use SAS we can specify for each token, what kind of actions can be made (Manage/Listen/Send).
Messages consumption
Messages can be consumed from subscription in two different way

• PeekLock – Message is took from subscription but is not deleted. Client needs to send a confirmation that message was consumed with success. If this confirmation is not send and the lock duration expires, the message will be available once again in the subscription. Remarks: When using this mechanism take into account that you will do two different transactions (Peek and Confirm) – this can increase the costs at the end of the month.
• ReceiveAndDelete – Message is received by client and automatically deleted. If an error occurs on the client side, the message cannot be retrieved any more. 

Lock Duration
For each subscription we can specify the lock duration when messages are consumed using peek mode pattern.
Max Delivery Count
We can specify how many times client can try to consume the same message from subscription. If this number of delivery count is exceeded the message is removed from subscription and will be send to death letter queue.
Session
Messages that are send to topic can be part of the session. When consumer are starting to consume messages from a session they will receive all the messages from a specific session in the same order.
Batch
There is the ability to send or consume messages in batches. The maximum size of a batch is  100 messages. Can be used with success when we want to optimize the number or request that send over the wire.
Message Property
Each message that is added to Service Bus Topics needs to be of type (format) of MessageBroker. A message broker can have not only a body (the data that we want to send), but also a list of properties. This properties represent the meta-data of a message and can be specified by clients.
Filters
We can specify filter at each subscription level. This filters can analyze look inside message property and accept message on that specific subscription based on the message properties (simple SQL filters -SQLFilter)
Actions
At subscription level we can also specify simple action that can change message property. For example we can change the value of a property based on other properties, increment them or create new properties (SQL Actions).
Deferred message processing
This feature enables receivers to "shelve" a message and retrieve it later by using a message unique ID
Message Size
The maximum size of a message can be 256kb.
Topic Size
The size of the topic can range from 1GB to 5GB.
Message delivery
Each message that is received by a Topic is guaranteed that will not be lost by system and will reach the final destination.
Subscription-Topic interconnection
You can connect a subscription to another topic from the same namespace. The message will be automatically forward from the subscription to topic.

Limitations 
Topic Size
This is a limit that can hearth you when you need to work with a lot of messages. In this cases you should look at Event Hub, it may be a better solution for your use case.
Subscription numbers
2.000 is a big number, but there are use cases when you would like more than 2.000 subscriptions. In this cases you should split your load on multiple topics based on different data like region or ID.

Applicable Use Cases 
Below you can find 4 use cases when Service Bus Topic can be used with success:
Send Commands to Devices
Service Bus Topic can be used when we need a reliable channel to send commands to different devices from field. Using it we will be sure that commands will be received by devices and when we need to execute multiple steps we can use session features with success.
Communication between different components
It can be used with success to connect multiple components. All the communication can be made in a reliable and scalable way. If one of the components is down, messages will not be lost and will be stored until the components is up and running again.
Distribute message to multiple components
Service Bus Topic can be used when we need to distribute content to multiple components in a simple and reliable way. We don’t need to care anymore about how we store content, distribute and so on.
Home Automation
In home automation, Service Bus can be the connection bridge between our backend and devices. It is an out of the box solution that is scalable and safe. We can even create a new topic for each different client and each subscription can be represented by a device from client home.

Code Sample 

// Create namespace
TokenProvider credentials = TokenProvider.CreateSharedSecretTokenProvider(IssuerName, IssuerKey);
NamespaceManager namespaceClient = new namespaceManager(ServiceBusEnvironment.CreateServiceUri("radusb", ServiceNamespace, string.Empty), credentials);

// Create topic description
TopicDescription rvTopicDesc = namespaceClient.CreateTopic("raduvunvuleatopic");

// Create subscription description
SubscriptionDescription acSubscription = namespaceClient.CreateSubscription(rvTopicDesc.Path, "ac");
SubscriptionDescription doorSubscription = namespaceClient.CreateSubscription(rvTopicDesc.Path, "door");

// Create topic
MessagingFactory factory = MessagingFactory.Create([serviceUrl], credentials);
TopicClient rvTopicClient = factory.CreateTopicClient(rvTopicDesc.Path)

// Send message
BrokeredMessage message = BrokeredMessage();
message...
rvTopicClient.Send(message);

// Consume messages from a subscription
SubscriptionClient acSubscription = factory.CreateSubscriptionClient("radusb", "ac", ReceiveMode.PeekLock);
BrokeredMessage message = null;
while ((message = acSubscription.Receive(TimeSpan.FromSeconds(30))) != null)
{
    ...
    message.Complete();
} 

Pros and Cons 
Pros

• Very scalable
• Robust
• Fast
• A lot of management features
• REST API

Cons

• Size of the topic not very big

Pricing
When you calculate the costs you need to take into account:

• Number of operations (each action that is done on topic/subscription is an operation)
• Outbound traffic

Conclusion
Service Bus Topic is a reliable messaging system that can be used with success in many scenarios. This a mature and robust service that has a lot of nice and useful features.