I’m pleased to announce that I FINALLY have finished and packaged up a cool little ServiceBus demo.
I say “finally” because this demo has a long lifeline, it began over a year ago. I enhanced it, and showed it to a colleague, Tony Guidici, for his comments. He ended up enhancing it, and putting it into his Azure book. I then took it back, enhanced it further, and, well, here it is. Thanks also to my colleagues David Chou and Greg Oliver for their feedback.
There are several resources associated with this demo:
- High def video walkthrough: http://youtu.be/xKHl87_BFT0
- Low def video walkthrough: http://youtu.be/c3KLhsjstco
- Complete source code, http://servicebuseventdemo.codeplex.com/
Note that this is based on the current-when-I-did-this version 1.6 of the Azure SDK and .NET libraries.
At a high level, the scenario is that this is a system that listens for events, and when critical events occur, they are multicast to listeners/subscribers through the Azure ServiceBus. The listeners use the ServiceBus relay bindings, the subscribers use the topical pub/sub mechanism of the ServiceBus.
Why relay *and* subscription? They serve different models. For example, using the subscription model, a listener could subscribe to all messages, or just a subset based on a filter condition (in this demo, we have examples of both). All subscribers will get all messages. By contrast, a great example of the relay bindings is having a Web service deployed on-prem, and remoting that by exposing an endpoint on the ServiceBus. The ServiceBus recently introduced a load balancing feature, where you could have multiple instances of the same service running, but if a message is received only one of them is called.
Both models work very well for inter-application and B2B scenarios. Note that this demo is intended to show the various parts of the ServiceBus, in a real world scenario you would likely not have a subscription listener that in turn publishes to a relay.
The moving parts in this particular demo look like this:
Subscriptions are shown above as ovals, the direct lines are relay bindings. The red lines are critical events, the black line is all events.
The projects in the solutions are:
Their purposes are:
|EventPoint.ConsoleApp||Listens for critical messages multicast through the ServiceBus relay binding|
|EventPoint.ConsoleApp.Topics||Listens for critical messages multicast through the ServiceBus eventpoint-topics namespace|
|EventPoint.Generator||Test harness, publishes messages to the ServiceBus eventpoint-topics namespace|
|EventPoint.Monitor||WinForms app that listens for critical messages multicast through the ServiceBus relay binding|
|EventPoint.CriticalPersister||Listens for critical messages multicast through the ServiceBus relay binding and persists them to SQL Azure|
|EventPoint_WebRole||Table browser UI to see all events that have been persisted to Azure table storage|
|EventPoint_WorkerRole||Worker role that sets up eventpoint-topics subscriptions for 1) All events and 2) critical (priority 0) messages that get multicast to the ServiceBus relay|
|EventPoint.Common||Config, message factory to support push notifications|
|Microsoft.Samples.ServiceBusMessaging||NuGet package to support push notifications|
There are a few things you’ll need to do in order to get the demo working. Remarkably few things actually, considering the number of moving parts in the flow diagram!
First off, in the admin portal, you will need to create two ServiceBus namespaces:
NOTE THAT SERVICEBUS NAMESPACES MUST BE GLOBALLY UNIQUE. The ones shown above are ones I chose, if you want to run the code you will have to choose your own and cannot re-use mine (unless I delete them).
The “eventpoint-critical” namespace is used for the relay bindings, the “eventpoint-topics” is used for the pub/sub (apparently you cannot use the same namespace for both purposes, at least at the time this was written). You don’t have to use those names, but if you change them, you’ll need to change them in the config file too, so I’d suggest just leaving it this way.
Because there are multiple types of apps, ranging from Azure worker roles through console and winforms apps, I created a single shared static config class that is shared among the apps. You can, and need to, update the app.config file with your appropriate account information:
Note: there are more things you need to change that did not fit in the screen shot, they will be self-evident when you look at the App.Config file.
To get the ServiceBus issuer name and secret, you may need to scroll as it is bottom-most right-hand side of the ServiceBus page:
Lastly, you’ll need to add the name/creds of your storage account to the Web and worker roles.
When you run the app, five visible projects will start, plus a web role and a worker role running in the emulator.
In the screen shot below, I generated 5 random messages. Three of them were critical, and you can see they were picked up by the console apps and the WinForms app.
Just as with Windows Azure queues, the Azure ServiceBus is a powerful tool you can use to decouple parts of your application. I hope you find this demo helpful, and that it gives you new ideas about how you can use it in your own solutions.