Connecting in the cloud with AppFabric : Connecting with the Service Bus

In this section, we’re going to look into what the Service Bus is, why you’d use a bus, and, most importantly, how you can connect your services to it. You’ll see how easy it is to use the Service Bus.

1. What is a Service Bus?

Enterprise service buses (ESBs) have been around for years, and they’ve grown out of the SOA movement. As services became popular, and as the population of services at companies increased, companies found it harder and harder to maintain the infrastructure. The services and clients became so tightly coupled that the infrastructure became very brittle. This was the exact problem services were created to avoid. ESBs evolved to help fix these problems.

ESBs have several common characteristics, all geared toward building a more dynamic and flexible service environment:

• ESBs provide a service registry— Developers and dynamic clients needed ways to find available services, and to retrieve the contract and usage information they needed to consume them.

• ESBs provide a way to name services— This involves creating a namespace around services so there isn’t a conflict in the service names and the message types defined.

• ESBs provide some infrastructure for security— Generally, this includes a way to allow or deny people access to a service, and a way to specify what they’re allowed to do on that service.

• ESBs provide the “bus” part of ESB— The bus provides a way for the messages to move around from client to service, and back. The important part of the bus is the instrumentation in the endpoints that allows IT to manage the endpoint. IT can track the SLA of the endpoint, performance, and faults on the service.

• ESBs commonly provide service orchestration— Orchestration is the concept of composing several services together into a bigger service that performs some business process.

A common model for ESBs is shown in figure 1. This is similar to the typical n-tier architecture model, where each tier relies on the abstractions provided by the layer below it.

The orchestration has become not only a way to have lower-level services work together, but it also provides a layer of indirection on top of those services. In the orchestration layer you can route messages based on content, policy, or even service version. This is important as you connect services together, and as they mature.

2. Why an ESB is a good idea in the cloud

The problem for ESBs is that they usually only connect internal services and internal clients together. It’s hard to publish a service you don’t control to your own bus. External dependencies end up getting wrapped in a service you own and published to your ESB as an internal service. Although this avoids the first problem of attaching external services to your ESB, it introduces a new problem, which is yet more code to manage and secure.

If you wanted to expose a service to several vendors, or if you wanted a field application to connect to an internal service, you’d have to resort to all sorts of firewall tricks. You’d have to open ports, provision DNS, and do many other things that give IT managers nightmares. Another challenge is the effort it takes to make sure that an outside application can always connect and use your service.

To go one step farther, it’s an even bigger challenge to connect two outside clients together. The problem comes down to the variety of firewalls, NATs, proxies, and other network shenanigans that make point-to-point communication difficult. For example, figure 2 might represent the layers between your local software and the services it’s calling across the internet.

Take an instant messaging client, for example. When the client starts up, and the user logs in, the client creates an outbound, bidirectional connection to the chat service somewhere. This is always allowed across the network (unless the firewall is configured to explicitly block that type of client), no matter where you are. An outbound connection, especially over port 80 (where HTTP lives) is rarely a problem. Inbound connections, on the other hand, are almost always a problem.

Both clients have these outbound connections, and they’re used for signaling and commanding. If client A wants to chat with client B, a message is sent up to the service. The service uses the service registry to figure out where client B’s inbound connection is in the server farm, and sends the request to chat down client B’s link. If client B accepts the invitation to chat, a new connection is set up between the two clients with a predetermined rendezvous port. In this sense, the two clients are bouncing messages off a satellite in order to always connect, because a direct connection, especially an inbound one, wouldn’t be possible. This strategy gets the traffic through a multitude of firewalls—on the PC, on the servers, on the network—on both sides of the conversation.

There is also NATing (network address translation) going on. A network will use private IP addresses internally (usually in the 10.x.x.x range), and will only translate those to an IP address that works on the internet if the traffic needs to go outside the network. It’s quite common for all traffic coming from one company or office to have the same source IP address, even if there are hundreds of actual computers. The NAT device keeps a list of which internal addresses are communicating with the outside world. This list uses the TCP session ID (which is buried in each network message) to route inbound traffic back to the individual computer that asked for it.

The “bounce it off a satellite” approach bypasses this problem by having both clients dialing out to the service. Figure 3 illustrates how this works.

The Service Bus is here to give you all of that easy messaging goodness without all of the work. Imagine if Skype or Yahoo Messenger could just write a cool application that helped people communicate, instead of spending all of that hard work and time figuring out how to always connect with someone, no matter where they are.

The first step in connecting is knowing who you can connect with, and where they are. To determine this, you need to register your service on the Service Bus.