Web Things, by Mark Baker

A little silliness on a Monday morning (aka garbage day). Here in Ottawa, WSI is our local waste management company.

Paul writes that innovation in the browser ain’t dead yet. I agree. From a distributed systems POV, I think there’s two important things that need to happen to the browser, in addition to the richer languages that Paul talks about (and don’t forget about RDF and OWL!);

• making the browser a peer
• allowing the browser to own application state

The former deals with integrating a Web server into the Web browser, enabling the “Two Way Web”, like KnowNow and Idokorro (my company) do.

The latter, related to the former, suggests that cookies can be replaced by purely client-side application state. What this would look like, is that you’d drag-and-drop items from a browser window into a desktop-located container – for example, a shopping basket – and then to check out, you drag the container back to the page. This keeps the session state – the basket – on the client, per REST’s Stateless constraint. This would require an extension to HTML/XHTML to support draggable objects, as well as a means to support file upload via a drop action (i.e. targetted at some element on the page).

WS-I released the first draft of the Basic Profile today. I don’t know how they manage to write so much about something that isn’t necessary; you wouldn’t need profiles if interoperability were well defined. It seems to be purely a political move to bundle specs together so that the technology doesn’t look like it could be easily marginalized (though it can).

I mean, really, why on earth does anybody need to specify the possible HTTP response codes to be used, when HTTP clients can already deal with all of them (even if only to fallback to x00)?

And cookies for state management? Puh-leeze! Cookies are a hack, and only make any kind of sense when you’re dealing with an installed base (browsers) that support them. Remove the browser, and you could do state management properly, on the client (and only on the client) instead of the server. This is Distributed Systems 101 stuff here, sheesh.

Sigh. It disappoints me to think of all the time and money the industry is wasting on this.

Sam writes that Glen Daniels has added HTTP GET support to Axis. Good job! Though I think my suggestion was cleaner, lined up well (semantically) with how other methods are invoked, and didn’t require that odd hack which suggests that a GET request is not a request message(!). Oh well. Thanks, Glen.

A message I sent to www-ws-arch this past summer seems to be making the rounds again. I don’t think I ever mentioned it in my weblog, so here ya go. Looks like it was mentioned on xml-dev, so perhaps that’s why. Er, and I forgot that I mentioned it in my “Playing Checkers with a Chess Set” blog too. Duh.

BTW, 10 kudos to whomever finds the “flaw” in the argument I made in that message. It’s not a fatal flaw, of course, but it does hilight the late binding issue, which I didn’t introduce in it (for fear of losing the simplicity of the point I was trying to make).

Update; the flaw is that when you get to the get/GET part, the message no longer means “get stock quote”, it just means “get a representation of what’s identified by this URI”. You find out if it’s a stock quote after you invoke GET. That’s late binding.

Presumably a virus/worm/whatever had a hand in a message forwarded to the Web Services Architecture WG mailing list today. Interesting, it appears as though Scott Dietzen, CTO at BEA, has moved on to Microsoft. Ow, that’s gotta hurt. 8-)

Who knows though, this could be a fake, since the message headers look weird; the message-id is from bea.com, despite the From header indicating microsoft.com. Shrug/chuckle.

Update; the archived content of the message has been removed, presumably per W3C archive editing policy. But you can still see the From and Message-Id headers.

Just came up with this. I’ll have to use it someplace. It’s a bit too brash for my .sig unfortunately, especially for WS-Arch emails. 8-)

Update; just whipped together a blog at my O’Reilly weblog.

It’s good to see Edwin agreeing with Steve Vinoski about how distributed systems are not as simple as just exposing object APIs through SOAP.

I especially like this bit; “We should think of it as email for business applications”. Yes! But email is fairly limited; we can do better than just “add this message to that mailbox”. What if we extended email with the ability to retrieve messages, replace existing messages, plus other operations on messages and mailboxes? If you squint a little, that’s what the Web is.

I should probably have done this long ago for the record, but there’s no better time than the present. This was prompted by a couple of comments I’ve seen recently saying “Web services are here to stay!”. Bzzt!

Web services will be considered an utter failure by the industry by the end of 2004.

The end game will be interesting to watch, that’s for sure. Some companies will emerge as the real thought leaders, and others will likely be left insisting that Web services are the right way to do things. Then again, it’s possible that Microsoft and IBM spin doctors may just absorb REST; “We’ve been saying that all along!”. Either way, none of the specs associated with Web services will be in use on the Internet by then, except perhaps SOAP, DIME, and WS-Routing. But I’d have to bet against those too, unfortunately, because they’re going to get caught up in the backlash.

I’ve seen the phrase “Service Oriented Architecture” (SOA) thrown about by so many people recently, and every time I see it, I cringe. As near as I can tell, it’s being used by Web services folks to mean simply “a service available over the Internet”, which AFAIK includes email, FTP, the Web, IRC. Really, what distributed system is not about services?

If marketing buzzwords are going to make it into technical discussion, please make sure they’re not no-ops.