Along with a significant minority of developers, I never believed that SOAP and WS-* based Web Services were going to be a practical way of constructing loosely-coupled, Internet-scale distributed applications—let alone the architectural answer to everything. (Hint: once people begin discussing the notion that human-readability and -writability are unnecessary as long as there is “adequate tool support”, you know the technology is a big fat expensive dead end.) Now I guess it’s official: WOA is the new SOA.

I have to agree with Tim Bray:

I think we should take the “Web Services” label into the jailyard, strap on a blindfold, give it a last cigarette, and shoot it. It doesn’t mean much any more, and to the extent that it does, it’s misleading: WS-* doesn’t have much of the Web about it.

Long live the Web-style.

While thinking about the differences between the Web and Linda (or REST and generative communication, if you prefer), I found this paper (pdf) from 1999 in which the authors propose replacing the current web architecture with a new one based on a Linda-like coordination language. Despite its dated-ness and a number of flaws, it’s a fascinating alternate vision.

First of all, many of the authors’ claims about the shortcomings of the architecture of the Web will strike current readers as naive. Perhaps they can be forgiven on the grounds that none of Roy Fielding’s work on the architectural style of the Web was published until a year later. Nevertheless, their unsupported assertions about the Web being inefficient and inflexible will no doubt rankle, and the significance they place on increasing performance looks, in retrospect, misguided.

A more interesting critique involves the web’s use of location (URL)–or in present terms, identifiers (URIs)–to address web resources. Since the relationship between a URL/URI and the content or value of the resource is not explicit, search engines had to be introduced to perform the mapping. “This article suggests that the mapping be removed altogether: since the content of the page is what distinguishes it, one should use content as the basis for locating and organizing pages as well.”

A second critique of the Web applies to the constraint of statelessness, noting that in practice the state of a client-server dialogue is maintained through a variety of “baroque” techniques applied on both sides. While it’s well-established that statelessness is a constraint that induces scalability in the Web, it’s also recognized as a trade-off reducing the server’s control over consistent application behaviour.

The athors may have been ahead of their time in envisioning the notion of a service on the Web. They suggest a mechanism whereby servers provide services by manipulating resources through an extended set of operations, and where clients take a more active role by storing their own views of interaction state as resources (as opposed to cookies). This leads them to propose replacing HTTP with a Linda-like coordination language.

Due to its content-addressable nature, Linda allows search-engine functionality to be baked in to the infrastructure. The catch is the requirement for a scalable, distributed tuplespace implementation. The authors don’t discuss the practical challenges to building such a beast, but from a survey of some of their other publications (for example: list of publications by R. Menezes) it’s apparent they are not naive about the issues.

In this “location-free” proposal, services would be represented and discovered via tuples in a distributed space. Each service would then use a unique space to coordinate with clients.

Despite a significant amount of hand-waving, this proposal is an early attempt to develop a web of content-addressable services and documents. It isn’t difficult to add content-addressable messages and application state to this view, increasing visibility of transactions (see Bill de hÓra’s discussion of transactional blackboards).