On the 9th day of Windows Azure Platform Christmas my true love gave to me the Windows Azure AppFabric Service Bus.
What is the Windows Azure AppFabric Service Bus?
Before I jump in and waffle on about the Service Bus. I’ll mention a little bit about Windows Azure AppFabric; what it is and what it does.
Windows Azure AppFabric is a platform made up of three services; Service Bus, Access Control and Caching. The purpose of this platform is to provide you with a way of building and managing, reliable, secure applications that run on Windows Azure.
So, back to today’s topic; Service Bus.
It’s quite common these days to expose services to the internet that allow applications; that either you or a third-party has created, to access data within a secure network. To allow this kind of infrastructure to work you would need to set up your service on a public facing server with ports and holes punched through a firewall and maybe some NAT policies to allow connections in and out.
The Service Bus was built to relieve the aches and pains of setting up such an infrastructure. So, how does it work?
Let’s say for an example you want to expose data using a WCF Service. First, you would register an endpoint between your service and the Service Bus. When this endpoint is created, the Service bus automatically creates its own corresponding endpoint. The Service Bus then assigns you a URI (Uniform Resource Identifier) root, below which you can create any hierarchy you like. This allows your endpoints to be assigned specific discoverable URIs.
Now, if an application; either in the Cloud or somewhere else, contacts the Service Bus with a specific endpoint URI, the Service Bus takes that URI and finds the appropriate endpoint registered with your service. This request process uses the Atom Publishing Protocol (http://bitworking.org/projects/atom/rfc5023.html) which returns an AtomPub service document with references to the endpoints the Service Bus exposes. Once the application has this document it can invoke calls to the Service Bus which in turn relays these calls through to the appropriate service; the WCF Service registered at the start of this example
This all sounds great, but how does this get past setting up firewalls etc.?
The service that you register with the Service Bus opens a TCP connection with the Service Bus (this is important). This connection is then held open by the Service Bus, which fixes two issues raised earlier; NAT and Firewalls. NAT is no longer an issue because traffic on the open connection with Service Bus will always be routed to the service/application. Firewalls are no longer an issue because the connection was initiated from inside the network; an important point made earlier.
For all you security peeps out there, the Service Bus only exposes one IP Address which means you don’t have to expose multiple addresses, limiting the surface for attacks.
In this post I’ve talked about using WCF Services to expose data to the outside world, but you can also use other technologies like Java to expose data or application functionality; you just need to make sure you communicate with TCP, HTTP or HTTPS. Simples
The Service Bus also provides a message buffer service, which allows the queuing of messages up to 256 kilobytes, which are persisted to disk and can be read by the service at a later point; they’re also replicated which means fault tolerance, a major feature of the Windows Azure Platform.
Exposing services or applications is never a simple task, but what I’ve tried to show you is that it’s very simple to implement with the Service Bus. This is the one feature that keeps appearing in each component of the Windows Azure Platform; simplicity! It’s there to make your job simpler, so all you focus on as a developer is the application.
Tomorrow’s installment: Windows Azure AppFabric – Access Control
P.S. If you have any questions, corrections or suggestions to make please let me know.