What Can We Achieve by Combining Web Services with P2P?

To understand the benefits of operating Web services over a P2P infrastructure, we will first analyze the current Web services model.

The Web Services Usage Model

We introduced the three Web services' interoperability stacks in Chapter 11, "Web Services Explained" (the wire stack, the description stack and the discovery stack). Let's analyze the usage model of the three stacks by considering an example. Suppose you want to find a particular service over the Internet (for example, you want to get the freight charges for sending a packet from source to destination).

Whenever you need a product or a service, you will go through the following three steps:

You need to know who is offering the product or service. This is a search, or discovery, operation. The result will be a list of service providers. Universal Description, Discovery, and Integration (UDDI) is meant to cover this stack.
When you have discovered the service provider, you will need to understand how to talk to the service provider. This is the service description stack that is essential in all e-business. If software components don't know what language to speak while talking to other components, they will not be able to communicate. The Web services Description Language (WSDL) covers this description stack.
When you know what language to speak, the last step is to talk to the service provider to invoke the service. This is the service invocation or wire stack, covered by Simple Object Access Protocol (SOAP).

These three stacks are independent of each other, meaning you are not required to follow all three steps. You will use only the step that you think is necessary for you.

For example, if you already know who is offering the freight service, you will not need to do any searching and can move to the service description domain directly. Similarly, if you already know what language to speak while talking to service providers, you can invoke the service directly.

Client-Server Interaction in the Current Web Services Model

Currently, all Web services-related technologies and major implementations depend on the client-server model. An example of client-server interaction in Web service applications is SOAP operating over HTTP. Recall the details of SOAP from Chapters 11 and 12, where we elaborated upon the SOAP structure, as well as the request-response mechanism in SOAP. SOAP clients author SOAP requests to invoke the Web services hosted on SOAP servers. SOAP servers, on the other hand, invoke the Web services and author SOAP responses, which are sent back to the SOAP clients.

This only proves the inequality of communicating parties in SOAP. The responsibilities, and therefore the capabilities, of SOAP servers and clients are different. This is analogous to the well-known client-server interaction between a Web server and a Web browser.

As explained in detail in Chapters 11 and 13, UDDI operates over SOAP. Therefore, UDDI also essentially follows client-server interaction, where UDDI servers are registry operators, and UDDI clients are the Web service publishers or users who want to publish or find Web services.

P2P Messaging Model

Imagine the tons of data being loaded on popular search engines today. UDDI registries provide standard APIs to perform the same publishing and search features that search sites like Yahoo! or MSN offer.

The amount of data that conventional proprietary search engines and standard UDDI registries handle is enormous, and growing. However, it is practically impossible for any search facility to do smart searches related to every subject and every topic.

A better way to manage this enormous amount of data is through distributed content management. Content related to any single subject will be handled by the experts of that field. There is really no requirement of central search facilities such as UDDI.

That's one of the ways in which P2P is different from the conventional client-server model. Every peer will manage its own content, search for data of its interest, discover other peers, and respond to search requests. This gives rise to the equality of peers in responsibility and capabilities.

We will use JXTA as a sample P2P infrastructure to demonstrate P2P Web services later in this chapter. As explained in Chapter 16, "JXTA and XML," JXTA has introduced the following major concepts to accomplish a peer-to-peer messaging framework:

Peers Everyone taking part in a JXTA network is a peer.
Peer groups Peers can join other peers having common interests to form peer groups. Every peer is free to join as many peer groups as it wants.
Rendezvous services A rendezvous is a meeting point for peers. This concept plays a very important role in the JXTA network. Peers can voluntarily chose to act as rendezvous. If you know a few rendezvous points, and some of the rendezvous points know other rendezvous points, you can reach every peer connected to this arrangement. The JXTA infrastructure handles all of this application developers are not required to handle these core issues.
Pipes and end points Pipes are logical communication channels capable of routing messages from source to destination. The source and destination are referred to as end points.
Discovery, advertisement, and search services Peers can advertise their resources (like pipes listening to requests related to particular topics) and search for resources exposed by other peers.