Chapter 7. Azure Service Bus Topic Integration

In this chapter, we're going to start implementing an Azure Service Bus topic that allows the subsystems across the three business units to send order status messages to each other and receive them via topic subscriptions.

After a quick introduction to Microsoft Azure Service Bus and topics, we'll create our Service Bus infrastructure, integrate the sales customer website, and create a WPF messaging simulator application, which will introduce some of the Azure Service Bus SDK features and provide us with a useful tool to help us build and test the full enterprise system.

We'll cover the following areas in this chapter:

• An overview of Microsoft Azure Service Bus topics

• Creating a Service Bus topic

• Connecting a website to a topic

• Creating a message simulator

• Exploring the portal's topic workspace

This will give us the foundations for building the rest of the system throughout the remainder of the book.

Introducing Azure Service Bus and topics

Service Bus technology, in general (not specific to Microsoft or Azure), allows multiple subsystem tiers in enterprise systems to communicate with each other in a loosely coupled and resilient manner.

Service Bus queues have a one-to-one relationship between providers and consumers, where a provider posts a message to a queue and it can be removed and processed once by a single consumer. This means we can easily scale up a consumer application without the fear of duplicating work; however, if we have a different application that may be interested in the same message, which is the case in our Azure Bakery system, we will need multiple processing applications to receive the same messages. This is the reason we selected an Azure Service Bus topic.

Service Bus topics handle messages to queues in a similar way, except that we can have multiple subscriptions for a topic that has a one-to-one relationship, where the applications interact in a similar way with...

Dead-letter queues

Under various failure conditions, messages can be automatically sent to a topic's dead-letter queue (the same applies to Service Bus queues). We can configure topics and subscriptions to dead-letter messages if their Time to live (TTL) expires, if they don't have a matching subscription filter, or if they cannot be delivered.

We need to pay attention to the dead-letter queue as it consumes our storage allocation for the topic, but it can also allow us to administer undelivered messages and diagnose potential performance issues or application problems.

Each subscription has its own dead-letter queue that can be accessed using the TopicClient object with /$DeadLetterQueue appended to various failure conditions; messages can be automatically sent to a the subscription name, like this:

// Create subscription client 
var subscriptionClient = SubscriptionClient.Create("TopicName", "SubscriptionName");

// Create dead letter client using subscription client TopicPath
var deadLetterClient...

Creating a Service Bus topic

Once we have a Service Bus namespace in place, Azure Service Bus topics and subscriptions can be created through the portal at design time and in code at runtime (also using the Azure PowerShell console, but we're not covering that). This makes it possible to create everything up front, providing the subsystems with the design details, or have the individual subsystems provision their own messaging infrastructure.

Creating Service Bus components in-code has security implications, as in order to create queues and topics, an application needs to use the namespace Access Control Service (ACS) or Shared Access Signature (SAS) credentials. System administrators may not want production applications to have this kind of capability, so they don't lose control over the Service Bus infrastructure architecture. If these credentials are compromised, the whole namespace can be at risk of an attack. To create subscriptions in-code, we need the Manage permission on a SAS policy...

Connecting a website to the Service Bus topic

We last saw the sales customer website order controller in Chapter 5, Building Azure MVC Websites, with the order status being updated to New in the sales database. Now that we have the service bus topic set up, we can modify this to send an order message for the production business domain to process and start manufacturing and the supply business domain to process and prepare packaging.

Preparing the website

The following procedure walks us through the installation of the WindowsAzure.ServiceBus NuGet package and configuration of the connection string, allowing the website to interact with the Service Bus:

1. In the portal, navigate to the TOPICS tab in the Service Bus workspace, select the new topic, and click on CONNECTION INFORMATION on the toolbar:

   

2. Here, we can see the SAS connection string for the SAS policies we just created. Leave this page open so that we can copy the strings later:

   

3. In order to interact with the Service Bus from the website...

The messaging simulator

The customer website is now integrated into the Service Bus, so new order messages are sent to the topic for the production and distribution business domains to process. To test the worker roles and load-test the system, we don't want to manually create orders through the website, as this would be extremely laborious and time-consuming, so we'll create a simulator application, which can generate orders of varying products at configurable rates on demand.

We'll create a new WPF application, which will allow us to start and stop messaging; control the order message cycle delay; and decide the quantity range of individual items to be added to the order, and the number of concurrent simulator threads, which will allow us to heavily load the system during testing.

If you don't have access to Visual Studio Professional, Premium, or Ultimate, you can create a new solution using Visual Studio Express for Desktop and add the existing Model project instead.

Setting up the project...

Exploring the topic workspace

If we navigate to our Service Bus namespace workspace in the portal and click on the TOPICS tab, we can see a quick overview of our topics, including their status, stored message size (CURRENT SIZE), and capacity (MAX SIZE):

Now, if we click on the topic and navigate to its workspace, we have a DASHBOARD section, which gives us a quick overview of the topic status with a graph that shows the messaging metrics, and a usage overview, which shows us how much of our storage allowance we're using along with some quick glance information.

The MONITOR tab

The MONITOR tab shows us the same metrics graph as the DASHBOARD section with more details of the tabular statistics underneath:

If we click on the ADD METRICS button, we can add and remove metrics from the display:

The CONFIGURE tab

The CONFIGURE tab allows us to configure the following settings that we originally set up when we created the topic:

• DEFAULT MESSAGE TIME TO LIVE: This is the amount of time elapsed between...

Summary

We've successfully implemented our Azure Service Bus Topic, which is the messaging layer of our entire enterprise system, integrated the Sales Customer website, and built a messaging simulator application, which will help us develop and test the rest of the system.

In the next chapter, we're going to be creating worker roles for the business units that will have their own subscriptions to consume and process Order Status messages.

Questions

1. What is the path of a subscription dead-letter queue?

2. What are the security implications of creating queues and topics in code?

3. What does the Enable Partitioning setting do when we create a topic?

4. What does the FILTER MESSAGE BEFORE PUBLISHING setting in the portal do?

5. Where can we find topic SAS connection strings?

6. In which config block does the Service Bus connection string appear when we install the WindowsAzure.ServiceBus package?

7. Which object do we use to send messages to a topic?

8. What does the IsTransient property on MessagingException tell us?

9. Which exception is thrown if a client tries to send a message with no matching subscription and FILTER MESSAGE BEFORE PUBLISHING is enabled?

10. What is the default ReceiveMode for a SubscriptionClient?

11. What is the message type we send to the Service Bus?

12. How many shared access policies can one topic have?

13. Create a simple WPF application, which creates a Service Bus queue itself, and then posts simple messages to the queue on a timer.

14. Create a second...

Answers

1. Subscription name along with /$DeadLetterQueue.

2. The code needs to use the Service Bus namespace security credentials, which puts the whole namespace at risk if the credentials are compromised.

3. Allows the Service Bus broker to scale up.

4. Prevents messages without a matching subscription filter being sent.

5. Under the topic CONNECTION INFORMATION in the TOPICS tab of the Service Bus workspace.

6. appSettings.

7. TopicClient.

8. If true, it tells us that an exception was caused by a transient fault and should be retried.

9. NoMatchingSubscriptionException.

10. PeekLock.

11. Brokered message.

12. 12.

13. NA.

14. NA.