« Writing Servlets with Jython tutorial | Main | Progress »

ABOUT / HTTP/1.2

The discussion on the intersection between Web Services and REST continues, but a passing aside may hint at an equally important issue for Web architecture.

Vorsprung durch einfachheit

Don Box:

Had we started with a simpler basis (perhaps Relax NG + some SOAP-specific extensions), my guess is we'd be having different discussions right now.
- Don Box, Correcting MNot

The purist's rebuttal to this is that there was enough programming and networking art at the time to have known that starting with a simpler basis was the right engineering option. The paranoiac's rebuttal is that a sufficient complexity was deliberately chosen to control the rate of decay of an industry's already dying business models. Neither is true. IT evolution is slower and more gradual that most in and observing of the industry would care to acknowledge. True technical disruptions are in fact rare and most are noted as such after they have happened not during. While it may be obvious at a very high level that things can and should be simple (the uniform interface is an idea with long-standing in computing and networking circles), in the cut and thrust of systems building it's easy to lose track of this against more immediate concerns. And while there is unquestionably a revolution underway in IT business models, it beggers belief that sworn competitors preside in smoke filled rooms collectively making arrangements to fleece the world's customers through web services standards.

Objects and uniformity

Mark Baker observes that part of Don Box's sample object interface isn't required:

P.S. java.lang.Object already has Get() - it's called toString().

Perhaps, but perhaps not. Granted, arguing against the completeness of uniform interfaces because object languages don't usually have them is not a convincing argument against using uniform interfaces in protocols, in much the same way arguing against the completeness of wave functions because Newtonian physics has only a physics of billiard balls is not a convincing argument against wave functions in quantum theory. The physics are sufficiently different that the metaphors break down. As for Java, this is the uniform interface:

    public class Object
    {
      protected Object  clone();
      boolean equals(Object obj);
      protected void finalize();
      Class getClass(); 
      int hashCode(); 
      void notify();
      void notifyAll(); 
      String toString() 
      void wait(); 
      void wait(long timeout);
      void wait(long timeout, int nanos); 
    }

Now, no-one in their right mind would base any interesting Java application semantics on toString; its idiomatic use is for diagnostics and printing. HTTP GET is an entirely different beast to toString - again the physics are sufficiently different. The Javaspaces API however is closer to Don Box's intent, and represents a uniform Object interface in use today:

  public interface JavaSpace 
  {
    Lease write(Entry entry, Transaction txn, long lease);
    Entry read(Entry tmpl, Transaction txn, long timeout);
    Entry readIfExists(Entry tmpl, Transaction txn, long timeout);
    Entry take(Entry tmpl, Transaction txn, long timeout);
    Entry takeIfExists(Entry tmpl, Transaction txn, long timeout);
    EventRegistration notify(Entry tmpl, Transaction txn, 
      RemoteEventListener li, long lease, MarshalledObject handback);
    Entry snapshot(Entry e);
  }

As Patrick Logan has observed , the problem that most object languages and most protocol languages are seeking to solve is different. Protocol verbs are concerned with coordination between entities rather than the functional composition and depedency management issues most object models are concerned with. Javaspaces is representative of what a coordination protocol looks like in API form - your business object representation of a customer may be very different.

What about you?

Finally, from Mark Nottingham's original entry, an aside that hints at an important issue that has not be discussed to date:

MEX is the first spec to use WS-Transfer, and it cant help but define a GetMetadata method to go along with Get, instead of splitting things up into separate resources.
- Mark Nottingham, POST

Accessing the metadata for a Resource (the thing a URI names) is a open issue for the web architecture, one that tends to get drowned out by more colorful but inconclusive and less useful discussions around pseudo-philosophical arcana as can been witnessed currently on the W3C's Technical Architecture Group's mailing list (the TAG as it is known, is the Group di tutti Groups within the W3C). However, it's not clear that declaring a second resource as the metadata resource for another resource is a workable or desirable option. For one it's intellectually frustrating in a Goedelian sense. More importantly it bifurcates resources into those that return representions that are about themselves and those that return representions that are about things other than themselves. This possibly only really matters when machines are expected to be able to disambiguate between the two under the current architecture (for the most part, people don't have a problem functioning with such ambiguity).

Patrick Stickler of Nokia has done enough work in this area to be satisfied that a new verb (one he calls MGET) is needed to inquire of a resource's metadata on the basis that distinguishing between representations of resources and metadata about resources using the HTTP entity body mechanism is ambiguous and/or inefficient. Stickler is prone to using emotive language calling any clients that need to use two resources (or two or more HTTP operations) to figure things out "second-class citizens"; and while an established consensus around the idea of this other verb has not arisen, the technical analysis seems comprehensive enough. There are other options such as adding a qualifying header that contextualizes the representation as being representation or metadata; there are those who think it doesn't matter and the current model will do fine.

This metatdata about issue may become apparent as more code is written to direct goal-oriented activities online of behalf of users rather the interactive data/state transfer we see today - the difference between code that actively monitors Ebay and bargains on your behalf and code that sends your holiday snaps to your weblog. While there was unjustified hype around such 'agents' during the 1990s, we are arguably reaching a point where the underlying network infrastructure and data formats are approaching a level of sophistication sufficient to support highly rudimentary but long-lived problem solvers (developments in instant messaging, social network software and online games are also significant technical drivers). As the level of automation increases online, it may be that GetMetadata is indeed the optimal approach.


October 23, 2004 12:45 AM

Comments

Robert Sayre
(October 23, 2004 12:56 AM #)

MGET? What in the world is wrong with PROPFIND, in principle?

Mark Nottingham
(October 23, 2004 01:02 AM #)

With all due respect to Patrick, I'm not satisfied at all. MGET breaks caching. Badly.

Bill de hra
(October 24, 2004 03:26 PM #)

" What in the world is wrong with PROPFIND, in principle?"

I suppose you'd need to ask Patrick, but PROPFIND is very specific to DAV, and Patrick is looking for a coherent way to serve RDF metadata. I seem to recall Dan Brickley and I having the notion a few years back that PROPFIND spidering would be a great source for RDF search engine scrapers, in the same way GET spidering is a great source for statistical search engine scrapers.

Also of note, and this referring to Mark's comment, PROPFIND isn't cachable.

Personally I have always thought that the ability to explicitly ask one resource what metadata it has about another resource would be interesting, much more interesting that asking the origin, which although authorative, simply can't be trusted. Sam's recent metadata postulate might sound good (very Wildean), but it doesn't hold. Computing the accuracy of metadata involves aggregation, not topology.

Robert Sayre
(October 24, 2004 05:36 PM #)

"The URIQA Semantic Web Service Interface", used for asking one resource what it knows about another, doesn't require a new method.

MGET is varying representations based on the fragment identifier, which is not compliant behavior. The "URIQA-uri" header is what's really varying the response; the fragment should never be reaching the server otherwise.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1419