Windows Azure ServiceBus Topic And Subscription Part-1
July 3, 2012 6 Comments
In my previous post: “Overview to Service Bus Messaging” , I spoke about the types of Service Bus messaging. One of the types of messaging which I wanted to discuss in more details is Service Bus Topic & Subscriptions.
I was wondering how to explain the concept in detail, so I thought of using a scenario to elaborate the concept and the usage. I have selected a hypothetical weather data distribution scenario.
When I started writing the blog, I initially thought that I would be able to post the full blog content in a single post, but unfortunately it became a bit bigger than anticipated, and therefore my colleague, Brian Furlong, suggested I split into two parts. So I have segmented my blog into two parts for better readability.
- In part 1, I would discuss the scenario and how we would achieve the objective using Service Bus Topic and Subscriptions
- In part 2, I would discuss how to implement the design using service bus topic and subscription.
So what is the scenario?
The scenario is; let’s assume that there is a large weather station which is monitoring and recording weather data from various monitoring units including ground station, weather satellite, etc. The large weather station in turn collates the weather data and publishes the collated weather data based on the region. The published weather data is received by the subscribers subscribed to a region specific data. For the sake of simplicity, I have three regions in my weather data publishing scenario namely; US, EU and APAC.
There are four subscribers in this scenario with following weather data subscription requirement:
- Subscriber “USObserver” intends to subscribe to US region data only
- Subscriber “EUObserver” intends to subscribe to EU region data only
- Subscriber “APACObserver” intends to subscribe to APAC region data only
- Subscriber “GobalObserver” intends to subscribe to all weather data.
The scenario has few additional requirements for security:
- The subscribers should not be able to view any other data other than the subscribed data. The rule would support the subscriber isolation scenario wherein a subscriber is allowed only to view their data and not the unsubscribed data.
- The subscribers should not be able to alter their rights. The rule would support the subscriber authorization scenario wherein a subscriber would be prohibited from altering the subscriber’s role and data permission.
The diagram below represents the scenario where a weather Data Publishing Service is collecting data from multiple sources for example ground monitoring, ground unit, weather satellite, etc. The collated data is then published to the subscribers.
Let’s see how we could build a highly scalable publisher subscriber messaging mechanism using windows Azure. The solution based on Windows Azure Service Bus messaging would comprise of the following major elements:
- Service Bus Topic
- Service Bus Subscription
- Access Control Service
So what is our design?
Let’s have a walk through with some design aspects showing how we are going to achieve our objectives. To achieve the desired objective we would need the following:
- A Publisher: For simplicity, we would create a console application which would act as a message publisher into the topic. Let’s name the application as “WeatherPublisherAgent”. The application would publish the various weather messages on to the topic. The messages are defined as “WeatherMessage” class.
- A Topic: A Service Bus topic would be required and let’s name the topic as “weathertopic”.
- Four Subscriptions: We would require four subscriptions corresponding to each of our subscribers. Let’s name the subscriptions accordingly to the subscriber
- i. USObservers – subscription for US tagged messages
- ii. EUObservers – subscription for EU tagged messages
- iii. APACObservers – subscription for APAC tagged messages
- iv. GlobalObservers – subscription for all messages
- Four Subscriber Applications: For simplicity let’s have a console application for each subscriber which would be pulling the weather data from the respective subscription.
- Access rules: This is one of the most important aspects dealing with security and authorization. Let’s consider the following users with roles for the scenario:
|publisher||Send||The user would be able to send messages to a topic|
|usobserver||Listen||The user would be able to listen to messages on a topic through respective subscription. The user would only be allowed to receive messages tagged as US messages.|
|euobserver||Listen||The user would be able to listen to messages on a topic through respective subscription. The user would only be allowed to receive messages tagged as EU messages.|
|apacobserver||Listen||The user would be able to listen to messages on a topic through respective subscription. The user would only be allowed to receive messages tagged as APAC messages.|
|globalobserver||Listen||The user would be able to listen to messages on a topic through respective subscription. The user would only be allowed to receive all messages.|
The diagram below represents the design overview of the solution.
My next post will elaborate on how to implement the above design. Read it here
Rahul Sur is a highly proficient and hands-on Technical Architect accomplished in designing and delivering complex and high profile IT solutions comprising middle-and-multi-tier software development across mobile, media, web and Cloud platforms using Microsoft technologies and a range of quality standards and project methodologies.
© 2012 Information Management Group Limited