Accessing Web Services

How do you apply the XML, SOAP, UDDI, WSDL, ebXML, and messaging concepts to P2P applications?

Can you develop applications that expose Web service interfaces over the P2P infrastructure and use SOAP to expose your P2P Web service interfaces? There is no conceptual problem in doing this. Chapter 20, "Using SOAP with P2P," demonstrates how to use SOAP over P2P networks.

You can also go one step further. Recall that WSDL is the grammar used to describe Web service interfaces, and UDDI tModels represent technical fingerprints. You can describe the interfaces of your applications using WSDL, and you can also publish your P2P Web service applications as technical fingerprints using the UDDI tModel structures.

This means that you can publish your P2P Web services on an XML registry like UDDI, search for P2P Web services published by other peers, describe your P2P Web services using a grammar such as WSDL, and bind your P2P Web services with concrete implementations using a binding mechanism, like SOAP.

For example, let's consider an application scenario in which a company has already written its WSDL interfaces, hosted its Web services on a SOAP server, and published all the relevant information and documents on a UDDI registry (or probably an ebXML registry). Now the company has come across a prospective customer base in a community of peers sharing a P2P infrastructure. The company would like to expose its existing Web services to the community of P2P users. For this purpose, the company will be required to do the following:

1. Publish new binding information for its existing Web services on the UDDI (or ebXML) registry. This new information will be in addition to the information already published, so the existing Web services will continue to serve as such. The new information will establish new service end points. For example, the old service end points were SOAP-based (they were pointing to the company's SOAP server); the new end points will point to some P2P resources (for example, in a JXTA network, pipe end points can be used as service end points. Refer to Chapter 16 for details on JXTA).

2. Create appropriate listeners for the P2P infrastructure, which will receive service invocation requests from peers, translate the requests to appropriate SOAP format, send the SOAP requests to the existing SOAP server, receive responses from the SOAP server, translate the SOAP responses back in a format acceptable to P2P users, and send the responses back to the requesting peers. This way you can get the benefits of P2P architecture over the conventional client-server model, as well as simultaneously integrate your loosely coupled Web service components into a global P2P-based Web services model.