Decentralized Web Services
David Wallace Croft
Senior Java Architect
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.
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.
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
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.
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