RE: Binding

James,

thanks,

it is about time this point is made by example.

abbie


> -----Original Message-----
> From: James M Snell [mailto:jasnell@us.ibm.com] 
> Sent: Monday, January 06, 2003 5:29 PM
> To: www-ws-arch@w3.org
> Subject: Re: Binding
> 
> 
> 
> Coordination without Context is useless.
> 
> http://www.snellspace.com/blog/2j43h5kmne54324u23kjl234sdf878.html
> 
> - James Snell
>      IBM Emerging Technologies
>      jasnell@us.ibm.com
>      (559) 587-1233 (office)
>      (700) 544-9035 (t/l)
>      Programming Web Services With SOAP
>          O'Reilly & Associates, ISBN 0596000952
> 
>      Have I not commanded you? Be strong and courageous. 
>      Do not be terrified, do not be discouraged, for the Lord your 
>      God will be with you whereever you go.    - Joshua 1:9
> 
> 
> 
> Miles Sabin <miles@milessabin.com>
> Sent by: www-ws-arch-request@w3.org
> 01/06/2003 01:54 PM
> 
> To
> www-ws-arch@w3.org
> cc
> 
> bcc
> 
> Subject
> Re: Binding
> 
> 
> 
> 
> Mark Baker wrote,
> > On Mon, Jan 06, 2003 at 04:54:21PM +0000, Miles Sabin wrote:
> > > And the RESTless version could work just as well if we 
> substituted 
> > > "9ajp23q9rj89aweruwer" for "getLastSharePriceOfIBM". What allows 
> > > this, in *both* cases is the _prior_ coordination between 
> the client 
> > > which has,
> >
> > Wrong.
> >
> > I think it's funny (in an unfortunate way) that this benefit is so 
> > easily taken for granted.  It's called a *coordination* 
> language for a 
> > reason, ya know. 8-/
> >
> >   http://www.markbaker.ca/9ajp23q9rj89aweruwer
> >
> > Quick, before you type that into a browser window, tell me 
> everything 
> > you and your browser know about it and what I'm trying to 
> communicate 
> > to you by putting it in this email message.
> 
> Well now ... you're giving David all the ammunition he needs 
> for his part of the argument.
> 
> I know a fair bit about that URI a priori. I'm reasonably 
> confident that there's something on the end of it. Also that 
> any representation I get back will probably have a text/html 
> MIME type. It's textual content will be in English, and 
> relate to this thread in some way or another. Either that or 
> it's a rude message ;-)
> 
> I have that confidence because it's not _just_ a random 
> string of characters. It's a URI posted in a mail to this 
> list by a person, with a purpose, for human consumption. It 
> has a context, a context which is shared by its publisher 
> (you) and its consumers (the rest of us).
> 
> I also have a reason for _wanting_ to see what's on the end 
> of it: I'm just intrigued to see what's there. That's why 
> I'll follow the link when I've sent this mail.
> 
> But what if the consumer isn't a person? In general a machine 
> won't know anything about that URI, it can't even guess. It 
> won't autonomously follow it any more than it would follow 
> any other link composed of a random string of characters. 
> Unless, that is, it's a spider, in which case it'll blindly 
> follow any link it's given ... but this is a list for Web 
> _Services_ Architecture, not Web _Spider_ Architecture, and 
> presumably we're all interested in getting machines to 
> something a little more sophisticated than wandering blindly.
> 
> If we want to do that, then we have to provide the machines 
> with something analogous to the shared context that makes 
> link following make sense in the human case. Machines being 
> the dumb lumps of tin they are, that has to be a priori 
> shared knowledge and semantics encoded some how or other.
> 
> The SOAP/WSDL way of doing that is to encode knowledge in the 
> communicating endpoints. The encoding is mostly ... code: and 
> the SOAP/WSDL community has given developers a programming 
> model, idioms and toolkits to help do the job of writing it.
> 
> Another way of doing it might be to encode a significant 
> portion of that knowledge in the structure of the network 
> that the machines are traversing when they follow links. In a 
> way, that's putting spiders to work by designing the network 
> they wander over in such a way that their wandering produces 
> a useful result. That this can be done is an insight from the 
> mobile calculii people, and, IMO, it's the echoes of this in 
> REST which makes REST interesting.
> 
> But note ... even if the machines are dumber in this case, 
> the network has to be smarter. Qualitatively speaking, the 
> same work that goes into the design and implementation of 
> RPC-style clients and servers would have to go into the 
> design and implementation of a REST-style network. And it's 
> harder work, because the programming model and idioms are unfamiliar.
> 
> All that work has to be done up front just as in the 
> SOAP/WSDL case, it doesn't come for free, and it isn't all 
> there in RFCs 2396 and 2616 just waiting to be found.
> 
> Cheers,
> 
> 
> Miles
> 
> 
>