Decentralized Web Services

Abstract

At the first meeting of the Web Services Java Users Group last night, I found myself challenging the speaker on the need for WSDL and UDDI, that is, the ability for distributed services to describe their interfaces and advertise the availability of those services via a central registry. Some time ago, I had decided that the JavaSpaces architecture, based upon the concept of tuple spaces, was superior to that of Jini. The standard UDDI/WSDL Web Services story is like Jini with the only change being that of using XML over HTTP instead of RMI. I advocate that developers avoid UDDI/WSDL and instead look to the JavaSpaces equivalent by exploring JAXM.

Coupling

In Jini, a service that implements a particular interface, such as the Printer interface, advertises its availability with a centralized registry. Those applications that need the services of a Printer will start by querying the registry. They are then given the addresses of zero or more services that meet their requirements. The applications, having pre-programmed knowledge of how to interact with an object that implements the Printer interface, will then initiate a synchronous remote procedure call to the service.

In JavaSpaces, services do not have interfaces. Instead, they subscribe to a broadcast medium, a "tuple space". An application seeking service will publish its request, such as a print job, to the medium. When the services see the published request, they, being knowledgeable of their own capabilities, will decide whether to service it. For example, a service may print the print job or respond with a bid to print it as appropriate.

In the Jini architecture, you have tight coupling in a number of ways. The first is that both the application and the service must be up and running at the same time in order for the service to receive the synchronous remote procedure call from the application. The second is that the application must be programmed to interact with the interface of the service. If the interface changes, the application breaks.

In the JavaSpaces architecture, you have loose coupling. An application process can broadcast a request and then terminate. Some time later, a service may come online and download the request. This is said to be loose coupling in both "time and space" in that the application and service do not need to be connected simultaneously and the application never needs to know the address of the service in order to make that connection. Also, since all communications are message-centric instead of interface or protocol based, applications do not need to be programmed to a particular interface or protocol. As there are no interfaces or protocols to change, the application does not break.

Decentralization

Some argue that the centralized registries can provide a "smart" service to applications by filtering and selecting the services on behalf of the application based upon some criteria. The analogy is that of a web search engine which responds to a user query with a prioritized list of web addresses. We know from experience, however, that the results from such portals are often biased in favor of those services that pay the highest listing fee. We also know that the dominant web portals have the ability to censor or substantially deprioritize the listings of their competitors. Realistically, we should expect similar tactics from any future centralized registries of Web Services.

The alternative is a decentralized business-to-peer (B2P) approach in which each peer, acting as an agent serving its own best interests, maintains its heuristics internally as a self-contained unit. Each peer, as a service, a consumer of services, or both, publishes and subscribes to a decentralized broadcast medium. As requests and requests for proposals (RFPs) are published, the services themselves, not a centralized facilitator, decide which tasks to accept or bid on. Consumer applications, having received responses from a number of distributed services, then use their own private and internal business logic to decide which bids to accept or whether further negotiation is warranted. This is decentralized e-commerce.

Implementation

In my talking notes entitled Tuple Spaces, I proposed that the Java Message Service (JMS) API, an abstract layer over a publish-and-subscribe message-oriented middleware (MOM) system, provided a better Java implementation of tuple spaces than did JavaSpaces. What was lacking at the time was the ability for applications and MOM implementations to transfer messages to and from other MOM implementations from different vendors using some non-proprietary standard. This was resolved with the release of the ebXML Message Service specification. Just as the JMS API provides a Java abstraction over MOM implementations, the Java APIs for XML Messaging (JAXM) provide a Java abstraction over the ebXML standard.

I recommend that those Java developers interested in promoting a future for decentralized Web Services start by introducing themselves to JAXM and the work of the ebXML. For my part, I am currently prototyping a decentralized consumer-to-peer (C2P) platform I call Agoracast as an Open Source Java project which I hope to extend later to encompass the domain of B2P Web Services.