Programming WCF Services, 3rd Edition

Appendix C. Discovery

All the WCF calls demonstrated throughout this book share two constraints. First, the port or the pipe assigned to the service must be available. The application developer or the administrator literally has to guess or have some way of knowing the port or the pipe is not used by any other application on that machine. TCP port sharing can alleviate this problem, but does not help with the second constraint: the client must a priori know the address of the service endpoints—not just the port number or the pipe name, but also the name of the service machine (in the case of TCP).

It would be great if the service could use any available address, decided upon at runtime. In turn, the client would need to discover that address at runtime. In fact, there is even an industry standard-based solution that stipulates how that discovery takes place. That solution, called simply discovery (and its supporting mechanisms), is the subject of this appendix.

Note

Discovery is not a new idea, and veteran developers have often opted for not embedding the type of the class to instantiate in their code and instead resorted to a class factory to resolve or discover the actual type supporting the desired interface:

IMyInterface obj = MyClassFactory.CreateInstance<IMyInterface>();

In WCF, since the client always programs against the interface or the proxy, the address of the service is analogous to the type of the implementation class in regular .NET programming. Address discovery is therefore ...