AppFabric Service Bus – Things You Should Know – Part 1 of 3 (Naming Your Endpoints)

In this mini-series, I’ll share experiences from a recent project and explore the decisions that were made as we worked to design and deliver a solution which leverages the relay capability of the Windows Azure AppFabric Service Bus. The first part of this mini-series highlights the insights that were uncovered when considering the naming strategy used to identify thousands of Service Bus endpoints.

Introduction

After being involved in a few Service Bus deployments and participating in many architecture design reviews, I have observed there are two primary types of Service Bus patterns that emerge when considering use of the “relay service”. First, there are implementations that expose just a few Service Bus endpoints, which are then consumed by many clients; second, is almost the exact opposite, where you will find many (e.g. thousands) of endpoints, however each one is only consumed by a few clients. While other architectures are certainly possible (i.e. many endpoints, each with many clients, or few endpoints, each with few clients), I have not yet run across many examples of these when compared with the other two possibilities.

Figure 1 illustrates the Service Bus “relay service” architecture for the “many endpoints and few clients” pattern, which is indicative of the solution I found myself deeply engaged in. In particular, we had thousands of endpoints to register with the Service Bus, and we needed a naming system that made this not only possible, but easily manageable as well.

Figure 1 – Many Endpoints and Few Clients

Naming Your Endpoints

Now that we have a basic understanding of our “relay service” pattern, we need to think about a naming strategy for all of these endpoints. What is the best approach for naming 1,000 endpoints, 10,000 endpoints, or even 100,000 endpoints which all need to be registered with the Service Bus?

Before we consider the naming solution we used, we need clarity on one very important rule regarding Service Bus endpoints. The rule is this:
Once a service is registered, no other service can listen on any URI scoped at a lower level than your service.

In a hierarchical context, this rule means that if you register a node as an endpoint, then any child nodes cannot also be registered as endpoints. For example, if I registered [sb://krbcorp.servicebus.windows.net/detroit/facility1] then I would not be able to register [sb://krbcorp.servicebus.windows.net/detroit/facility1/orderservice]. However, if I did not register [sb://krbcorp.servicebus.windows.net/detroit/facility1] then I could have registered both [sb://krbcorp.servicebus.windows.net/detroit/facility1/orderservice] and [sb://krbcorp.servicebus.windows.net/detroit/facility1/shippingservice] as endpoints on the Service Bus.

Given this rule and the need to manage thousands of endpoints, we ended up with a naming solution that did not use city names, or facility names, or any other type of name; rather, we used GUID’s to uniquely identify each location. This was then followed by a descriptive name of the service. This structure allowed us to uniquely identify each endpoint on the Service Bus, which consisted of a GUID (representing a specific hosting location) and the name of the service. Here is an example:
[sb://krbcorp.servicebus.windows.net/B3B4D086-BEB9-4773-97D3-064B0DD306EA/myservice1]

There are a few reasons we selected this naming structure:

1. Using city and/or facility names, which admittedly are very descriptive and used in many examples, can cause a bit of trouble because they may not be unique when you have thousands of locations hosting a service that must be registered on the Service Bus. This is particularly true in the case of ISV’s which may have thousands of clients all over the world. Apparently city names like Franklin, Springfield, Salem, and many others, are some of the most commonly used city names in the world. We could have added another level in the hierarchy (e.g. State) to help with some of this, but even this was not guaranteed to be unique. We considered against this approach in order to avoid exceptions to our taxonomy. As it turned out, there was even more meta-data we wanted to capture about the location in which our service was hosted, and this additional meta-data embedded in the address had no bearing on the rules of the Service Bus.

2. GUID’s (representing the hosted location) and a service name (representing the service) guaranteed each registered endpoint would be unique – a requirement of the Service Bus.

3. The coding required for the automatic registration of an endpoint using GUID’s was a piece of cake. We simply generated a new GUID for each hosted service, concatenated this to our base address, and then appended the service name prior to registering the endpoint.

4. Appending the service name (i.e. myservice1) after the GUID provides us with the capability of registering more than one service per location, which non-coincidentally helps us meet the requirements of the Service Bus rule stated above.

5. And perhaps the most important… we didn’t have to worry about creating and using a taxonomy that could cause more discussion than actual work!

What else did we do?

Since we had a need to capture additional meta-data for each registered endpoint, and we elected to not have this reflected in the endpoint address, we decided to create a custom meta-data service repository using SQL Azure. This repository is populated by a custom WCF service hosted in Azure, which is called whenever a new endpoint is registered on the Service Bus. This allows us to maintain a rich set of data for each registered endpoint and keeps the naming process simple and effective.

Conclusion

This wraps up part 1 of 3 in the Service Bus mini-series. I hope this bit of insight helps as you explore the Service Bus offerings, especially if you find yourself in a scenario that considers various approaches for naming thousands of registered endpoints.

Authored by: Keith Bauer