Peer technologies seek to build vast ad hoc networks and communities around common interests, objectives, or content. Web services provide a common platform through which information and business processes can be exchanged, combined, and deployed across networks. There are interesting overlaps between the two as each seeks to become a common stack for publishing and discovery across networks. This article explores some of the similarities and differences between Web services and peer technologies and highlights key intersect points that enable interesting possibilities when used together.

Web Services Architecture Recap
By now, most of us are familiar with the Web services architecture depicted in Figure 1. That is, the service requestor, service provider, and service broker form a process triad that provide publishing, bindding, and interaction semantics.

As the process indicates, a service requestor identifies one or more UDDI-enabled directories on a network that it can search for candidate services. It's the role of the directory to carry out queries and return service descriptors to the requesting application, which then binds directly to the service in a service-defined manner. All of this happens relatively automatically through the Web service stack.

The service broker exists to separate the details of the service provider from the service requestor and vice versa. This is necessary because the two endpoints can undergo changes in regard to their exact location, protocol, and other binding details. The act of publishing a service in a UDDI requires that it contain the necessary information needed by a client to contact the service directly. It will be the responsibility of the service provider to ensure that published service descriptors match the implementation details of a particular service. For this reason, the service directory is a key component in the dynamic discovery of services, but the emergence of directories will bring a class of problem affecting the efficient discovery of published services.

Registry Fragmentation
It's unclear exactly how registries will be organized across the Internet. Major companies are offering free registry services that you can build your Web service clients to for testing purposes (note: visit www.uddi.org for a complete list of publicly accessible UDDIs). The problem relates to the observation that no single directory will exist to provide discovery for all services. Rather, many UDDI directories will crop up over time as companies with common interests band together to ensure that they can benefit from Web services and seek to endorse reliable facilities and services to make that happen. No one company will provide this reliability.

Also, there are many opportunities for directory-oriented companies to attract service-providing constituents and assist in the formation of new markets around those services. Since many markets seek to benefit from Web services, various directories will probably offer different types, numbers, and qualities of services therein, all in an effort to compete for and establish new service-oriented markets around them.

Registry Specialization
In addition to the natural fragmentation of registries across the Internet, some sectors will seek to build or couple with highly specialized registries where entries of particular interest are kept close together or frequently visited. For example, the financial services vertical might foster directories where only financial services are published and as such, applications and systems in those fields will gravitate towards them, strengthening their position in the process.

As specialized registries grow in popularity, they become more valuable to the constituents and the cycle continues, possibly weeding out inappropriate or irrelevant services along the way. This sort of refinement is much how we see things evolve around us, in nature and the complex systems of which we are already a part. In addition, corporate mergers/ acquisitions seek to unify similar assets, markets, and revenue, perpetuating this trend.

A force resisting a single registry for all services will coexist with the forces unifying vertically aligned registries as well. The two forces simultaneously seek to bring together and to separate. This fractal phenomenon repeats itself on many scales. Vertical sectors will have a variety of registries that serve their community as a whole. Applications and services can be published and hosted throughout the network and used on demand. However, the same problems repeat themselves on this scale as well. Namely, how do service requestors (applications, systems, or people) know where to look? Even as registries unify or multiply, these forces cause disruptive changes regarding where applications can expect to find them.

Since UDDI services are provided on some fixed port address, it must be known in advance of the request (on the client) so the requesting applications can attach to the registry at request time. The precise knowledge about which registries to search will have to be managed and disseminated to client applications. That process carries not only the logistical burden of doing it, but also the legacy burden of maintaining it. It would be nice if these burdens could be diminished. One possible solution is to disseminate that information separately from the client application, instead placing the burden on users to acquire and input the addresses of directories they wish to search. However, leveraging the qualities of peer networks might offer another approach.

Qualities of Peer Networks
Peer networks like Gnutella and Freenet bear a unique quality that sets them apart from other peer networks ­ they are truly distributed. Unlike Napster, which is a brokered peer network, networks like Gnutella have no central index or server. Rather, they operate collectively across all nodes in the network.

Searching a true peer network results in a request that seeks across the nodes of the network until most or all nodes are reached. Much like ripples in a pond, these searches fan out, seeking routes to unvisited nodes and maximizing their radius. However, the algorithms require the search to acquiesce after a certain number of "hops" have been reached. They do this to avoid lengthy search times and ping-pong effects where nodes are accidentally visited multiple times. Depending on the topology of the peer network, this has little effect on the precision of a search, but in general, peer networks operate best when highly connected ­ a term used to described the nature of the network graph.

The benefit of these complex search algorithms across interconnected networks is that the requestor and the provider do not need a priori knowledge of one another. This is true even in Web services, but the knowledge of the provider has been displaced somewhat by the knowledge of a given repository.

Peers in peer networks behave like model routers in that they receive and forward message traffic from and to their neighbor peers. Much like network traffic routers, they operate independently on one level, yet collectively on another. This offers a strong degree of resilience as traffic can be routed and rerouted in numerous ways to ensure maximum exposure or endpoint reliability as well as discovery. The Gnutella protocol is based on a simple "find a friend" paradigm. It requires only that a given peer know of at least one other peer to send and receive messages across the entire network.

Leveraging P2P and Web Services
Both Web services and P2P computing models provide a discovery process. Current peer networks focus more on the discovery of content in the form of common files published with metadata. The content served by a UDDI repository is metadata describing Web services. However, where peer networks serve their content in a highly distributed fashion, UDDI provides a central discovery mechanism for service provisioning. One intersection between P2P and Web services involves bringing the decentralization aspect of P2P to the central service discovery aspect of Web services.

In a decentralized peer network, content is described and indexed locally to a given peer. Since each peer acts as a tiny router, forwarding and responding to search queries as they pass through, it has an opportunity to address them in a peer-specific way. Thus, each peer qualifies the search criteria against its locally maintained database and responds accordingly. In this model, no centrally managed index is required to span the network. Peers are interconnected and forward traffic in optimized ways that span all nodes.

Peer Services: Peer-based Web Service Provisioning
It's not difficult to envision a class of peer networks that promote the decentralized searching mechanics we've discussed but provide Web service descriptors as their content just like a UDDI. In this way, any client can specify the criteria for a service candidate and fire it across the network. The search will ripple across the peer nodes and responses will feed back to the originating client. Thus, no additional effort or knowledge is needed by a search client to increase its chances for a match, the peer network absorbs this responsibility. Nor does the service provider need to know in advance where best to publish its service to increase its exposure.

Using this highly decentralized approach, service providers can themselves become peers in a vast network of Web service providers, or peer services. Queries for services pass directly to service providers who can easily maintain the qualitative data associated with their service, including the number and types of services they wish to offer. Because the peer network is dynamic and not a cached or indexed searching scheme, information discovered at any given moment is likely to be current and availability higher than if discovered statically through a broker.

Peer Directories: Clustering Directory Services Using Peer Technology
We can see that the process of publishing and discovery can be mapped from a static, central model to a dynamic, decentralized one with the benefit of freeing applications and services from static address logistics and maintenance. However, there are degrees of centralization that can mitigate between the qualities of centralization and decentralization. For example, rather than require all peers to publish their own service descriptors (locally), you can employ a federation of UDDI-enabled, peer registries that operate in a decentralized way, yet do not directly provide the peer service implementation. In this way, UDDIs can join and leave a dynamic federation of directories. Such federations might indeed represent common interest groups and verticals as we mentioned earlier. Using peer technology, the general topology and addressing of registries in the federation can be concealed from the endpoint client performing a search. Figure 2 shows us what such a clustered federation of directories might resemble.

Figure 3 shows the binding process, which occurs as before ­ directly between the provider and requestor. Publishing is done locally to each service broker/directory and queries are propagated among them. Once service information is discovered, the registry is no longer needed and binding can occur immediately.

It might also be the case that service registries provide information pointing to additional registries. Peer technology can be embedded within registries to cooperatively respond to queries. In contrast to a federation of registries, this approach allows a client to access a single registry that has the scope of many. The difference is centered on what the client knows and how it behaves. In Figure 3, the client knows less and provides mechanics for sending queries across the peer federation. Figure 4 shows the client accessing a single registry and finding a service in another registry that was discovered at query time.

Service and Registry Syndicates
The ability to form ad hoc federations of services (peer services) or directories promotes the formation of service-oriented syndicates. Service syndication seeks to promote in-demand services by offering them throughout the federation, not just at one location. This also increases the reliability and availability of the service, since it can be acquired and bound to from a variety of providers. The incentive is such that use of the service benefits the syndicate members regardless of who provisions the service, since that responsibility is now distributed.

Probably more practical will be the syndication of directories (or registries). This too will benefit the reliability and availability of the discovery process. Regardless of whether a particular service is online or not, if it isn't visible in a particular broker it might not be found. To help this, UDDI federations will share or cache service descriptors or references to one another such that clients can either discover the remote registries directly or simply search them all at once using a more peer-based search algorithm.

Practical Issues
There are certainly many issues that need to be resolved before peer technologies can exist peacefully within corporate boundaries and even more so for Web services. Security is still the number one concern, as companies want to ensure that the forthcoming automation doesn't leave them vulnerable to malicious attack or unauthorized use.

For peer networks, the lack of central control is also a big concern. The blessing is also the curse. Finding an acceptable balance between centralization and decentralization is key, yet any approach must justify itself against the benefits, the cost, and the need.

That peer networks are highly distributed doesn't mean that they can't be centrally controlled. Networks are highly distributed, yet companies have found ways to manage their private networks and secure them from trespassers.

From an authentication perspective, businesses will have to resolve how they intend automatic or anonymous interactions to occur, even if (and especially if) there are usage fees involved. The idea is to let the wanted people through, and none of the unwanted, ie., not to hinder the expansion of their e-commerce.

Conclusion
In this article, we've explored the basic architectures of Web services and P2P systems. We also looked at ways in which Web services discovery can benefit from P2P decentralization. At first, it seems that searching UDDIs across networks is a key point of development for merging these two computing paradigms. In the future, directories may not even be required as service providers publish their own services (peer services) in the same way that you would expose content on their computer for sharing across FreeNet or Gnutella. It's quite certain that many issues will need to be resolved before such an approach would gain corporate appeal, but the technology pieces are ready and the new frontier of peer-based services lies ahead.

Author Bio
Darren Govoni is a Distinguished Engineer at Cacheon (www.cacheon.com), where he writes and mentors on subjects such as P2P computing, Web services, and component-based development and assembly. Darren's past research at Metadapt, a company he founded, is the basis for Cacheon products. dgovoni@cacheon.com.