RE: Harvesting REST

Hi David

You ask ...

>>>Why wouldn't time to market be satisfied with doing only soap and wsdl?
It
would certainly preclude many of the ratholes on "why web services is
broken".<<<

Yes, but it would also, I think, preclude using Web Servics for business. 

As a bare minimum you need persistent security (so you can prove some time
after the message arrived that someone sent you a message) and reliable
messaging/delivery (so that you know the message will get through once and
only once).

The classic example I use for this is making a payment request to your bank
to transfer money to a suppliers account to pay a bill.

Firstly, the bank will be interested in being able to prove after the event
that YOU actually asked them to send the money and not someone pretending to
be you, SSL does not work for this.

Secondly, YOU will want the payment to go through just once - after all
no-one wants to pay a bill twice.

SOAP and WSDL on their own don't come anywhere close.

... I suppose it all comes down to requirements ...

David

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Tuesday, July 16, 2002 2:55 PM
To: 'Mark Baker'; 'Champion, Mike'
Cc: www-ws-arch@w3.org
Subject: RE: Harvesting REST



hmm.  When I was on the XLink WG, the charter specifically was for
"Hypertext" links, which always involved a user-agent.  Hence the
onload/onrequest actuation axis, etc.  Also why ranges (for drag'n drop in
gui apps) were added for xpointers.

There was explicit acknowledgement that hypertext linking was different than
more general purpose xml linking.

Why wouldn't time to market be satisfied with doing only soap and wsdl?  It
would certainly preclude many of the ratholes on "why web services is
broken".

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Baker
> Sent: Tuesday, July 16, 2002 10:05 AM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: Harvesting REST
>
>
>
> On Tue, Jul 16, 2002 at 12:30:15PM -0400, Champion, Mike wrote:
> > Hmmmm .... "Hypertext" (as most would define it) use cases
> have to do with
> > humans reading  textual representations of web resources.
> Web Services use
> > cases have to do with machines extracting and processing information
> > identified by web resources.
>
> If that is Eric's view, then I can understand what he means.  But
> hypertext is in no way restricted to human processing.
>
> > The issue is not the change of state of the resources, but
> the semantics of
> > the resources.  One can imagine mapping the semantics of textual
> > representations onto ontologies, etc. that would allow a
> machine to extract
> > and process information, but this has not been demonstrated
> AFAIK in the
> > "wild", only the laboratory.  So, as a practical matter,
> there are currently
> > different use cases for web hypertext and web services.
>
> Hmm, well, I'm not so sure.  If the choice is between an architectural
> style which has demonstrated its inability to be deployed at Internet
> scale, and one which has, though is still in the early stages of being
> used in the way that Web services needs, I know which one I'd choose.
>
> > BTW, I do agree with Mark B. that we ought to "harvest" the
> WEB (REST?)
> > architecture as one of the inputs into the WSA.  To not do
> this would both
> > deny the "web" part of web services, and would inflict upon
> us a long debate
> > that the TAG would probably resolve in favor of the REST
> advocates.  While
> > one might well argue that the 80/20 point of the WSA might
> exclude REST, it
> > would not IMHO  be conducive to time to market!
>
> Good to hear!  I agree.
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com
>
>