WCF 4 Step By Step Chapter14 Note 1 (Discovering Services)

an endpoint specifies three pieces of information: an address, a binding, and a contract.  The address indicates  where the message should go;  the binding identifies
the transport, format, and protocols to use to communicate with the service; and  the contract determines the  messages that the client can send and the responses it should expect to receive.It is possible for more than one service to implement the same contract, and it is also possible for a service to change its address.  If a client application has the address of a specific service hard-coded into its configuration, then  if that service moves, becomes temporarily unavailable, or is just too busy to handle requests, the client will not be able to communicate with it.  WCF provides discovery and routing to address these issues.

Implementing Discovery
WCF discovery is an implementation of the OASIS WS-Discovery specification. This feature enables a client application to locate a service dynamically, based on criteria such as the contract that the service implements. The location of the service can change, but as long as a service is discoverable, a client application can find it and connect to it.

With WCF, you can configure a service to support discovery simply by  enabling the discovery behavior and adding a preconfigured discovery endpoint to the service.This endpoint is called  udpDiscoveryEndpoint and is an example of one of several standard endpoints implemented
by WCF.

Server:



Client:

DiscoveryClient client = new DiscoveryClient(new UdpDiscoveryEndpoint());
            FindCriteria productsServiceFindCriteria = new FindCriteria(typeof(IProductsService));
            FindResponse productsServices = client.Find(productsServiceFindCriteria);
            client.Close();


            EndpointAddress productsServiceAddress = productsServices.Endpoints[0].Address;
            ProductsServiceClient proxy = new ProductsServiceClient();
            proxy.Endpoint.Address = productsServiceAddress;

Handling Service Announcements
Discovery is undoubtedly a very powerful technique, but ad hoc discovery can be a little time consuming and frustrating in a client application;Ad hoc discovery can also be very network unfriendly, especially if you have a large number of clients in your organization; each time they connect to a service they will broadcast Probe requests across your network.  One possible solution to these issues is to handle announcement messages.

A service that supports discovery “announces” its presence to the world  when it starts up by broadcasting a multicast message over a well-known address. Client applications can listen for these multicast messages and capture the details of the service in a local collection acting  as a cache (the address of the service and metadata describing the service is transmitted as part of the announcement). When a client wishes to send a message to a service, it can look up
the address of the service in its local collection. The client can then connect to the service and invoke its operations, as before. Similarly,  when a service shuts down, it broadcasts a shutdown message. Client applications can capture these messages and use the information to remove the details of the service from their local caches.

In this case, the onus shifts from the discoverable service to the client applications.  Clients no longer send Probe messages to the service, and consequently, the service does not need to implement a discovery endpoint. However,  you need to modify the service to send announcement messages as it starts up and shuts down.
WCF makes this easy; all you need to do is add a  udpAnnouncementEndpoint standard endpoint to the serviceDiscovery behavior element. The WCF runtime does the rest.

Server:



Using a Discovery Proxy
The use of service announcements can reduce the volume of network traffic associated with large numbers of Probe and ProbeMatch messages,  but what happens if a client is not running when the service starts up?The answer is that it will miss the announcement messages and will not be aware of the service, so it will not be able to connect to it. The solution is to use a hybrid combination of discovery messages and announcements;  build an intermediary service that lives at a well-known address that listens for announcement messages from other services and caches them. Because the intermediary service lives at a fixed, well-known address, clients do not need to broadcast Probe messages to the world at large; instead, they can send them in a unicast manner directly to the intermediary service.

In WCF, the intermediary service is known as a discovery proxy. Furthermore, the System. ServiceModel.Discovery namespace contains an abstract class called DiscoveryProxy that you can use as the basis for building one these services.