In my last post we discussed using Azure AppFabric Queues as part of Azure AppFabric Applications.  In this post, we will discuss a couple of related Queue technologies called Topics and Subscriptions.  The purpose of this post will be to describe the conceptual behavior of Topics and Subscriptions and then in a follow up post actually dive into a detailed example of how we can use this technology. 

What is a Topic?

A Topic is much like a Queue in some ways.  It is a durable storage container that allows consuming clients to retrieve messages from.  Data within a Queue can be consumed by a single client.  Data within a topic can be consumed by multiple clients through an AppFabric Subscription.

What is a Subscription?

A Subscription is probably exactly what you think it is.  It is a client requesting a copy of a particular message that has been published to a Topic.  Subscriptions by default include all messages for a particular subscription but we can also specify a SQL 92 query which essentially allows us to “filter” messages that we are interested in.

Topics + Subscriptions = Pub/Sub

The combination of Topics and Subscriptions really allow for Pub/Sub in the cloud.  It provides the ability for a publisher to put a message in the cloud then have consuming client(s)  retrieve messages that are relevant.  When a publisher sends a message to the cloud, it is really sending it to a Topic and when a consuming client retrieves a message it is doing so through a Subscription.

Why is this important?

In my opinion, I think this is pretty cool technology.  Internet Pub/Sub messaging is something that is a relatively new concept in the Microsoft Stack.  The idea that you can perform this pub/sub in the cloud provides some unique opportunities in both Business to Business and Business to Consumer scenarios.  With Business to Business scenarios dealing with network firewalls to allow for communication to occur(between organizations) is usually not a fun adventure.   Also, providing the ability to scale usually provides challenges as well.  On the Business to Consumer side, our Topic messages are stored in a durable store and therefore support disconnected client scenarios provided we mark messages with a suitable time to live (TTL) parameter.

Example

In the previous Queue post we had an example of a Power Outage application that allows customers with a power outage to report it through a mobile phone browser.  That example works great if we have a single consumer, but what if we have multiple consumers?  Enter Topics and Subscriptions.

This scenario is very similar.  We want customers to be able to submit power outages to our fictitious power company located in the Redmond, Washington area.  What is different this time around is that due to the growth in the Kirkland, Washington area we have subcontracted power line maintenance to another company.  So we want our Redmond system to receive messages for the Redmond area and this other company to receive messages for Kirkland.  The Redmond company should not see the Kirkland messages and vice versa.

To support this solution, we will create 1 Topic.  The Web application will submit messages to this Topic.  We will also register 2 Subscriptions on this topic and provide a filter expression that will ensure that our Redmond client receives messages for Redmond and a filter expression that ensures our Kirkland client receives messages for Kirkland.

Please see post 2 that will provide a step by step implementation of this solution.