RE: A priori; the big secret

Well said, Suresh.

Mark,

The big secret has turned out, to me at least, to be
conceptually very similar to the approach taken in POSIX,
which I alluded to during the last telecon.  A salient benefit
of the approach is that portable programs, or in WSAWG's
context, web services can be realistically built and deployed,
relying on "a priori" knowledge inherent with a set of standard
methods.  So the idea is IMO a "good thing."   I've seen it fly.

Calibration of details: 
I think, agreeing with Suresh, the semantic abstraction should
be one level above your proposed HTTP-ish methods.
The proposed faults may serve as an example for what's just about
right (in terms of semantic abstraction), IMV.  That is, they're
higher in level of abstraction, can be mapped to some HTTP 300's,
400's, or even 500's in an HTTP binding; but don't lock the
programmers into one binding.

BTW, have you settled (in your mind) on whether this will be
manifested as a protocol or an interface?  (They are not the
same for the discerning, as you well know.)

Cheers,

Joe Hui
Exodus, a Cable & Wireless service
================================================ 

> -----Original Message-----
> From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> Sent: Wednesday, May 22, 2002 4:07 PM
> To: www-ws-arch@w3.org
> Subject: RE: A priori; the big secret
> 
> 
> 
> I agree with and support the broad notion of the a-priori protocol,
> which I think will support interoperability of systems built with
> partial compliance to standard interfaces by allowing discovery
> of supported interfaces at each party's side.
> 
> However, I disagree with the implementation dependency on HTTP.
> I would prefer building the same protocol using SOAP,
> and make the binding for HTTP, SMTP, FTP, BEEP, what have you.
> This will help wider adoption of this protocol.
> (I remember discussing it as the "zero protocol") 
> I cannot offer a counter proposition right now, but shouldn't 
> be a stretch.
> 
> Cheers,
> -Suresh
> 
> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, May 22, 2002 1:35 PM
> To: www-ws-arch@w3.org
> Subject: A priori; the big secret
> 
> 
> I'm having a really bad day today, so I thought I'd try to liven it up
> by describing the interface that I had in mind for the 
> recently accepted
> draft requirement that I proposed about "a priori".
> 
> In order to build the most general interface, we need to look at what
> things are common about *all* Web services.  Here's a rough list;
> 
> - each is identifiable by a URI (or at least that's what our working
> definition says).
> - each will have a lifetime; at some point it will be 
> created, and some
> will eventually disappear.
> - each will have state, if you count the "null" state for stateless
> services
> - each should be able to be restricted to authorized users.
> - sometimes, a Web service might have to relocate
> - sometimes, by mistake or intent, a Web service might just 
> not be there
> 
> So, here's my stab at the methods and responses.
> 
> Proposed methods;
> 
> - GET() - used to return a representation of the identity and state of
> the Web service.  For example, a GET on a Web service that controls a
> lightbulb might return an XML document describing whether the 
> lightbulb
> is on or off; <lightbulb state="on"/>
> - PUT() - used to set the state of a Web service.  For 
> example, we could
> change the lightbulb document, and then PUT() it back, thereby turning
> the lightbulb off; <lightbulb state="off"/>
> - POST() - used to hand a document to a Web service for processing.
> Only the Web service gets to decide what to do with the document.
> - DELETE() - requests that the Web service be deleted.  It 
> doesn't have
> to delete itself if it doesn't want to.
> 
> Faults
> - unauthorized - you aren't yet authorized, but here's what 
> you have to
> know in order to be.  Fill it in and respond back.
> - forbidden - sorry, you're not allowed
> - not found - sorry, can't find this Web service
> - relocated temporarily - for now, please use this other Web service,
> but keep checking back here
> - relocated permanently - please use this new Web service, 
> and you might
> as well forget about the URI you used to get here, since it 
> ain't coming
> back
> - gone - sorry, this Web service has been removed
> 
> Hopefully you now understand why I'm such a big fan of HTTP and Web
> architecture.
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com
> 
>

Received on Wednesday, 22 May 2002 20:57:22 UTC