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

Received on Monday, 6 January 2003 17:28:50 UTC