Web Things, by Mark Baker

Along with most everybody else I imagine, I had a look over the Avalon/WinFS stuff from Longhorn this week. Jon Udell sums up my position better than I could;

Yeah, “embrace and extend” was so much fun, I can hardly wait for “replace and defend.” Seriously, if the suite of standards now targeted for elimination from Microsoft’s actively-developed portfolio were a technological dead end, ripe for disruption, then we should all thank Microsoft for pulling the trigger. If, on the other hand, these standards are fundamentally sound, then it’s a time for what Clayton Christensen calls sustaining rather than disruptive advances. I believe the ecosystem needs sustaining more than disruption. Like Joe, I hope Microsoft’s bold move will mobilize the sustainers.

Yup, bingo. I was shocked when I realized that they were completely reinventing the wheel here for no (really) good reason … except that somebody high up figured, as Jon says, that the Web was “ripe for disruption”. As much as I dislike many of MS’s business practices, I have the utmost respect for the company and the people there. But man oh man, what a stinker this stuff is. Remember Blackbird? Did these guys forget that they own the browser? If they had done this properly, they could have had the rest of the industry playing catch up to their Web extensions for the next five years or more. What an enormous gaff. Wow.

Just as an example of some things that they could have extended the Web with, consider these;

• client-side containers for stateless session management; requires HTML extensions (drag-and-drop, events, etc..)
• Web-browser-as-server for async notification; ala mod-pubsub
• Advanced forms (XForms/Infopath/RDF-Forms); that Infopath is stuck in Office land is criminal
• Web-friendly structured storage, where URIs are file names (yes, I meant it that way around)
• Better HTTP proxy integration via per-request message routing, rather than per-connection routing which we currently have

All but the fourth require non-trivial, visible extensions to the Web … and the W3C and IETF aren’t currently touching them (except for forms).

A fine description of why we prefer our URIs to be treated opaquely, in the context of a brain-dead spam-busting idea by a UK MP.

Because I needed to use this myself, but also because I wanted to flaunt the simplicity and expressiveness of RDF Forms, I whipped together a little spec …

URI Proxy provides a means of describing a RESTful service as being a “proxy” (well, kinda – read the spec) for other RESTful services. Composition via aggregation.

You’ve seen examples of services like this before; Google’s cache (example – though the full URI isn’t used, which sucks), Google’s translator (example) the Web archive (example), etc..

Apparently that needs to be reiterated. Interesting.

Computers->Programming->Internet->Web Services->REST. Neat.

I’m in the middle (or perhaps its the end) of a conversation with Savas Parastatidis regarding a “radical” new form of Web service constraint. Consider his plan to send along this as a message;

<orderForm1>
  <carOrMotorcycle>car</carOrMotorcycle>
  <colour>blue</colour>
  <cc>1800</cc>
  <model>blabla</model>
</orderForm1>

Sure, there’s no symbol visible that can be mapped to an operation, but in order to understand what is being asked of a recipient of that message, something somewhere has to say what is being asked. Otherwise it would inherit the semantics of any underlying application protocol that transferred it – consider that it would mean different things to send it with HTTP PUT and POST – and therefore wouldn’t really be a message, just a piece of a message (representation anyone?).

Based on what Savas explains he wants that message to mean though, what he describes is semantically equivalent to HTTP POST, only without URI targetting, and with an implicit operation rather than an explicit one. I claim that this is a better version of his message;

POST some-uri HTTP/1.1
Content-Type: application/order-form+xml
<orderForm1>
  <carOrMotorcycle>car<carOrMotorcycle>
  <colour>blue<colour>
  <cc>1800<cc>
  <model>blabla<model>
<orderForm1>

It’s pretty funny to see pieces of Web architecture being rediscovered by Web services folks. Once the enormity of the big picture of the Web hits home with them, well … let’s just say that there’s a whole lot of walls on which I’d love to be a fly.

P.S. more uniform interface goodness from Bill.

BEA CTO Scott Dietzen gave one of those typical Q&A interviews in which he says a lot of the usual stuff you’d expect him, or any Web services proponent, to say about Web services. But he does say something interesting about UDDI;

I took an informal survey of our highest-end customers. We had our top 50 or top 40 end users in a user group together and I was astonished that all of them claimed they had transactional Web services in production and 60 to 70 percent had transactional Web services running between .NET and WebLogic in production. The UDDI[sic] adoption was much less.[sic] People were basically using URIs and URLs as their model for locating and binding into Web services.

and later,

I think it’s also clear that UDDI has been oversold.

Right. So Paul and I were right then?

I think there’s a critically important point being explained here; even in the face of hype-up-the-wazoo, customers will generally opt for simplicity. This is why it is possible for Web services/SOA to fail. All it takes is for customers to understand how to do things the simpler way. The use of URIs and GET is really very simple, so there’s no surprise it was first. Knowing how to use POST and URIs (without operations in the body) is tougher. But it’s just a matter of time before they figure it out, IMO.

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.