RE: FW: LC Comments: Web Method Feature

Hi Mark,

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 03 July 2002 18:35
> To: Williams, Stuart
> Cc: 'xml-dist-app@w3.org'
> Subject: Re: FW: LC Comments: Web Method Feature
> 
<snip/>

> > > I have to admit to being confused by the suggestions to derive the
> > > method.  Why is that desirable? 
> > 
> > Well we continue to have the two views... the chameleon view and the
> > messaging/tunneling view. 
> 
> 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.
 
> > We are close to a position that admits both views. The Web Method
features
> > enables the chameleon to take on the REST resource state manipulation
and
> > retrieval view. Mandating its use (needlessly IMO) denies the
> > messaging/tunneling view.
> 
> For HTTP, yes it does, more or less.  It encourages SOAP implementations
> to expose the method in some manner to developers, thereby breaking the
> notion of SOAP as a layer when bound to HTTP.  This is a good thing IMO.

Encouragement is fine. Exposure is mandated, but at least for me the notion
of SOAP as a layer when bound to HTTP is not broken.

> 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.

> 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 ;-)

> > > A developer has to know what methods are being invoked.  How else can
they get their job done?
> > 
> > Developers of binding implementations will know... the binding
specification
> > will tell them.
> > 
> > Developers of SOAP applications will know the semantics of the features
they
> > use, because the feature specification will tell them.
> 
> 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.

> > If the resource state view is important to them, they will use the Web
Method 
> feature. If they think more in terms of message exchange (in a binding 
> agnostic fashion) Web Method is unlikely to be a feature they will use.
> 
> 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.

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

Regards

Stuart

Received on Wednesday, 3 July 2002 13:54:45 UTC