RE: Requesting WSDL Files

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Sanjiva Weerawarana
> Sent: Friday, July 02, 2004 7:32 PM
> To: www-ws-arch@w3.org
> Subject: Re: Requesting WSDL Files
> 
> 
> 
> Hi DaveO,
> 
> > Arguably HTTP is based upon the semantics of REST.  
> Modelling a view 
> > of the world through generic verbs performing transfer of state 
> > representations is hardly limited to http. 
> 
> Agreed. Would you consider NFS RESTful?
> 

Mostly.   It does model it's world as resources with state that are exchanged via representations using a constrained protocol.  I'm not sure if the messages are self-describing though.  Just don't know enuff about nfs.

> > One could argue that WS-RF is mostly REST compliant as it uses
> > a constrained set of verbs.  
> 
> If that were the interpretation then once you *define* *any* interface
> all services that use just that (now fixed) interface would be REST
> compliant.
> 
> I just don't see how one could consider WS-RF RESTful .. can you 
> expand more please?

Sure, but check out the constraints described in Roy's thesis and compare those with WS-RF.  At a high level, I think they think about the world in the same way.  WS-RF views it's world as a set of properties that represent the state of resources, which are exchanged using representations by a constrained protocol.  My take on it from a direct comparison of REST to WS-RF is RF:
- uses constrained operations to interact with resources (the get/insert/update/delete)
- uses hypertext as the engine of state transfer.  Hypertext really meaning "active documents" where active means they have "links" in them.  And I consider EPRs to be "links".  I spent some time on the TAG making sure that the issue of "hypertext" and metadata where dealt with.  In the Web arch section 4.4 on hypertext, http://www.w3.org/TR/webarch/#hypertext, we see that when one resource refers to another with a URI, this constitutes a "link" between two resources.  WS-RF supports EPRs with either no reference properties or with ref properties.  I don't really want to quibble about whether the ref properties are considered metadata or data. 
- is self-describing (xml+soap+ws-addressing action).
- is layered client server
- It doesn't follow the caching aspect of REST, where the cache control logic is built into the protocol, but that's usually not quoted as part of being "RESTful".  FWIW, why WS-RF doesn't want caching for the GET requests is beyond me.  

As I showed in my "WS-REST" proposal to WS-RF, there is a pretty straightforward binding of WS-RF messages to HTTP verbs, the exception being mapping some of the WS-Addressing asynch parts onto HTTP.  

If people want to dispute whether WS-RF is "RESTful" or not, I'd prefer it if they gave concrete technical reasons rather than "I don't think so" or "doesn't feel like it to me".  The constraints that make up REST are rigorously defined and WS-RF can be directly evaluated against them.  For example, I could see an argument being used that says something like: WS-RF isn't RESTlike because EPRs aren't links.  They aren't links because the use of reference properties takes the resource "off the web".   Now I have counter-arguments to that in mind, but that's the kind of argument I'd expect.  

> 
> > FWIW, there *always* seems to be a debate when using a generic verb
> > set on how to get representation of the metadata.  The metadata is
> > definitely a different resource so it needs either a new 
> verb or URI. 
> > I think the Semantic Web folks were debating about an MGET verb.
> 
> Taking a protocol independent view, how would that map to say SMTP
> or JMS carrying the messages?

I'd say there needed to be either a new message type or URI (queue?) for JMS or SMTP.  My guess would be that JMS would need some kind of 

> 
> > I like the idea of formally specifying an extension/feature/property
> > that a service provider could put in their WSDL to say "do x to get
> > metadata".  It has the classic bootstrap problem though.
> 
> Right .. so I view WS-MetadataExchange like Java's Class object or
> COM's QueryInterface method. Every Web service must support being
> asked "tell me about yourself" .. just like in Java you can ask any
> object for its class and from that get all the metadata necessary
> to execute something in it. That of course does not mean that the
> Web service implementor has to handle those messages himself (or
> herself); the "infrastructure" has to do that.
> 

I think that's a great way of looking at it.  There's cases where you get the metadata from somewhere other than the object - like a registry - and cases where you discover the metadata from the object/resource.  There is a choice to be made: whether to make a new operation for getting the metadata, or re-using existing operations/protocol and using some kind of URI.  There are 2 different extensibility points for the functionality.  There is appeal to both.  

I do think it is a shame that trying to bridge the "arbitrary verbs" versus "constrained verbs" is really hard.  Each optimizes for different cases.  I think that arbitrary verbs optimizes for the "update/write of things with side-effects" and that constrained verbs optimizes for the read case.  And both are really important.   I hate having to come up with a new verb every time I change my schema (the abitrary verbs), and I hate having to shoe-horn the updates with side-effects - like setTimeOut(0) - into a generic update operation.  WS-MetadataExchange partially bridges the gap, and that's a good thing.

Cheers,
Dave

Received on Monday, 5 July 2004 14:24:07 UTC