Web Things, by Mark Baker

A great one from Jim this morning, about how REST seems to be all the buzz in various distributed computing communities. I noticed that too; it’s very cool, and a long time coming.

As for the cons, this one sentence of his seems to sum it up;

Sure REST’s message-oriented approach is sensible, but it has the downside of mixing the semantics of the SOAP message with those of the transport protocol.

What can I say? As I see it, that’s been the “Big Disconnect” since the whole Web services thing got started. Far too many people – especially those weened on CORBA, DCOM, and similarly styled architectures – just don’t appreciate the HUGELY important role played by application protocols. This is evident by the continual de-emphasis of them by treating them as transport protocols, as Jim does there, intentionally or not.

Document oriented SOAP messages should have no semantics by themselves, not even processMessage (modulo TCP – see below). The semantics should be provided by the underlying application protocol. That way, the semantics of a SOAP envelope being transferred with HTTP PUT won’t be confused with one being transferred with HTTP POST or SMTP DATA; they mean different things, and you can lookup those meanings in the HTTP and SMTP specs.

Now, if you sent it over TCP and want POST/DATA/processMessage-like semantics, you need to bind those semantics to the TCP port via an IANA registry.

Transport protocol (e.g. TCP, UDP) independence is good. Application protocol independence must die die die!

A good one from Sanjiva Weerawarana;

For the success of the Web services platform, it is ABSOLUTELY critical that there be one and only one addressing/referenceing/whatchamacallit standard. Until we get there everything is and will be broken.

I couldn’t agree more. Identification anybody?

Sometimes I think Web services advocates are so close to understanding what the Web is. Other times, erm, not so much. 8-(

If only media types were http URIs, then you could dereference them to learn whether or not they’re what you’re looking for. This is why URNs suck.
(link) [Mark Baker’s Bookmarks]

Sweet! But is it a tree in the forest, or the first domino?
(link) [Mark Baker’s Bookmarks]

In a previous incarnation of this project, I was asked to move to Mountainview in late 1999 (IIRC) to work with Asko Komsi of Nokia on a micro version of Gecko/Mozilla. We were to work out of Netscape/AOL’s offices there. Politics killed it, but I heard
(link) [Mark Baker’s Bookmarks]

(Via Jacek) Digs deep into HTTP/RDF as a tuple/triple-space architecture, and concludes that this is the future of Semantic Web services. I couldn’t agree more!
(link) [Mark Baker’s Bookmarks]

Separated at birth?
(link) [Mark Baker’s Bookmarks]

Congrats to Edwin and Doron!
(link) [Mark Baker’s Bookmarks]

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.