Web Things, by Mark Baker

Tim Bray writes

about an informative Nokia paper on WS/SOA.

Check out Nokia Web Services Framework for Devices – a Service-oriented Architecture. It’s a practical intro to how SOA might play in the mobile space, with some eminently sensible background work; there’s a section entitled What is a service-oriented architecture, and why is it good?

Heh, look, HTTP GET and POST being used (largely) RESTfully. Yeah.

The example exchange at the end is a bit concerning though. Anybody who’s done any amount of work in the mobile space quickly learns that network round trips are even more prohibitively expensive than on the land lines. You’re looking at at least a 500ms one-way over most networks, perhaps up to a second or more depending upon a number of factors, primarily signal strength (read; packet loss). At Idokorro, we had access to the first GPRS network in Canada (when nobody else was using them) and the first GPRS Blackberrys, and we were still getting 1.2 second hops to our BES.

So, any solution that requires two network round trips for doing what can be done in one, is a really horrible idea. They should scrap the PAOS stuff and just send the authentication information in the initial GET. It’s more self-descriptive, the net bandwidth consumption, at least in this example, is appreciably reduced (if auth info isn’t needed elsewhere, it might not be over time, though there’s still RESTful ways to manage that), and the user or app gets their data a second (or more) faster.

Stefan found a paper with a very interesting title, that I hadn’t heard anything about; Developing Web Services Choreography Standards – The Case of REST vs. SOAP.

I’d heard Keith Swenson’s name a few days earlier in the context of ASAP and some of the recent buzz surrounding it, but I’ve known about his work for a while. I spent some time studying both SWAP (co-authored with a buddy of mine, Greg Bolcer) and IPP during their development.

Aside; IPP actually slowed my studies into the Web (along with HTTP-NG, sigh) because I, for whatever reason, started by assuming that IPP was a good use of HTTP. Only later did I realize that the exact opposite was true (as was only recently confirmed by Roy).

On the upside, IPP’s use of POST spawned an important and interesting exchange, via Internet draft, that I studied very carefully (which lead to a draft of my own); Don’t go Postal, and The Use of POST.

Anyhow, all of this to say that I was quite surprised to see REST reasonably well represented … except for perhaps this part;

Several standards for REST style workflow interaction have been proposed, namely SWAP, Wf-XML [26, 52, 58], AWSP [49] and ASAP [38]. Instead of relying on the HTTP 1.0 commands, these standards provide higher level operations that are specifically designed for the interaction with remote processes.

Hint; if you’re trying to provide operations at a higher level than the application layer (e.g. HTTP), you’re abusing HTTP, not using it. But, the operations being tunneled are themselves reasonably generic, which is good design practice for this space, and what I think the authors were trying to point out as nearly RESTful.

It’s really encouraging to see REST mentioned in the context of workflow, since I believe it provides a superior base for scalable solutions than does SOA. I think this paper could be an important piece of work if the authors were to spend some time studying both architectural styles from a software architecture POV, as well as actually building some systems with each. As is, the analysis is pretty decent, but the conclusion – basically that it’s a crap shoot over which one is superior – needs some major work.

Mario Jeckle, dead at 30. Peace, Mario.
(link) [Mark Baker’s Bookmarks]

Geez, I didn’t realize it was still going. I remember attending a meeting in 1998 when it was called the “Connected Alliance”. Neat stuff, based primarily on Anselm Baird Smith’s Java Embedded Server (JES)
(link) [Mark Baker’s Bookmarks]

A good post by David on the relationship between data format and protocol extensibility and evolvability. I’m not sure I totally agree with his conclusion – that “protocol designers […] shouldn’t have high hopes that they can regularly provide for compatible protocol evolution” – but the bulk of it makes sense. I also think he’s approaching it from too theoretical a POV, since there are practical considerations that change the dynamics he’s studying (as I mentioned to him).

However, he finishes with this whopper;

As an afterward, it may be worth pursuing trying to solve problems of protocol evolution by examining whether the use of a constrained protocol, ie HTTP, provides any greater evolvability for protocols

That kinda came out of left field, no? I don’t see how that follows from what he wrote. I agree, of course, but just because a constrained interface provides self-descriptive messaging, and self-descriptive messaging provides better evolvability characteristics than the alternative, since the semantics of the message are unambiguous. This is in constrast to an SOA style message, where the most important semantic – the operation – is actually purposefully removed from the message.

I’m looking forward to his next post, which I anticipate to have a title something like “Oh my, you mean HTTP and RDF are what I’ve been looking for all along?!”. 8-)

[Oops, I forgot to promote this to my “live” weblog last week. Here goes.]

Had a blast at the Middleware 2004 Program Committee meeting in Toronto this weekend. I got to catch up with my old dist-obj buddy Doug Lea, as well as meet some people whose work I have at least a passing familiarity with such as Roy Campbell, Stefan Tai, and Chris Gill. Unfortunately Werner couldn’t make it en corpo – it would have been good to talk face-to-face with him about REST, SOA, distributed objects, etc.., – but he was able to dial-in which was appreciated.

I hadn’t heard about this conference before being invited to be on the PC, so wasn’t exactly sure what to expect in terms of paper and organizational quality (though after seeing who was involved, I was less concerned 8-), but after this weekend, I’m confident it will be an exceptional conference. Please consider attending!

RDF/XML? Think of toString() as the local API equivalent of GET.
(link) [Mark Baker’s Bookmarks]

Honeypot/spamassassin integration – beautiful, I’ll have to try that with CRM 114 now that markbaker.ca has an MX record
(link) [Mark Baker’s Bookmarks]

Dan Connolly and Rohit Khare on a Web/OO comparison. See, it’s not just me. 8-) (have I blogged this yet?)
(link) [Mark Baker’s Bookmarks]

This is important.
(link) [Mark Baker’s Bookmarks]