Chapter 8: Building a Discovery Web Service

Overview

In the client-server world, applications are deployed in a static, well-known environment. Database connection strings, server paths, and other location-specific details rarely change, and can often be hard-coded in configuration files (or even application code). Developers and network administrators work in close contact, and the system runs smoothly, day in and day out.

In a peer-to-peer application, you can't take anything about the environment for granted. The first consideration for any peer-to-peer application is how peers will discover one another on the network and retrieve the information they need to communicate. One approach is to create a complex "switchboard" of messages that routes peer requests around the network in a constant low babble. However, there's another approach that's easier to implement (and easier to make reliable). This approach is to use a hybrid design, with a central component that acts as a repository for peer information.

You've already tackled one such design in the second part of this book, where a central coordinator served stored information about peers in a chat system. However, this approach was tied to the Remoting network pointer (the ObjRef), and required a continuously running server application. This chapter presents an approach that's often more robust and scalable, thus replacing the central coordination component with a stateless web service and a back-end database. We'll use this approach to create a discovery service that will support the file-sharing application described in the next chapter.