Service Discovery Techniques Introduced in WCF 4.0

Service Discovery

In WCF or the .NET Framework web services bonding between the client and the service is actually created only when the services are discovered and their proxy reference is added to the client. If the URL of the hosted service is a fixed one, i.e., if it doesn't change over time the service can be discovered by "Add Web Reference" - for Web Services or "Add Service Reference" - for WCF. But for instance what if the service is designed to change its host URL quite frequently? Or what if the service would come on or off the network in a scheduled manner?

WCF 4.0 introduces a couple of service discovery techniques, which the client can use to discover the services dynamically through client probing or service announcement. WCF 4.0 comes up with the ability of dynamic discovery. This feature allows the client to probe for the services or reversely the services can also announce their presence on the network. Below are the dynamic service discovery techniques used in WCF 4.0.

  • Ad-Hoc or UDP Discovery
  • Managed Discovery

Ad-Hoc Discovery

Ad-Hoc discovery follows a broadcast model by sending multi cast request probe messages over the network and the matching services respond back with a probe match response to the client. The probe match response would have the endpoint details about the service.

In order to make a service discoverable, the .net framework 4.0 provides the endpoint class named UdpDiscoveryEndpoint lying under the System.ServiceModel.Discovery namespace. Also the service behavior named ServiceDiscoveryBehavior should be added to the service. From the client perspective, services can be discovered using the class DiscoveryClient. This class is responsible for issuing multi cast messages using UDP protocol. Services can be searched by providing the find criteria such as MaxResults to be returned, contract type, scope, etc. Only the matching services would send back a probe match response to the client.

Dynamic service discovery can be implemented on both the client and WCF service using the configuration file or through code behind. The config file option provides the capability of converting the existing WCF services to be dynamically discovered. Below is the sample code demonstrating the ad-hoc WCF service discovery.

Service Host:

namespace AdhocServiceHost
    class Program
        static void Main(string[] args)
            Uri hostAddress = new Uri("http://localhost:8888/GreetingService");
            using (ServiceHost serviceHost = new ServiceHost(typeof(GreetingService.Implementation.GreetingService), hostAddress))
                //Add a greeting endpoint
                serviceHost.AddServiceEndpoint(typeof(IGreetingService), new WSHttpBinding(), "http://localhost:8888/GreetingService/Greeting");
                ServiceMetadataBehavior metaDataBehavior = new ServiceMetadataBehavior();
                metaDataBehavior.HttpGetEnabled = true;
                //Add the ServiceDiscoveryBehavior
                serviceHost.Description.Behaviors.Add(new ServiceDiscoveryBehavior());
                //Add the discovery endpoint
                serviceHost.AddServiceEndpoint(new UdpDiscoveryEndpoint());
                //Open the host
                Console.WriteLine("Greeting Service Hosting URL: {0}", hostAddress);
                Console.WriteLine("Press any key to close the service");

Client code:

namespace AdhocServiceClient
    class Program
        static void Main(string[] args)
            DiscoveryClient discoveryClient = new DiscoveryClient(new UdpDiscoveryEndpoint());
            //Set the probe criteria
            FindCriteria findCriteria = new FindCriteria(typeof(IGreetingService));
            //Only the first result will be returned.
            findCriteria.MaxResults = 1;
            Collection<EndpointDiscoveryMetadata> endpointCollection = discoveryClient.Find(findCriteria).Endpoints;
            if (endpointCollection.Count > 0)
                GreetingServiceClient client = new GreetingServiceClient(new WSHttpBinding(), endpointCollection[0].Address);
                Console.WriteLine("No matching services discovered!");

This discovery technique is very useful when the service and client are lying in the same subnet. UDP (User Datagram Protocol) is the one that supports sending a multicast message to all on a local network.

Additionally, the WCF 4.0 service discovery feature allows the WCF service to announce its presence over the network.

Managed Discovery

Unlike the ad-hoc discovery, managed discovery can be used to probe for services over a broader network. When I say broader network it includes the internet as well. In the managed discovery model, apart from the client and the service, there is an intermediate element called the DiscoveryProxyService.

It works like this, the service will make the announcement of its current state (online or offline) to the DiscoveryProxyService, which is hosted on a separate server and the DiscoveryProxyService takes care of caching the endpoint details in it. Developers can create their own DicoveryProxyService by deriving their class from the in-build DiscoveryProxy class.

Clients will send the unicast probe message directly to the DiscoveryProxyService and the later takes care of providing the probe match response back to the client based on the service endpoint information that it has cached.

Hope this article was informative. Happy reading!

About the Author

V.N.S Arun

I work for an MNC in Bangalore, India. I am fond of writing articles, posting answers in forums and submitting tips in dotnet. To contact me please feel free to make use of the "Send Email" option next to the display name.

Related Articles


  • Nice Article

    Posted by dhruv rajpoot on 05/09/2012 09:14am

    Can you please write the code for discovery proxy using managed mode. I want to develop a discovery proxy which will use routing table (any collection) to register all the service call and whenever any service is going offline , we can simply delete that service from table. Thanks.

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Moving from an on-premises environment to Office 365 does not remove the need to plan for disruptions or reduce the business risk requirements for protecting email services. If anything, some risks increase with a move to the cloud. Read how to ease the transition every business faces if considering or already migrating to cloud email. This white paper discusses: Setting expectations when migrating to Office 365 Understanding the implications of relying solely on Exchange Online security Necessary archiving …

  • Anthony Christie, the Chief Marketing Officer for Level Communications, is responsible for customer experience, worldwide marketing and product management. In this informative asset, he shares his insights into why a private network connection to cloud-bases applications is the right decision for your enterprise. Download now to find out more.

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date