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]
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.
a paper with a very interesting title, that I hadn’t heard
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
and some of the recent
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,
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).
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  and ASAP . 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.