.NET Service Bus (Part2) – Hands on with Queues

Its been an unforgivably long time since I wrote Part 1 of my series of hands articles on with the .NET Service Bus. I’ve tried to convince myself it was because I was confused by the WCF nature of the service relay. I also told myself to shelve the series while I started working on my “App Fabric” architecture model. Well, yesterday I realized I was just making things too hard. The service relay is just one piece of the .NET Service Bus which in turn is just one component of .NET Services. And while the service relay is an great piece, I was trying to do more with it when I needed too.

So with this epiphany in hand, I’m turning my attention to the another feature of the .NET Service Bus, queues.

I spent much of my playtime with Windows Azure messing with Azure Storage’s queue mechanism. IIMHO, .NSB’s queues are a little more robust and I’m happy about that. It also compliments the relay service nicely. The relay service is great when both the host and subscriber and online. But if either one could be offline, a queue is a great way to relay messages. There are also a series of important differences with how messages are pulled from .NSB queues. However, we’re gonna cover that in my next post.

NOTE: This article presumes you already have a .NET Services solution created and know the solution name and password.

What’s the same and what’s different

As I just mentioned, .NSB’s queues are a little more robust. But it would be helpful to put this in a bit of context by comparing the two.

Both are based on RESTful services that require authorization for access. And with both you can create, delete, and list queues as well as put and retrieve message from them. The .NSB version of Queues however has a fully supported API for .NET access (the StorageClient api for Azure storage is only a sample right now). You can define policies for .NSB queues and control access a bit more granularly. Finally, we have the ability to monitor for queue exceptions (possibly caused by policy violations).

As this weren’t enough, we can also hook these queues up to another .NSB feature, routers. But more on that another day. :)

Creating our first queue

So before we can start working with our queues, we need to actually create them. The process of creating a queue is pretty simple. You’ll define its policy and using that policy, create the queue. So lets get started with our hands on..

Fire up Visual Studio and create a windows form application, drop a text box and button onto the form, and start a “Click” event handler for the button. Next, we need to add references for .NET Service Bus SDK assembly (Microsoft.ServiceBus), System.ServiceModel, and System.RunTime.Serialization. Lastly, put a using clause for Microsoft.ServiceBus into the code-behind to make things easier later on.

We’re going to do the heavy lifting inside our event handler. Create two string values that will store our solution name and password for use in the code (I know, not a best practice, but this is just a demo *shrug*). The remaining work is split into four steps: create our URI, create our authentication credentials, define the queue policy, create the queue.

Define the URI

For creating our URI, we’re going to use ServiceBusEnvironment.CreateServiceUri. This is a solid best practice for working with the service bus.

Notice that we’re using our queue name (from the text box) as the path of our URI. We’ve also specified the protocol as “sb” because we’re addressing the service bus itself, not the queue.

Papers Please (Authentication Credentials)

Our URI specified “sb” as the protocol because we’re going to talk to the service bus. As such, we need to present our credentials. We’ll set up a simple username/password set using the solution credentials.

Nothing new hear really. Its not all that different then when we were relaying messages through the bus via WCF. The SolutioName and Password values are the strings we created earlier and should be valued appropriately for our .NSB solution.

Queue Policy (this is where things get interesting)

This is were we really get to see a key difference between Azure Storage queues and .NSB queues. To create a .NSB queue, we must define a policy that indicates how the queue will behave. We do this using the QueuePolicy class and its properties. The MSDN documentation for this class lists them all, so for the moment, I’ll just discuss the ones we’re using in my example.

QueuePolicy tmpPolicy = new QueuePolicy();

tmpPolicy.Discoverability = DiscoverabilityPolicy.Public;

tmpPolicy.Authorization = AuthorizationPolicy.NotRequired;

tmpPolicy.ExpirationInstant = DateTime.Now.AddDays(7);

Discoverability lets us control if this queue will be publically visible. Since I’ve seen this to true, anyone going to my solution’s URI will be able to see the ATOM of my queues. Authorization sets the type of credentials that are needed to access the service. And finally, ExpirationInstant determines when our queues resources can be reclaimed. This last time is an important distinction between Azure Storage and .NSB queues. With Azure Storage, once a queue is created, you need to explicitly remove it. With .NSB, we need to periodically update/renew this value if we want the queue’s existence to continue.

Now, I don’t know why this is the case, I would surmise it is because unlike with Azure Storage, you aren’t paying for the resources required to persist your queue. Given this, its reasonable that steps were taken to allow the .NET Service Bus to reclaim unused resources.

Create the queue. It Lives!

The final step is to create the queue. This is super simple…

QueueManagementClient.CreateQueue(tmpCredentials, tmpURI, tmpPolicy);

QueueManagementClient is what handles the interaction with the .NSB queue manager. We’re only calling one of several static methods contained in this class. We can also delete a queue, get an instance of QueueClient associated with a specific queue, renew a queue, or get just a queues policy. The only item lacking here that I’d like to see is a way to get a list of all the queues as we could with Azure storage. However, since we can crawl the ATOM feed for our solution and find any public queues, its not something I’m going to lose sleep over.

*ponders an idea for another blog post*

Wrapping up

That’s all I wanted to cover for today (I’m getting tired of my own SUPER long blog posts). Thanks for stopping by. Next time I’m going to dig into the QueueClient and working with the queue contents themselves.