Web Things, by Mark Baker

Dave Orchard wrote, and Don Box concurred, that it’s a good thing to avoid registration at the likes of IANA and IETF. I also concur, as my hopefully-soon-to-be-BCP Internet Draft with Dan Connolly describes.

Where I disagree with Dave and Don, is summed up by Dave;

XML changes the landscape completely. Instead of having a small number of types that are registered through a centralized authority, authors can create arbitrary vocabularies and even application protocols through XML and Schema. In the same way a client has to be programmed for media types, a client must be programmed for xml types and wsdl operations.

IMO, XML doesn’t change the landscape in that way at all. It’s always been possible to have an explosion of data formats and protocols; 10 years ago you could have done it with ASCII and ONC or DCE. The fact of the matter is that we don’t see these things on a large scale on the Internet because most people don’t want them. Not only is it expensive to develop new ones – even with a fine framework for their development, such as SOAP & XML Schema – but you’re very typically left amortizing that expense over a very narrowly focused application, such as stock quotes or shoe ordering, or what-have-you. The Web and Semantic Web efforts are an attempt to build a supremely generic application around a single application protocol (HTTP) and a single data model (RDF). Now that’s landscape-changing.

Dave Orchard wonders how XQuery might be put on the Web.

My position seems to fly in the face of at least one part of Dave’s position;

But clearly XQuery inputs are not going to be sent in URIs

Why admit defeat so easily? Did the TAG not say, “Use GET … if the interaction is more like a question ..”? Well, aren’t XQuery documents questions? I think it’s quite clear that they are, and therefore XQuery would benefit from being able to be serialized into URI form. That’s not to say that all XQuery documents would benefit, but many could.

I got a lot of pushback from some in the XQuery WG when I suggested this to them a few months ago, but I think the TAG finding is quite clear. I also strongly believe that doing this is the only significant way in which XQuery can be “put on the Web”.

On the upside, Dave says good things about the value of generic operations;

I first tried to re-use the Xquery functionality rather than providing specific operations in the SAML spec. My idea was that instead of SAML defining bunch of operations (getAuthorizationAssertionBySubjectAssertion, getAuthorizationAssertionListBySubjectSubset, ..), that SAML would define a Schema data model which could be queried against. A provider would offer a generic operation (evaluateQuery) which took in the query against that data model.[…]

Of course, while you’re generalizing, why not go a little further and just use “POST” (suitably extended) instead of “evaluateQuery”?

I also like what Dare had to say about this too, in particular;

One thing lacking in the XML Web Services world are the simple REST-like notions of GET and POST. In the RESTful HTTP world one would simply specify a URI which one could perform an HTTP GET on an get back an XML document. One could then either use the hierarchy of the URI to select subsets of the document or perhaps use HTTP POST to send more complex queries. All this indirection with WSDL files and SOAP headers yet functionality such as what Yahoo has done with their Yahoo! News Search RSS feeds isn’t straightforward. I agree that WSDL annotations would do the trick but then you have to deal with the fact that WSDL’s themselves are not discoverable. *sigh* Yet more human intervebtion is needed instead of loosely coupled application building.

Heh, good one, especially the use of the “human argument” against Web services. 8-)

Jon Udell responds to Stefano Mazzocchi’s comments on an earlier column of Jon’s. Stefano wrote;

Marketing, protocol and syntax sugar aside, web services are RPC.

to which Jon responds;

I disagree. It’s true that Web services got off to a shaky start. At a conference a couple of years ago, a panel of experts solemnly declared that the “Web” in “Web services” was really a misnomer, and that Web services really had nothing to do with the Web. But since then the pendulum has been swinging back, and for good reason,Learn about rep management. Much to everyone’s surprise, including mine, the linked-web-of-documents approach works rather well. Not just one-to-one and one-to-many, but also many-to-many. Adam Bosworth’s XML 2003 keynote was, for me, the most powerful affirmation yet that Web services can and should leverage the Web’s scalable spontaneity. That’s the vision firmly planted in my mind when I talk about Web services.

I’m reminded of a picture Don Box linked to a few weeks ago. A dog dressed as a clown is still a dog. Until Web services embrace a constrained interface (I’d recommend this one, they will always be RPC.

This is goodness, though I’m embarassed that it took me so long to get plugged into; I’m too many degrees of separation away from some communities that are important to my work. Time to update my weblog subscriptions.

Here’s what’s been said the past week;

• Michael Champion on Adam Bosworth’s XML 2003 keynote
• Vanessa Williams on RESTful Tuplespaces
• Phil Windley, also on RESTful Tuplespaces
• Patrick Logan is unsure what REST means, down deep

Phil’s done his homework on his “See also” links there; it’s a nice collection of snippets from the past couple of years, several of them mine. I’d also recommend a presentation I gave last year to the Web Services Architecture WG titled “REST Compared”, where I present a simple example of a REST vs. Tuple space based solution to the pervasive problem of turning lights on and off.

I also like what Vanessa did there, and I think that for anybody currently into tuple spaces hardcore, that following through her outline of one possible integration of REST & tuple spaces would be very informative about how the Web relates to their work.

Patrick seems stuck with how to reconcile his position that generic abstractions are a good thing, but that systems should be built independent of the protocol. Note to Patrick; this is all well and good for transport protocols, but application protocols define the abstraction; for them, protocol independence requires that you disregard that abstraction.

What I like most about this meme is primarily that it implicitly eradicates the myth that the Web and/or REST is just for humans. Even if you don’t know – or want to know – about tuple spaces, it should hopefully pique your interest that a bunch of bright folk in the large scale distributed software composition space – where there’s no humans in the loop – are looking at REST.

From early on in my work as a member of the XML Protocol WG to make SOAP 1.2 usable in a REST based architecture, I found myself up against the unmoveable force known as “protocol independence”.

I was reflecting on this experience in the car this morning, and realized that I could perhaps explain the different viewpoints – of “protocol independence” and “transport vs. transfer” specifically – in terms of message metadata.

Message metadata is that data in a message which defines the context for interpretation of the rest of the data in the message. Application protocols typically have a handful of pieces of it. For example, HTTP has the protocol version, request methods, request URIs, and response codes, and each one of those changes the meaning of their message fundamentally.

My issue with “protocol independence”, which essentially says that you should put everything you need to know in the SOAP envelope, is that it requires me to a) disregard the metadata already provided by application protocols, and b) requires me to reinvent the same mechanisms higher up! Here’s two examples of that form of reinvention;

• the one I talk about a lot; defining a new place to put the requested operation
• putting the target identifier in the SOAP envelope

One type of message metadata that hasn’t, to my knowledge, been reinvented, is the response code metadata. I don’t mean the response codes themselves, as SOAP does have different standard fault types. I mean a standardized place in a SOAP envelope which indicates whether the SOAP message is a fault or not. What’s that you say? The mere presence of a SOAP fault in the body of the envelope is sufficient information to identify the fault? Ah, I see. Well then, you’ve got a message metadata problem. To explain it, consider a Web service with an operation whose job is to return the last fault that the service generated. How do you distinguish between the success of that operation and its failure? Both return faults inside the SOAP envelope! One way would be to define a wrapper that encapsulates the fault in the not-a-real-fault case, thereby hiding it. But that wrapper is exactly the kind of message metadata that I’m talking about!! Another case of reinvention, and again, completely unnecessary when you’re using an application protocol which already has a place for such metadata. When you consider that SOAP doesn’t define this wrapper, then you have to conclude that either a) SOAP is broken, as it prevents me from defining services which return data that looks like a fault, or b) there’s another way to use SOAP, as an extension protocol which reuses the message metadata of the underlying protocol (when it has any, which all application protocols do).

James Strachan responds to my SDO comments suggesting I missed the point. I don’t think I did. Perhaps James missed the point of my comments. 8-)

He writes;

To help set Mark straight; Servlets are a Java API for implementing HTTP operations. (Incidentally Servlets don’t have a client side – for that you need to either use the URL class or the commons-httpclient library). So Servlets take care of the server-side part of HTTP protocol for you. To use REST speak, Servlets implement the server side of the transfer part of REST.

HttpServlets do expose a client side API, they just do it in a language neutral way via the HTTP protocol. I could have also compared SDO to java.net or HttpClient I suppose, but my argument would have been the same.

SDO on the other hand is a generic Java API for any arbitrary typesafe blob of state. It says nothing of how you fetch the state, where it comes from, what transfer/marshalling mechanism etc. The state could come from anywhere; from parsing any XML document, calling some RESTful service, a web service, an RMI call, an EJB / JDO / JDBC / JNDI / JMX query etc.

Yes, true, just as a RESTful service could front for an EJB, JDO, JDBC, JNDI, JMX query etc.

When I first reviewed it, I looked for a “smoking gun”; that thing that would stand out as evidence that the authors hadn’t studied the Web in sufficient detail. I didn’t see any at the time, but after having a second look I’d say it’s the use of XPath; SDO should have used URIs (or perhaps both) as the means of relating objects. Perhaps that might help you see where I’m coming from with my objections, James.

Thanks for the feed/pushback.

Update: James responds again. I think his last paragraph is all I really need to comment on;

Incidentally, the interesting thing about SDO is that the navigation mechanism is pluggable. So Mark, an SDO implementation could use URIs (or XPointer, or XQuery etc) to navigate through the data graph.

Yes, understood, but that misses the point of the Web. URIs aren’t just another identification mechanism, they are the most general identification mechanism, enabling other mechanisms to be defined in its terms (e.g. FTP file names engulfed via the ftp URI scheme, email addresses engulfed via mailto: etc..).

Sure, the Web can be treated as just another system, but as soon as you do that, any attempt to build a general model that includes it ends up being an attempt to reinvent it, because that’s what the Web is; the system of all systems.

Stefan Tilkov thoughtfully responded to my “Building the Web with Web services” blog. Here are some of his comments.

In response to my assertion that documents/state don’t ask anything of anyone, he writes;

Er … well, I think I can see the point, but I can’t really make sense of the examples. So, a purchase order isn’t asking anything from anyone? That can’t be true – so obviously, these are counter examples – a purchase order is asking something. Looking at the paragraph, even for some length of time, I have problems finding out what exactly Mark is getting at – I fail to see the similarity between a pure piece of data like current time and a very concrete, business level document like purchase order. Arguably, it’s just not phrased very clearly, or maybe it’s because I’m not a native English speaker.

A purchase order isn’t asking anything of anyone; it’s just capturing the state of some order. It can be used to ask something of somebody. For example, I could give it to a skywriter, and they could write the XML out in smoke overhead. Or I could give it to an archiving service which promises to keep a copy around for some period of time. Or, I could give it to a purchasing department with the intent that they fulfill the order. But all those actions are where I’m asking somebody to do something. What would you do if you found a paper purchase order lying in the street? Do you know the intent of its author? No.

He also added this;

While Mark obviously was thinking of content negotiation, support for Expired headers and so on, he doesn’t talk about it at all. How is anybody supposed to make sense of that?

I quite intentionally (though I slipped some in at the last minute, sigh) tried to avoid mentioning Web terms where I could, and just talk about the general approach. I did this because in my experience, once you start using Web terms, people automatically import their preconceived views of the Web … which is what I’m trying to fix.

And then this;

OK, I’m a bit puzzled by now, but surely things are going to be clarified in the next few sections. (Seriously, that’s what I thought when I first read the article). Imagine my surprise when I saw that the next paragraph’s title is Conclusions:

Well, that’s all there is! 8-) The intent of the essay was to describe how the Web relates to document style Web services; that if you add identification of the things whose state is represented by those documents, make semantics uniform and explicit on the wire in the form of an application protocol, and dereferencing of identifiers to request a document, that you’ve got the Web.

Thanks for the constructive comments, Stefan. I know how easy it is to get all kneejerky on this. It just seems that the industry is SO close to finally understanding the Web, that I feel an obligation to jump up and down and yell “Yo, over here, we’ve already got one of those!”.

Until last week, the SOAP document/literal examples I’d seen differed from the rpc/encoded ones only by the encoding. Then I spotted this example (in section 5.1 – sorry, no URI) in the WSDL 2.0 Primer;

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Body>
	<customerName>Kevin Liu</customerName>
	<checkInDate>2002-09-01</checkInDate>
	<checkOutDate>2002-09-10</checkOutDate>
	<roomType>double</roomType>
	<comments>the customer will be arriving late in the evening</comments>
 </env:Body>
</env:Envelope>

Ignoring the problem that there’s not a single child element of env:Body, this is, from a Web architecture POV, quite encouraging; we have a SOAP envelope encapsulating state. Very RESTful (at least the part of the architecture that is visible in that example).

But if you know where (how?) to look, the Web is nearby. The key is to realize, once you’re dealing in state, that the obvious next question is, “The state of what?”

Though he didn’t use the words “self-description”, a good article nonetheless.

FWIW though, I think XML only provides the syntax in which contextual information can be serialized. It’s a start, but we need more.

A great quote relayed by Jim Hendler, as told by an old advisor of his;

“the only thing better than a strong advocate is a weak critic”

Heh. Too true.