Recently I have fielded questions from customers like, "Which is better, peer-to-peer or Web services?" and "Do you think I should move from Web services to a peer-to-peer network?". The answer is another question: "Which approach best suits your solution?". This tends to make the customer think about system requirements a little more, so that once an interaction model is better defined a more informed choice can be made.

This article provides a solution developer with some of the facts about both P2P and Web services so they can make that informed implementation decision.

Web Services
Most of the current solutions under the title of Web services have a number of elements that are common to their construction. For communication, they use XML to format their messages and deliver them over HTTP. If an interface language is required, another XML syntax called WSDL is used. To deal with the bootstrap issues associated with service and endpoint discovery, clients may access a public UDDI database. This basic framework allows clients to discover and communicate with a service on the public network. Of course, behind the scenes there is an implementation technology that may range from a couple of Java servlets to a full CORBA with services deployment - but the choice is usually constrained by definite factors, such as cost and skill levels.

The characterization of the Web service operation is the classic client/ server model. The software fulfilling the role of the server will register with a centralized but replicated datastore. Software that fulfills the role of the client will contact the datastore to discover the server location and can then contact the server. The mechanism to ensure that the client and server can speak intelligibly to each other, or interoperate, is enforced by well-known standards. This is a straightforward approach to distribution with the advantage that clients are coupled to the servers only by a software contract. Since the contract is fully described, using WSDL for instance, developers can construct clients using the contract information. To set up a stall on the public network, all a developer must do is make a server available at a URL, publish the contract, and advertise.

Enterprise Analysis
Scaling: A large number of clients can swamp a central server, add more servers, implement load-balancing strategies; this may be costly.
Failing: A single point of failure can be catastrophic, add more servers, and implement clustering and standby strategies; this also may be costly.
Security: A single point of data access simplifies access control and authentication.
Integrity: A single logical datastore simplifies enforcing ACID properties.

P2P
Peer-to-peer solutions currently have a different technology usage profile from Web services, but there is no reason why P2P solutions can't use the same XML technologies that Web services use. Centralization of resources is anathema to P2P networks: each participant in the network is equal to every other participant.

The characterization of a P2P network is the peer-to-peer communications model. Each functional unit in the network is behaviorally similar. There is no fixed role for a peer as there would be with the client/server distribution paradigm. Peers may do exactly the same thing or there may be transient role assignments. The key element of a P2P system is the peer algorithm, the programmed behavior that makes the system fulfill its intended purpose. The algorithm enforces a logical network topology by defining the concept of "neighboring" peers. The neighbor relationship enables the flow of the essential data in the network, a vital requirement in a system with no central data resource. The fact that the network may be a fluctuating and dynamic one, with peer neighbor relationships breaking and reforming as the load or infrastructure stability changes, is the core attraction of P2P systems.

Unlike Web services, where the client and server roles mean the system deployment requires two separate pieces of software, P2P networks have just one deployable software unit - the peer code. If the peer algorithm can provide for it, P2P networks are easy to extend.

Enterprise Analysis
Scaling: More peers means more work is done cheaper - organizations may deploy peers on many inexpensive machines.
Failing: All peers are behaviorally similar, so there is no functional loss - just make sure that the network algorithm replicates the data.
Security:Difficult unless a peer trust system is established as a simplifying assumption.
Integrity: Can be tricky unless each peer can enforce local ACID properties; lag between nodes may contribute to out-of-date information.

Summary
The Web services versus peer-to-peer comparison is really about two fundamental distributed processing approaches. Each has a network and a way of processing nodes on that network. Indeed, when you look at the details from a node/network abstraction, it's easy to see that a peer-to-peer network that publishes a software contract may actually implement a Web service and similarly a peer-to-peer network may be composed of Web service-style client/server nodes. Choosing an approach is just a matter of matching your requirements with the features each solution provides.

Author Bio:
Oisin Hurley has been involved with distributed objects since 1989. His initial exposure to the field was research into operating system and compiler support for distributed objects. He joined IONA in 1993 to work on the world's first CORBA implementation and since then has worked as a consultant and engineer in the areas of CORBA, J2EE, and Web services. When not developing code, he represents IONA in the OMG, JCP, and W3C standardization activities. ohurley@iona.com