Re: Proposed text for section 1.6.2 and 1.6.3

Mike,

I definitely need to chew on what you said below more.  I do see
a faint link between this "engine" business and the idea of direct
action invocation versus document-writing.  But I believe "engine of
application state" refers to something else.  Someone correct me
if I'm in the weeds here...

In a distributed system with stateless servers, application state
is approximately client state. (I don't want to spend time refining
or defending that statement, even if it's not perfect.)

When, as a client, I do something that results in the server
sending me a new representation, and when that representation
includes the identifiers for the next set of relevant resources
in the domain of discourse for the application, then moving to
the next state is as easy as following the link.  (Again with some
complexity elided.)

That navigation: from representation to identifier to next rep
to next identifier, and so on, is the "engine".  It doesn't really
motivate the client*, but it greatly facilitates the client's exploration
of valid application state.  (And it greatly un-facilitates the
client's exploration of *invalid* application state.) So it's reasonable
to call that an "engine".  (It might be even more reasonable to
call it the road, but that's another matter.)

*except in the sense that opportunity motivates.

Meanwhile, a "vocabulary" just sits there.  If, as a SOA3K client
I know how to invoke some service and do so, there is no
explicit connection between the response I get and my next
action.  No easy next step.  No facilitation.  No engine. <cough>

--Walden

----- Original Message -----
From: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
To: <www-ws-arch@w3.org>
Sent: Wednesday, May 07, 2003 5:15 PM
Subject: RE: Proposed text for section 1.6.2 and 1.6.3


>
>
>
> > -----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
> perspective.
>
> I think your comments have suggested how this might be clarified in the
next
> draft ...
>
> Mike
>
>

Received on Wednesday, 7 May 2003 18:35:24 UTC