Re: FW: LC Comments: Web Method Feature

Hey,

On Wed, Jul 03, 2002 at 06:52:28PM +0100, Williams, Stuart wrote:
> > Where did "messaging" come from there?  I think the chameleon view is
> > as much about messaging as the tunneling view ... at least as far as
> > the underlying protocol permits.
> 
> The surface model with the REST resource state view is that of direct access
> and manipulation of resource state. The underlying protocols use messaging
> to create the illusion of shared state... but the surface model is one of
> state access and manipulation, not of message exchange. GET, PUT, POST,
> DELETE... are operations performed on resource with varying degrees of
> success.

The access and manipulation operations *are* messages.  I don't
understand the distinction you're making.

One of the principle qualities of a messaging system, in my observation,
is statelessness.  REST is stateless, which makes it possible to
decouple its request and response messages.  HTTP requires a connection,
so there are some issues such as implicit correlation between request
and response messages on the same connection that wouldn't normally
exist in a connectionless messaging system.  But that's purely an
implementation artifact of HTTP, not inherrent to REST.

> > As you know, I've been saying that SOAP isn't a layer (with HTTP) for
> > some time.
> 
> I think view points differ. I can see both ends of the spectrum and merit in
> both.

I wish I could be so supportive. 8-(  No offence, but I don't see any
merit to the tunnel view.

> > If developers want to use the tunnelling approach, they can use TCP.
> > That's the right thing to do on many levels, IMO.
> 
> Of course it would no longer be tunnelling ;-)

Aha! 8-)

> > But you need more than features to use an application protocol, you need
> > application semantics.  Are you suggesting that they be exposed as
> > features?
> 
> Well... I guess there is one existence proof there.... 
> 
> Whatever you are using you have to understand the semantics of the thing you
> are using. I'm not so hung up on the 'application' prefix.

Hmm, I guess I am hung up on them, because application semantics are
special; they're at the top of the stack.

> > If the resource state view is not important to them, why are they using
> > HTTP?
> 
> Because there is a binding available that provide features whose semantics
> they understand and because our charter mandated that we provide such a
> binding.

I guess this relates to the point above; binding SOAP to an application
protocol exposes more semantics than those exposed by the features and
MEPs we've associated with the binding.  Specifically, application
semantics are also exposed.  To quote Roy;

"The difference between an application-level
protocol and a transport-level protocol is that an application-level
includes application semantics, by standard agreement, within
the messages that the protocol transfers.  That is why HTTP is called
a Transfer protocol.  It is impossible to conform to an
application-level protocol without also conforming faithfully to
its message semantics."
 -- http://lists.w3.org/Archives/Public/www-tag/2002Apr/0303

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 3 July 2002 15:30:35 UTC