Re: Binding

Chris,

On Tue, Jan 07, 2003 at 06:46:09PM -0500, Christopher B Ferris wrote:
> > Well, I disagree for esoteric but important-on-a-large-scale reasons.
> > But I don't consider those significant for this example, so ok.
> 
> What reasons? I'm curious.

I can respond off-line if you like.  It's not relevant to this
discussion, and we've got enough stuff on our plate already. 8-)

> Is it not reasonable to want to accomodate software agents that have
> this understanding "hard coded" in the software that implements the agent?

It's entirely reasonable.  I'm surprised you thought I believed
otherwise!  As I said elsewhere, I was trying to avoid mentioning
Semantic Web technologies for the most part, because I have a good
idea how I'll be received.

And besides, I think there's a lot of value in vanilla REST based
Web services without the Semantic Web.

> > The difference between WSDL based knowledge, and REST based knowledge,
> > is that REST's knowledge doesn't impact the binding qualities of the
> > interaction.  So a client written to know how to place trades, can do
> > so with any service that supports the same schemas.  A Web services
> > approach requires that *both* interface and schemas match up.
> 
> Nonsense. You must be assuming RPC style here...

(I think you and I have been over this before.  I'll try again, but
from a slightly different angle.)

Sort of.  You and I disagree on what "RPC style" is though.  I define
"RPC style" as a style of Web service where the developer defines the
methods/operations.

This is in contrast to when developers use the methods provided by
the underlying application protocols.

Do you see how that relates to this binding discussion?  That an
application protocol defines the interface to which an application
binds?

> There is no reason 
> whatsoever why
> you cannot design a Web service such that it used a document-centric and 
> RESTful style of interaction.

Absolutely, so long as there's no method in the SOAP envelope, or a new
HTTP-like protocol is developed on top of SOAP (i.e. where the methods
in the SOAP envelope mean the same as HTTP methods; GET, PUT, etc..,
i.e. they are uniform).

> Are you suggesting that somehow the RPC style of interaction is part of 
> the
> Web services architecture? Are you suggesting that REST precludes that
> style? 
> 
> Think again. 

Well, with my definition of "RPC style", yes, I think it's most
definitely part of the Web services architecture.  I think most Web
services developers would be quite shocked at the prospect of not
defining their own network APIs! 8-)

> > The structure of URI space is *completely* irrelevant, because the
> > service creates the URIs, and clients use them opaquely without any a
> > priori knowledge of what each one is; the a priori knowledge is in the
> > code that interprets the schemas and understands what it means for some
> > token, such as a URI, to be in a particular place.  The first point #3
> > above demonstrates this.
> 
> And your point is what? I believe that you have successfully argued Miles'
> case for him.

Miles and I are still struggling through that.  We appear to understand
each other though, but I'm not sure you and Mike are following. 8-/
Assuming that your responses indicate interest, I will however continue
the discussion.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Wednesday, 8 January 2003 00:19:00 UTC