W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2003

RE: Proposed text for section 1.6.2 and 1.6.3

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Wed, 7 May 2003 15:15:11 -0600
Message-ID: <9A4FC925410C024792B85198DF1E97E405A96092@usmsg03.sagus.com>
To: www-ws-arch@w3.org

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Wednesday, May 07, 2003 3:51 PM
> To: Mike Champion; www-ws-arch@w3.org
> Subject: Re: Proposed text for section 1.6.2 and 1.6.3
> I think that anyone who hasn't read the REST thesis is going to
> be lost in the language about "engine of application state".  Is there
> a more "plain english" way to express this thought?

Hmm, I was trying to preserve what I thought was a very good point in the
previous draft (I think Dave Orchard wrote it after a long discussion with
Roy Fielding on the subject).  But your point is well taken, this is not a
familiar concept.  And it gets to the "how does the book get ordered"
discussion I had with Mark in the last post.  

> I think the truth is that "SOA of the third kind" (it's as good as
> your other names, admit it) has no discernable pattern for
> driving application state, unlike REST.  Unless someone can
> convince me otherwise.

This is a tricky subject, but I think it gets to the core of what we've been
arguing about for the last year or so.  In REST, one directly manipulates
representations of resources that tell somebody/some program to go out and
ship the book (or whatever).  That's clearly a hypermedia approach to
setting the application state to "Person X ordered book Y."  In
"non-REST/SOA of the Third Kind / API SOA"  there is presumably some
software component/object/service/application out there that maintains its
state, and that state is not exposed as a Web resource, so we invoke some
code to set the application state.  So we have "the application itself as
the engine of application state" as opposed to "hypermedia as the engine of
application state."  But it's all pretty metaphysical ... I don't have
strong feelings that this *needs* to be in the WSA document, except that so
much virtual ink has been spilled over the REST vs non-REST issue, and this
is the essence of it, so we ought to try to at least put it in architectural

I think your comments have suggested how this might be clarified in the next
draft ...

Received on Wednesday, 7 May 2003 17:15:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:51 UTC