It is very important to understand how the Service Bus Naming and Discovery system works. This would allow the developers to name their services properly. The Service Bus namespace mechanism though is advanced works in a way that is similar to the Domain Name System (DNS) being used for the internet.
The Domain Name System (DNS) forms a critical part in how the internet is served. DNS maps the website address (example: mapping www.bing.com or www.google.com or www.pramati.com) to their respective IP addresses. This is first and most critical item that takes place when a user types in a website on a web browser. The DNS relies on the public IP’s of the websites and cannot look for websites being hosted behind a Network Address Translation (NAT) device without Dynamic DNS services.
The Service Bus naming system is more optimized for naming and identifying the endpoints compared to the DNS. The service bus naming system can be used for naming service endpoints in a host-independent way.
One can imagine the service bus naming system being akin to a huge forest of federated naming trees being projected onto host-independent URI’s with each service namespace being a tree, which makes that namespace unique. Each namespace owner in turn controls all the names within his namespace. The namespaces are hierarchical in nature as they contain names within names within names.
Each tree though being having a unique URI is again host-independent. Thus providing a way to have multiple services being hosted on different machines with the same solution name.
The root of the Service Bus naming system is resolvable through traditional DNS techniques. The naming system then relies on host-independent criteria – specifically the service namespace – to distinguish between different domains of control within the naming system. It’s up to namespace owners to control the names with their respective service namespaces.
Service Bus Naming System – From documentation provided by Microsoft
Service Bus URI format can be thought as
[scheme]://[servicebus-namespace].servicebus.windows.net/[name1 or path1]/[name 2 or path 2]/…. And so on and so forth.
Supported URI schemes are “sb”,”http”,”https”. For HTTP-based endpoints use “http” and “https” and for TCP-based endpoints use “sb”.
The “servicebus-namespace” is the placeholder for uniquely identifying a naming tree with the entire Service Bus. This is under the control of the owner and is the one that we create through the portal.
The next part “name or path” is the path for the endpoints and is user-created. A user can create as many names within this namespace. You’ll notice this being the one shown as “Name” in the relay section of the particular service bus namespace provided there’s an active connection.
You can have multiple “Paths/Names” depending on your requirement. For example, let’s say your service bus namespace is “myservicebus” and your path name is “hello”, then the entire URI format would look like “sb://myservicebus.servicebus.windows.net/hello” or “http(s):// myservicebus.servicebus.windows.net/hello” depending on the protocol being used.
You can also have multiple endpoints within it that’d provide service, let’s say based on the continent, then you can add that to the URI. For example
You can also go ahead and have country based one’s as well if you’d like to and again go granular if needed.
One of the biggest advantages of using the service bus is that, even though you have a large number of endpoints created within the same service bus namespace they don’t have to be hosted either in the same network/geographical location/network etc. The relay service of the Service Bus is responsible to determine where the service is present physically at the time of resolution.
No API’s are provided by the Service Bus to be able to access/interact directly with the naming system, one can only access the naming system through the service registry functionality.
Publishing and discovering service endpoint references within a service/service bus namespace is possible since Service Bus provides a service registry.
Service endpoints within a service namespace can also be discovered by going to the service namespace base address using a browser provided the service endpoint supports either http or https protocols. In such scenarios an Atom feed can be retrieved by sending a HTTP GET request to the base address and you can drill down the naming structure to the lowest level of the hierarchy created by the endpoint.
Service Bus takes care of publishing endpoint information into the service registry as and when a new endpoint is registered. Endpoint can also be made to be discoverable by setting the Discovery Mode property to DiscoveryType.Public in the ServiceRegistrySettings and associate it with the WCF endpoint. Note that the Discovery Mode property is set to DiscoveryType.Private by default. The relay service generates the service registry along with the information about the endpoints automatically.
static void Main(string args)
Console.WriteLine("## Starting Service ##");
ServiceHost serviceHost = new ServiceHost(typeof(MyServiceBus));
ServiceRegistrySettings registrySettings = new ServiceRegistrySettings();
registrySettings.DiscoveryMode = DiscoveryType.Public;
foreach(ServiceEndpoint endPoint in serviceHost.Description.Endpoints)
Console.WriteLine("Press Enter to exit");
Sample code to make endpoint discoverable by associating ServiceRegistrySettings class object to WCF endpoint.