- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Wed, 7 May 2003 15:15:11 -0600
- 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 perspective. I think your comments have suggested how this might be clarified in the next draft ... Mike
Received on Wednesday, 7 May 2003 17:15:23 UTC