W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2004

RE: Static vs. dynamic aspects of a service description (was Re: HTTP properties

From: Champion, Mike <Mike.Champion@softwareagusa.com>
Date: Thu, 29 Apr 2004 11:25:57 -0400 (EDT)
Message-ID: <31DD0ECB10776B428B1186E60FB3D7B172C1D1@RESMSG02.AME.ad.sag>
To: www-ws-desc@w3.org




 

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org] 
> Sent: Thursday, April 29, 2004 10:54 AM
> To: David Orchard
> Cc: www-ws-desc@w3.org
> Subject: Static vs. dynamic aspects of a service description 
> (was Re: HTTP properties
> 
> 
> I'd like to understand the use case for this 

My understanding (not being actively involved in this stuff anymore) is that
it is essentially to validate that WSDL 2.0 is rich enough to describe a
RESTful service.  I believe you have explicated a number of use cases for
such services over the years :-)

> So what's the value in, for example, allowing a WSDL document 
> to declare "This service accepts gzip encoded documents", 
> when HTTP already does that? 

Again in my somewhat detached understanding, the point is to describe the
service in a way that is independent of its binding.  The classic use case
would be a service invocation that goes across multiple protocols between
the requester and provider, e.g. HTTP -> MQ -> SOAP wrapper around Mainframe
service implementation.  HTTP may know about gzip encodings, but that would
not necessarily map into any metadata that another protocol carries, but
would be necessary for the actual service implementation to understand.

If I have this wrong, I would appreciate being set straight by the WG.  I
know that in my Day Job I'm anxiously awaiting this capability in WSDL 2 and
the tools that will support it!
Received on Thursday, 29 April 2004 12:41:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:30 GMT