What is the Windows Azure Service Bus?

For the last year, there have been few things in the development space I have heard as much about, as I have heard about Windows Azure. Microsoft has been pushing the Azure platform hard, we all know that, but not all of us have had the chance to try it out though.

Luckily I have had the fortune of being on a few projects that have been using it, but to be honest, I haven’t been really blown away yet. Yes…it does offer some awesome features that work extremely well in certain scenarios, but I would still claim that it isn’t for everyone. Having that said, I admit that I have only scratched the surface of the platform…

Lately however, more or less every time I hear Azure, it comes bundled with the term Service Bus. Either in “this would be such a great scenario for the service bus”, or in “wonder if we can get the service bus in there so that we can try it out”. Ok…so one of these are ok, the other isn’t to be honest… Playing with the service bus isn’t hard, as I will show you in future posts, and thus does not need to be added to a project to be tried. But before I start coding, I want to have a little rant about what it is. Or at least a rant about how I have understood it…

As we start moving to more and more disconnected scenarios, and service oriented architectures, communication between the different parts of the solution becomes more and more complicated. Mostly it gets complicated because we need to cross the “cloud”. And as we all know, when we connect to the “cloud”, there is often an IT guy that puts some form of security between it and us. At least if you are on the service end of it…

The IT guy is also very reluctant to punch holes in his defense, which causes a lot of problems for us developers. At least in some scenarios. On the client side, it is not a problem as we are generally allowed to open communication outwards to the internet, at least as long as we stay within certain ports, e.g. port 80. The other way however is much more of a problem. Opening a port and expecting communication to come to you, is generally problematic, even if we don’t have the grumpy guy there telling us that we can’t. Even opening up a service on my computer at home requires me to reconfigure my router’s mapping. Not to mention that a lot, if not most, home users get a new IP address ever so often.

And that is where the service bus comes in. Or at least that is one of the things that the service bus can help us with. (It does a whole lot more…)

You can see the service bus is a friendly, but firm, intermediary that allows us to get around problems like firewalls. How? Well, that’s the funky stuff. Normally when you open up a service for communication, you open a port, or “endpoint”, on your machine and wait for clients to connect to it. Thus punching a hole in the defensive perimeter of the computer.

When you use the service bus, you do it slightly differently. Instead of opening up a port on you machine, you connect to an endpoint on the service bus, and tell it to open an endpoint for you. That way, your connection is outward bound, and flies through the firewall without problems in most cases.

In turn, the client does not connect to your service directly. Instead, it connects to the endpoint on the service bus, and send its messages to that endpoint instead. The service bus then relays the message to your service, gets the response back, and relays it to the client. At least in the simplest scenario, called “relayed messaging”.

So does this mean that we are limited in any way? Well not really. Yes, the endpoint configuration is not quite as flexible anymore, but other than that we still have the same features. We even build the services in the same way that we build our normal Wcf services. The only difference is that we use specific bindings…and that the client doesn’t connect straight to the service.

But, that isn’t it everything… There are a lot more features in the service bus, enabled by the fact that you let an intermediary sit in the middle. The most obvious being “brokered messaging”.

By using what is called “brokered messaging”, you can for example make it possible to expose services in a scenario where the service isn’t always there. Instead, messages being sent to the service are persisted in the service bus until the service connects and requests them.

This might not seem like a common scenario, but it does make it possible to create some interesting things. We are often talking about scenarios where the client isn’t always connected, but in some cases it might actually be the same for the service. SO far, this has not been possible, but with the service bus it is…

Brokered messaging, as described above, is done through what is called service bus queues. They work a whole lot like regular Azure queues, but are different in several areas. Mainly in the way that the service requests the messages, as well as the access control.

Another feature offered by the service bus is the use of topics and subscribers, which enable a publisher/subscriber pattern for services. It basically makes it very easy to have a single service endpoint that routes messages to more than one service. A message from a client might end up being handled simultaneously by several services, which can create some very powerful functionality.

As you can see, putting a man in the middle adds a lot of neat features. Most of them could definitely be created in a different way than using the service bus, but having it pre-built like this makes it so much easier for a developer to use.

And no, security is not a big issue. Communication can still be secured using SSL, and access control is handled by using tokens. Everything controlled by the Azure Access Control Service. And speaking of security, I just want to highlight that Microsoft is focusing a LOT on security nowadays.

But in my world, the possibly funkiest feature of them all is that REST-based WCF services using the WebGetAttribute are supported as well. And why is this cool? Well, I just find it funky that I can write a REST-based service using WCF and host it in whatever host I want, on whatever machine I want, and expose the functionality through a service bus endpoint. 

And if you for some mysterious reason follow my blog, you will know that I very rarely write posts here without code. I have been doing so lately as I attended BUILD, but that is hopefully going to change. So, this post will be followed by a couple of posts with code showing some of the things I have been talking about. So stay tuned!

Comments (2) -

Ryan CrawCour 9/30/2011 2:13:07 AM

Nice writeup! Especially like the way you summarise the brokered message and queuing stuff.

Definitely don't subscribe to the "let's get it in to a project so we can play with" camp. The ServiceBus is awesome and really adds massive value. For me it's the biggest differentiator in the market at the moment.

The REST stuff is funky too because it opens things up to service developers and consumers outside of the .NET only world! Now Java devs can build services / consumers and use the ServiceBus too via this API.

Looking forward to the next installment ....

Thanks Ryan!

The next part is up at chris.59north.com/.../...Bus-Message-relaying.aspx.

It is very simple, but it does contain code... Smile

Comments are closed