RE: Requesting WSDL Files

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.  One could argue that WS-RF is mostly REST compliant as it uses a constrained set of verbs.  

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.

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.

Cheers,
Dave


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Anne Thomas Manes
> Sent: Friday, July 02, 2004 4:38 PM
> To: jsled@asynchronous.org
> Cc: www-ws-arch@w3.org
> Subject: RE: Requesting WSDL Files
> 
> 
> 
> Responses inline marked by <atm> ... </atm>
> 
> -----Original Message-----
> From: Josh Sled [mailto:jsled@asynchronous.org] 
> Sent: Friday, July 02, 2004 6:04 PM
> To: Anne Thomas Manes
> Cc: www-ws-arch@w3.org
> Subject: RE: Requesting WSDL Files
> 
> On Fri, 2004-07-02 at 17:15, Anne Thomas Manes wrote:
> 
> > It's a "feature", not a requirement, and it enables SOAP to support
> > the REST architecture (which is protocol-specific). Regardless of 
> 
> How is REST protocol-specific?
> <atm> Okay -- maybe REST isn't protocol-specific, but it is 
> based on the
> semantics of the HTTP protocol. Besides, the WebMethod 
> feature defines a
> binding only for HTTP. </atm>
> 
> > whether or not it's right or wrong, this feature prevents you from
> > establishing a convention to return the WSDL when you do an HTTP GET
> > the Web service endpoint URL.
> 
> How does it prevent establishing convention?
> I thought the original question was about a convention of 
> using GET...?
> 
> <atm> It prevents us from establishing the convention that Savas was
> suggesting -- that if you perform an HTTP GET on the service 
> endpoint URI
> (without a parameter), you will get back the WSDL. </atm>
> 
> > I think it's a better convention to specify a parameter:
> > http://service-endpoint-uri?wsdl
> > http://service-endpoint-uri?xsd
> > http://service-endpoint-uri?policy
> 
> What is the better convention, here?
> 
> <atm> I'm saying that the prevailing convention of adding the ?wsdl
> parameter is a better convention than not adding the 
> parameter. I'm also
> extrapolating and saying that we can expand this convention 
> to return other
> types of metadata, such as schema and policy. </atm>
> 
> I thought 'http://host:port/endpoint_path?wsdl' was the convention...
> 
> <atm> It is. But Savas was suggesting an even simpler convention (no
> parameter). Unfortunately, Savas's suggestion is incompatible 
> with the SOAP
> 1.2 WebMethod feature. </atm>
> 
> But I'm confused: why perform a query at all?
> Isn't the WSDL just a file?
> 
> <atm> Not necessarily. Some tools generate the WSDL on the 
> fly at deployment
> time or when you query the service endpoint. </atm>
> 
> ...jsled
> 
> 
>

Received on Friday, 2 July 2004 20:56:34 UTC