Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Naming and Registry

Updated: January 22, 2014

DNS is designed to map domain names to IP addresses. When you browse to a Web site, the first thing that occurs is a DNS lookup that determines to what IP address the friendly domain name resolves. Since DNS relies on public IP addresses, it does not work for identifying hosts located behind NAT devices without the help of a layered service such as Dynamic DNS. It is common for a single IP address to identify a complete network of hosts located behind a single NAT device. Ultimately, the DNS model is less than ideal for naming and identifying endpoints in a service oriented world.

Unlike DNS, the Windows Azure Service Bus naming system is optimized for naming service endpoints in a host-independent manner. You can think of the naming system as a global forest of federated naming trees projected onto host-independent URIs. Each service namespace maps to a naming tree; therefore, each service namespace must have a globally unique name. The naming trees are “federated” because each service namespace owner controls the names within a service namespace. They are “trees” because of the hierarchical nature of the namespace (names within names within names). There can be a natural projection for these names onto URIs, but the resulting URIs are completely host-independent – you can have multiple services running on different hosts that share the same solution name. These characteristics of the Service Bus naming system provide a more granular, endpoint-level approach that complements DNS.

Naming System

The root of the Service Bus naming system is resolvable through traditional DNS techniques. The naming system relies on host-independent criteria – specifically the service namespace – to distinguish between different domains of control in the naming system. Service namespace owners control the names within their respective service namespaces.

You project Service Bus names onto URIs as follows:


The Service Bus supports three URI schemes: “sb”, “http”, and “https”. You use “http” and “https” for all HTTP-based endpoints, and the “sb” scheme for all other TCP-based endpoints. The [service-namespace] part of the host name identifies a unique naming tree in the complete Service Bus namespace, which is controlled by the service namespace owner.

In the current release, nesting in the URI naming scheme is not supported. For example, topics and queues cannot be nested under each other. You cannot create a topic at https://contoso.servicebus.windows.net/HumanResources/Topic1, then a queue at its child location: https://contoso.servicebus.windows.net/HumanResources/Topic1/Queue1. Conversely, you cannot create a queue at a location such as https://contoso.servicebus.windows.net/HumanResources/Queue1, then a topic at its child location: https://contoso.servicebus.windows.net/HumanResources/Queue1/Topic1.

Similarly, a relay endpoint (for example, an endpoint for NetTcpRelayBinding, any Http relay binding, or a message buffer) and a messaging endpoint (for example, a queue or topic) cannot be nested under each other. You cannot have a messaging endpoint at https://contoso.servicebus.windows.net/HumanResources/Queue1 and a relay endpoint at https://contoso.servicebus.windows.net/HumanResources/Queue1/Relay1.


The Service Bus provides a service registry for publishing and discovering service endpoint references in a service namespace. Others can then discover the endpoints in a service namespace by browsing to the service namespace base address and retrieving an Atom feed. The service registry exposes the service namespace endpoints through a linked tree of Atom 1.0 feeds. You navigate the service registry by navigating the naming system via HTTP, browsing to each level in the naming structure of the solution you want to inspect. When you browse to the service namespace base HTTP address, you obtain the root Atom 1.0 feed describing the first level of nested names. If you then browse to one of the nested names, you obtain another Atom 1.0 feed that describes the second level of nested names. This continues until you reach a leaf name in the tree.

The Service Bus can publish endpoint information into the registry whenever you register new endpoints. If you want a particular endpoint to be discoverable, you associate the ServiceRegistrySettings behavior with the Windows Communication Foundation (WCF) endpoint, setting its DiscoveryMode property to DiscoveryType.Public. The following code shows how to do this in the WCF host application:

class Program
    static void Main(string[] args)
        Console.WriteLine("**** Service ****");
        ServiceHost host = new ServiceHost(typeof(myExample));

        ServiceRegistrySettings settings = new ServiceRegistrySettings();
        settings.DiscoveryMode = DiscoveryType.Public;
        foreach(ServiceEndpoint se in host.Description.Endpoints)

        Console.WriteLine("Press [Enter] to exit");


With this behavior, the relay service automatically populates the service registry with information about the endpoint in question.

Service Bus Queues, Topics, and Subscriptions are not discoverable in the service registry.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

© 2014 Microsoft. All rights reserved.