Sharing structured data

XML Magazine

Subscribe to XML Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get XML Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

XML Authors: Jayaram Krishnaswamy, Chris Pollach, Jason Bloomberg, Peter Silva, Mehdi Daoudi

Related Topics: XML Magazine

XML: Article

What Can Web Services Learn From P2P?

What Can Web Services Learn From P2P?

Both peer-to-peer (P2P) and Web services are attempts at decentralizing computing. P2P is more mind-set than technology, an attempt to weave the world's intermittently connected machines, into the fabric of the Internet. Web services are a more formal technological challenge, an attempt to apply the Web model for publishing - loosely coupled components with a simple request-and-response model - to computing, using XML in place of HTML.

It's easy to see how Web services are affecting P2P, as many P2P companies are adopting Web services standards, such as defining their document formats in XML or exploring the use of UDDI as a P2P Registry. But what can Web services learn from P2P? The development of P2P applications has three lessons for Web services developers.

HTTP isn't the only transport
Much of the Web's success can be traced to HTTP, which struck a careful balance in its synchronization between client and server. HTTP operates in real time but is stateless, which allows for tight coordination between a browser and a server, with very little overhead.

This trade-off, though, isn't the correct balance for all possible means of communicating. In particlar, HTTP is inadequate at either extreme of synchron-ization requirements. P2P Instant Messaging systems like ICQ and Jabber need their own protocols to manage the kind of flexible two-way stream required for instant messages and chat. At the other end of the synchronization scale, where requests to remote machines need to be batched or will take longer than a couple of minutes to execute (such as complex database interactions or requests that require significant computational modeling on the server), HTTP is also inadequate. Many P2P systems, like 3Path and InstantPowers, have adopted SMTP, the e-mail delivery protocol, to send asynchronous messages between nodes.

P2P demonstrates the range of services that can be built on top of alternate protocols, and since applications like Jabber and 3Path can handle XML natively, they're ideal for adoption (and adaptation) for Web services that need either tighter or loooser integration between client and server than HTTP allows.

DNS is not the only addressing scheme
A central problem for P2P apps is how to address resources on PCs that have no permanent IP address and are therefore outside the DNS system. The typical P2P solution has involved a directory of user-created addresses, continually remapped to the user's current IP address, as with Napster or Groove. These systems have evolved into something more than just a dynamic replacement for DNS, though. In many cases P2P addresses are for resources other than the machines themselves. A Jabber address (or indeed any IM address) points to a person, no matter what machine they are using at the time, while systems like Freenet and MojoNation point to addresses for pieces of content, irrespective of what machines it is on. For Web services, alternate addressing schemes mean that a Web service could be accessed at a Jabber ID rather than a domain name, and could listen for remote calls packaged as instant messages. Likewise, a Web services client that knew how to interoperate with P2P file-sharing networks could extract a piece of content by its address without knowing where that content lived.

Don't divide the world into client and server
On the Web the roles of client and server are largely fixed - Yahoo is always the server, your browser is always the client. In P2P systems, those roles are temporary, with the same machine performing some of the functions of a client and some of the functions of a server, often at the same time. In the Gnutella network, for example, PCs act as servers for remotely requested files and as routers for other users' requests. This lack of permanent distinction is reflected in the naming schemes of P2P systems, where the software running on the user's computer isn't called a client but a "clerver" or a "node" or a "tranceiver."

Because Web services clients and servers can both send and receive structured XML, clients can act as servers, and vice versa. P2P has demonstrated the immense value that can be created when groups of machines, act as both client and server, and Web services that adopt the same attitude can create new functions in which:

  • Jobs are shared across multiple clients.
  • Central databases, typically thought of as servers, can initiate requests to remote PCs.
  • Clients message one another directly, without needing any central server at all.
Though Web services attempt to broaden the success of the Web into the domain of networked applications and business processes, the success of P2P demonstrates ways in which their broad goals - automatic communications using structured documents - can be supported, without conforming to the narrower technological dictates of the Webs.

Web services can operate with more or less synchrony than the Web by passing XML documents over other protocols like Jabber or SMTP. They can access a greater range or resources more directly by using non-DNS addressing schemes for entities like people and files. And Web services can provide a greater range of behavior between nodes by loosening the distinction between client and server. By adopting the work P2P systems have done in these areas, Web services can become a more flexible and ultimately more valuable technology.

More Stories By Clay Shirky

Clay Shirky is a writer and consultant on Internet technologies, focusing on the rise of decentralizing technologies such as peer-to-peer and Web Services. He is currently teaching a class entitled "Thinking About Networks" at NYU's graduate Interactive Telecommunications Program (ITP) and has written for the original Business2.0 and FEED magazine, as well as writing occasional pieces for the New York Times, the Wall Street Journal, and the Harvard Business Review. His earlier work appeared in Silicon Alley Reporter,, Urban Desires, and net_worker magazine.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.