Re: Proposed text for section 1.6.2 and 1.6.3

Mike,

Below is an exerpt from your proposed text.

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?

Aside from that, I have issues with the idea of "application specific
vocabulary" as the engine of anything.  For two reasons:

(1) to be an engine, it has to facilitate if not actually drive
the process.  Vocabularies, by their nature, just can't do that.

(2) every application under the sun has an application-specific
vocabulary.  Indeed, you might use the vocabulary to identify
the application, or compare two applications and declare them
isomorphs.  But I'm wandering off..  Even REST applications
have application-specific vocabulary, so that can't be a point
of distinction

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.

--Walden


[Both classes of "Web services" use URIs to identify resources and use Web
protocols and XML data formats for messaging. Where.they fundamentally
differ is that "distributed object" [Ed note: or "mediated services"] use
application specific vocabularies as the engine of application state,
rather than hypermedia. Also, they achieve some of their benefits in a
somewhat different way. The emphasis on messages, rather than on the
actions that are caused by messages, means that SOAs have good
"visibility": trusted third parties may inspect the flow of messages and
have a good assurance as to the services being invoked and the roles of the
various parties. This, in turn, means that intermediaries, such as fire-
walls, are in a better situation for performing their functions. A fire-
wall can look at the message traffic, and at the structure of the message,
and make predictable and reasonable decisions about security. ]

Received on Wednesday, 7 May 2003 15:52:18 UTC