Published on (
 See this if you're having trouble printing code examples

Convergence of Peer and Web Services

by Jeff Schneider

Two of the hottest topics in computing in the new millennium have been peer services and Web services. Although these concepts have a significant amount of overlap, their current manifestations remain very different. In reviewing the types of problems that these systems solve and their method for solving them, it is very possible that the two will converge, producing a single hybrid solution. This statement may seem premature since both technologies remain in early stages; however, after reviewing the impetus behind these offerings, it seems reasonable to predict the convergence of these paths.

A Review of Web Services

Web services are typically described in two ways: the conceptual view and the manifestation view. From a conceptual viewpoint, Web services are an example of a Service Oriented Architecture (SOA). As with most SOAs, there are three main entities:

These three entities work in concert to provide a loosely coupled computing paradigm. The manifestation of this paradigm is through standards, most notably XML, SOAP, UDDI and WSDL. These standards offer the three parties (consumer, provider and registrar) a common language to communicate. Most industry analysts would point out that these technologies offer no real innovation. The industry is excited about the fact that competitors have set aside their differences and agreed on a universal approach to communicating. This new opportunity for business integration has made it attractive for the enterprise to move forward with Web service initiatives.

Perhaps the first wave of Web services is simply building a front end to legacy systems with XML-RPC mechanisms such as SOAP. This means that instead of exposing proprietary APIs from applications such as SAP, we provide an open abstraction layer. This layer facilitates the translation of requests between systems. In essence, corporations are asking that their systems begin speaking the same interfacing language via the mechanisms that have collectively manifested themselves as "Web services." The use of a single interfacing language reduces engineering costs and decreases the amount of time to deploy business-to-business systems. Additional hurdles include defining more advanced "business grammars" and waiting for the widespread adoption of the grammars that exist today.

A Review of Peer Services

The explosion of Napster and other peer technologies has reintroduced the peer-to-peer architecture to the corporate IT setting. Microsoft, Sun and others have quickly been assembling their peer strategies. These efforts are not about the consumer file-swapping systems of yesterday; rather they focus on the needs of the corporation to solve real IT problems. Early applications of peer technology include distributed computing on the edge (or desktops), using peers as a content distribution system, collaborative desktops, as well as several others.

Peer systems also leverage a Service Oriented Architecture (SOA), but they have their own twists. Unlike in Web services, the determination of who is a provider, a consumer or a registrar is much looser. Typically a peer is all three of the aforementioned roles, whereas in Web services a node is typically a producer and a consumer but not a registrar. Most peer systems tend to have strengths in self-healing, resilience through redundancy and very loose coupling through a highly distributed topology.

Comparing Peer and Web Services

Both peer and Web services leverage the SOA. They also define a computing topology and set of communication protocols. They are designed to enable loosely coupled systems often employing layered stacks and referencing best-of-breed protocols. Both have a heavy emphasis on distributed computing and using XML as a means to describe information. It is also apparent that both are at early stages, with significant maturing ahead of them. Despite their similarities, it is the differences that are intriguing.

The Web services conceptual architecture has been defined as having three core stacks: Wire Stack, Description Stack and Discovery Stack

Figure 1. Web Services Conceptual Architecture

This conceptual mapping (as illustrated above by IBM) actually is similar to the one provided by JXTA, the peer-to-peer framework initiated by Sun. The peer-to-peer world has not yet solidified as much as the Web services world. For the sake of comparison, I will use JXTA as a working example of peer services.

Figure 2. JXTA Architecture

At the heart of the JXTA Core are wire protocols, security mechanisms, routing and envelope structures for moving information around. In addition, JXTA defines peer domain concepts like, "What is a Group?" and "What is a Peer?"

The Wire
From a wire perspective, the primary difference between the two is that JXTA must spend significantly more effort on the routing. Generally speaking, servers that run Web services will be well-known hosts, with static IP addresses and will be on the outside of a firewall. In the peer world this is typically not the case. JXTA jumps through hoops trying to get two peers to connect through a potential maze of firewalls, NATs and proxies. This will most likely remain one of the largest differences between peer services and Web services.

Both systems look similar from the security perspective. Features for encryption, hashing, strong authentication, etc., can be found in both systems. The advances and maturing of security libraries are starting to make the same type of features common in most new systems. The JXTA group is taking on the "web of trust" issues, where essentially one peer can loan out its credentials to another peer. This advancement could be significant and might eventually find its way into Web services.

P2P and Web Services Speaker

Jeff Schneider will be speaking at the O'Reilly Peer-to-Peer and Web Services Conference, Nov. 5-8 in Washington D.C.

In loosely coupled systems, having one computer discover another is a big issue. The preferred method of finding a Web service is currently through a central repository known as a UDDI operator. This is a listing of all the published services, kind of like the global yellow pages. In addition, companies can run local versions of UDDI servers for internal services or they can use the ADS protocol (Advertising & Discovery Services) to list the set of services that they offer from a service on their Web site.

Peer systems tend not to rely on centralized systems, preferring instead to decentralize the information. Peers perform discovery in a variety of ways including multicasts, inquiring about services that other peers know about, and using hubs, known as rendezvous, to act as a meeting place for peers with similar interests. It is possible that eventually internal Web services will borrow some of the decentralized techniques from the peer world, while the peers will begin to leverage some of the centralized registries in the Web services world. Both systems have their pros and cons, suggesting hybrid solutions will be valuable as well.

Although the aspect of reliability really isn't part of the standard of either Web services or peer services, their general topology suggests how it will be handled. Web services will most likely use centralized mechanisms to create highly available systems, such as clustered application servers with load balancing and hot swappable services. Peer systems will use distributed peers running the same service in a redundant manner with the first peer that hears about the request responding to the question.

Service Interfaces and Message Protocols
Perhaps one of the biggest differences between peer services and Web services is in the service interface. Web services have gone through great trouble to define a standard way of describing a service through the Web Services Definition Language (WSDL). The WSDL provides a method of describing an interface via XML descriptors. In addition to having a standard way to define an interface, Web services utilize SOAP (Simple Object Oriented Access Protocol) as a standard way for the consumer to send a message to the provider facilitating a remote method invocation in an object-oriented fashion.

Related Articles:

GNOME's Miguel de Icaza on .NET

Hailstorm: Open Web Services Controlled by Microsoft

Mono Unveiled

How We Got From P2P to Hailstorm

The JXTA group has taken a more abstract approach. The initial JXTA implementation used formats similar to the Web services approach, but slightly different. The JXTA team is now going back and making adjustments to the core platform to make peers interoperate with Web services using protocols like SOAP and WSDL. It is expected that the JXTA project will support a variety of communication devices to adhere to the requirements placed on peer frameworks that are required to work in both small and large devices.

Business Standards
In addition to the increasing number of technical standards, we are now seeing a number of business process and transaction standards such as ebXML from the OASIS Group. It is these standards that could very well drive the convergence between Web and peer services.

Generally speaking, the first wave of Web services emphasizes moving information from one company's server to another company's server. However, Web services fail to capture information at the touchpoints -- that is, employees' desktops. This is where peer services enter into the picture. It is likely that we will begin to see more sophisticated business processes that include the employee in the process. In essence, it will be a convergence of intra-business workflow systems and inter-business processes.

From a technical perspective, this means that Web services and peer services begin working closely together. Web services will act as the official company view of the information, while peer services will act as a collection of the employee's view of the information. It is easy to see where Web services will eventually elicit information from each employee's peer services, roll-up the information and then make it available either to the peers or to other company's Web services.


In essence, we are describing how centralized and decentralized systems will come together to provide a more thorough solution to IT problems. It is fair to say that to date, peer systems have concentrated more on their resilient architecture and less on the common communication protocols. From an architectural perspective, Web services have borrowed heavily from well-known centralized computing paradigms and instead concentrated on common messaging formats and industry evangelism.

Figure 3. Integration of business proceseses on combined web/peer service architectures

It is likely that we will see both peer services and Web services rely on WSDL and SOAP for service descriptions and invocations. The two systems will most likely diverge on lookup services, peers using decentralized discovery and Web services using larger centralized approaches like UDDI. In addition, we will begin to see the business process grammars crossing between corporate information and employee information, forcing the two types of services to come together. The convergence of peer and web services is yet another instance of engineers utilizing the right tool for the job, while corporations gain from increased efficiency and reduced handling costs.

Figure 1 was published by IBM at:

Figure 2 was published by Sun Microsystems at:

Copyright 2001, Resilient Edge Inc.

Jeff Schneider is the CEO of Resilient Edge, a provider of peer service technology to ISVs and Fortune 2000 companies.

Copyright © 2009 O'Reilly Media, Inc.