Re: Protocol independence

On Fri, 4 Apr 2003 12:27:17 -0500, Mark Baker <mbaker@idokorro.com> wrote:


>
> That's true, but you're forgetting the most important difference;
> not all of those protocols are transport protocols.  For example,
> BEEP has no method for "get me data", while HTTP does.  You can't
> expect that bits sent with one can have the same meaning when sent
> with the other; bits sent with BEEP necessarily has to include a
> method, whereas bits sent with HTTP does not.

So sorry, I just find this mystifying.  A bit is a bit; how it got from one 
process to another is an implementation detail, at least in my own vision 
of what XML web services are all about.  I fully agree with much of the 
REST position when you talk about the advantages of leveraging the HTTP 
infrastructure in a way that exploits it in specific applications(e.g., by 
using GET to get things over the Web, so as to exploit caches and allow 
hyperlinks), but I simply don't understand this concern with the 
relationship between the methods of the message transport mechanism and the 
operations implied by the content of the message.  The JavaSpaces example 
is a bit, uhh, fishy, but it does illustrate that sometimes you have to 
write()a request to be able to read() the result.  HTTP GET probably makes 
more sense for the canonical getStockQuote use case, but that's an 
engineering decision by an implementer, not an architectural decision for 
the Web services community.

> For example, SMTP
> should not be used to retrieve things.

I use SMTP to retrieve things all the time!  mailto:somebody@somewhere.com - 
- "Uhh, I can't get to that document on your intranet ... could you please 
send it as an attachment?  Thanks."  Why shouldn't a machine be able to 
mail another machine to request that some information be sent?  Why should 
a web service back end care whether the request came in over SMTP or HTTP 
or MQ or JMS or hyperwave or snail mail?

Received on Friday, 4 April 2003 13:28:28 UTC