Web Things, by Mark Baker

David wrote an article on the BEA site, that, to its credit, confronts the issue (and IMO, mistaken assumption of so many); that the Web is for humans. He writes;

It turns out that humans are pretty darned smart. We can figure out a variety of interactions such as:

    * How to enter usernames and passwords into different pages
    * When to stop waiting for a page to return and resubmit the request
    * When timed out of a site, how to reenter data and get to the right pages
    * How to enter an e-mail address in a Web form, and then switch over to the e-mail client to view the resulting e-mail message
    * What ordering (or flow) of Web pages to go through to achieve a task

Dave’s correct that humans are pretty darned smart, and also when he later suggests that machine-to-machine integration requires additional standards because of this. But he’s mistaken if he believes (and I know he does 8-) that this requires disregarding REST’s uniform interface constraint. Allow me to run through that list to demonstrate …

How to enter usernames and passwords into different pages. For the specific case of user names & passwords, the Web already has a standard for that. For the more general case of entering any data, I agree that a standard is missing. That’s why I developed RDF Forms, but something like WIDL could also be used.

When to stop waiting for a page to return and resubmit the request. I can’t imagine a scenario where you’d need a standard for this. If the system were stateless, then time is immaterial. I would expect that what is most important would be that when you do resubmit, that the expectation about invocation semantics are explicit, e.g. “once and only once”, “idempotent”, “safe”, etc… I agree that standardization is required here (though not as much as you might expect).

When timed out of a site, how to reenter data and get to the right pages. This sounds like a combination of the previous two, but I should also mention that RDF Forms uses “link metadata” (i.e. type information adorning a hyperlink, such as <PurchaseOrder rdf:about=”http://…”/>) that can be used by automata to “get to the right pages”.

How to enter an e-mail address in a Web form, and then switch over to the e-mail client to view the resulting e-mail message. Much like the first one above regarding data entry, but I’m not sure what “switch over to the e-mail client” means; surely my automata isn’t going to be using the Outlook GUI/app, it’ll be using some email client library or an HTTP proxy to an MTA.

What ordering (or flow) of Web pages to go through to achieve a task. That’s where “hypermedia as the engine of application state” comes in, as hypermedia is your application model. Link metadata is key here too; I talked about this in “Hypermedia Workflow”. But I do think some more standardization is required, specifically in the area of link metadata describing useful workflow abstractions such as rendezvous (none of the RESTful integration work I’ve done has required a workflow component other than vanilla hypermedia, so I can’t say with certainty what needs to be standardized).

Thanks to Dave for mentioning this, because it’s been such a long standing assumption that most Web services proponents would consider it unworthy of discussion.

I’ve known Graham for a few years, ever since I was at Nortel, working with a pre-release version of Objectspace Voyager (purchased by Recursion). He and I, and his team, had several interesting discussions about Voyager & CORBA, culminating in an attempted recruitment of yours truly (I couldn’t do the move).

Voyager was a Java framework which provided a smorgasbord of options for building distributed applications including agents, mobile agents, tuple spaces, and RPC (CORBA/RMI/DCOM/etc..). My fondest memory of it was when I used the Spaces package to prototype a workflow management system (with a constrained interface!! Who knew?! 8-) in about two days. To this day, I count that as one of my most aesthetically pleasing designs.

Shortly thereafter, I stumbled upon the work of a guy named Charles Axel Allen at a startup called WebMethods. That work was WIDL, and I used their WIDL toolkit to generate the Java stubs (IIRC) which I tied into my Voyager based workflow system. It’s hard to believe that it took me many more months to have my Web epiphany after flirting with something so similar to Web architecture in WIDL and Voyager Spaces. Live and learn.

Every successful large scale system (say, >1M nodes) ever deployed used a constrained interface.

Prove me wrong.

Update: somebody asked what I meant by “constrained interface”. Basically, I meant that it uses a coordination language.

And now for something completely different …

I thought it might help my cause for me to admit that I’m only human (yes, I’m not really a know-it-all!), and that there remain things about REST and Web architecture that I don’t understand (including those things that I don’t even understand that I don’t understand 8-). Here’s my current list of things I know I don’t grok.

Can I do PUT with POST RESTfully? I go back and forth on this one all the time. At first glance, the answer seems to be yes; that it should be possible to “submit data” with POST semantics, but using a mandatory extension (ok, so it’s M-POST) to indicate the extended intention of “state replacement”. But when you dig a bit deeper, you wonder if this is equivalent to tunneling; that the extended intention of PUT-via-POST provides visibility into the terminal state of the resource, which seems to be a no-no from a REST POV. I won’t even bother you with the wacked mental model I have of this issue, except to say that it involves residues.

Self-description and namespace mixing If I produce a multi-namespace document, am I automatically importing the entailments of those namespaces? Dan Connolly says yes (at least for RDF Schema), and I disagree with him. But I lack the background in this space to be able to convince Dan (or even myself, for that matter). It’s just a hunch at this point, but the issue has very important consequences, especially to REST which requires self-descriptive messages.

A proposal of mine was recently accepted by the RDF Core WG which IMO, will help explain what RDF is for to a lot of people who don’t yet understand the important role it plays in the World Wide Web project. I believe this because I’ve used the RDF it permits, to successfully explain what RDF adds over vanilla XML to Exec types.

Consider the following. Is it XML or RDF?

<Person xmlns="http://example.org/foofoo/">
  <name>Mark Smith</name>
  <age>55</age>
</Person>

Answer? It’s both. Depending upon which media type it’s described with, it means different things.

To an XML application that isn’t hardcoded to know about that language, it’s an almost entirely opaque blob, except for the namespace.

To an RDF/XML application that isn’t hardcoded to know about that language, it knows what the XML app knows, plus;

• that there exists a resource of type “http://example.org/foofoo/Person” someplace, with properties “http://example.org/foofoo/name” and “http://example.org/foofoo/age” with those values
• that additional properties can be added without impacting the meaning of the former interpretation, i.e. potentially breaking some application somewhere. An XML app can’t assume this; it might be breaking its validity against some schema someplace
• various other possible syntactic additions or modifications which can be used to extend the current semantics in a backwards compatible way, if desired.

This is the value of partial understanding.

I’m sure everybody’s seen the Amazon/Microsoft announcement about buying books through Powerpoint by now. Did you notice this bit?

The solution, called Amazon.com Research Services for Microsoft Office System, will be available for download in the Office Marketplace at no additional charge later this fall.

Oh goody, so now I’ve got to download a new app every time somebody integrates their services with Microsoft’s?

If you can’t do O(N) or better, go home.

Here’s an interesting project, Sensor Web;

Sensor Web is a web-centric, open, interconnected, intelligent and dynamic network of sensors. It presents an entirely new vision towards the way we deploy our sensors, the way we collect the data, the way we fuse and distribute the information.

Alright, I thought, some Web fans who aren’t afraid of tackling the big integration problems. Upon further investigation however, I discover (in a report titled “An Web-based Distributed Geocomputing Architecture for Smart Sensor Webs” no less) that they’re not using Web architecture, they’re using Web services. Hey, if they want to knock themselves out trying to tackle that problem given the known integration problems with Web services, that’s fine. But doing it while saying it’s “Web-based”, is misleading and harmful, especially to those who might use the Web to solve the same problems.

Mark Nottingham responds to my suggestion that “REST = SOA + late binding”;

[…] While I see the truth in this, I think it’s pretty orthogonal, and it’s not that compelling for most SOAish folks. This is because their use cases are machines talking to machines, not people talking to machines. In Web browsing, this is great, because people are smart enough to look at the late-bound semantics in a representation and figure out what they want to do; machines aren’t, yet.

Hmm, I think we might not be in synch about “late binding”. Without getting into the nitty gritty of it, which I admit eludes me sometimes, perhaps we can just look at the use Roy makes of the term;

This abstract definition of a resource enables key features of the Web architecture. […] it allows late binding of the reference to a representation, enabling content negotiation to take place based on characteristics of the request.

“Late binding of the reference to a representation” refers to GET; that any reference can be turned into data without dependencies on any centralized component. As a comparison between the SOA and REST approach, consider an identifier for a purchase order; REST would use a URI, “http://example.org/po/928340823”, whereas an SOA approach might use just “928340823”. Turning the former identifier into data, no matter where its discovered, requires simply invoking GET on it. Turning the latter into data cannot be done without a dependency on some central component that turns purchase order identifiers into data. This is why Web services need centralized registries like UDDI.

Hopefully this sheds some additional light on what “REST = SOA + late binding” means. Another interpretation could be “REST = decentralized SOA”.

In a report on Web services tools, PC Magazine‘s Robert P. Lipschutz writes;

Data-based strategies such as Roy Fielding’s REST (REpresentation State Transfer) replace SOAP and put the content, Uniform Resource Identifiers (URIs), and XML at the center of the equation. It’s too early to make the call on REST, but don’t rule this option out.

Doug, anticipating my response, promptly responds.

He brings up the “identification vs. location” issue, which I agree remains a point of contention between many (though the Web wizards are all in agreement on this one, at least 8-). But we’ve already been there, and I don’t think I could explain my position much better than I did there. So I’ll concede that point for the moment so we can move on to an aspect of architecture which I feel is more important in determining the degree of loose coupling; late binding.

REST uses late binding, as REST clients are developed to a system-wide abstraction; the resource. As an example of what this enables, a RESTful client can get data from any RESTful server. SOA cannot do this; a constrained interface is required for this, whether in a RESTful manner or not.

FWIW, in these terms, one can look at REST as the natural evolution of SOAs on the Internet; SOA + late binding => REST