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

Quite a few tools (including all JAX-RPC-compliant implementations) can use
WSDL at runtime to dynamically bind to a service. These tools typically
generate the Java interface from the WSDL portType at compile time, but they
generate the communication proxy implementation from the WSDL binding at
runtime. This required feature of JAX-RPC lets the SOAP runtime dynamically
bind using the appropriate protocol (HTTP, JMS, SMTP, etc.) supported by the
service. It makes a lot of sense to also include additional protocol
information, such as supported compression mechanisms, in the binding.

Anne 

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Mark Baker
Sent: Tuesday, May 04, 2004 3:04 PM
To: Yaron Y. Goland
Cc: www-ws-desc@w3.org
Subject: Re: Static vs. dynamic aspects of a service description (was Re:
HTTP properties


On Tue, May 04, 2004 at 11:29:23AM -0700, Yaron Y. Goland wrote:
> Allowing implementers to define in WSDL what HTTP features they support, 
> e.g. GZIP, etc., enables a performance boost by allowing an on-line 
> discovery step to be skipped. Given that the whole purpose of WSDL is 
> effectively 'discovery', it seems reasonable to use a discovery 
> mechanism to discover even more useful information.

I guess this boils down to use-cases for WSDL.

The only way I've seen WSDL used in practice, is as a design-time tool
which declares the static aspects of a service.  This is in line with
its (pervasive) use in code generation.

But that's a very different use than you're describing there, which is
to use WSDL as a runtime tool (which, FWIW, I've been promoting by
trying to add some forms-like capabilities to WSDL, viz a viz
"urlReplacement").  And though I agree that there's a lot of value in
that approach, I'm concerned that it's being done without due
consideration to the problems it will create for those using it for
code generation.

I wonder if an extension couldn't be defined to allow a WSDL document
to declare whether what its asserting is intended to be true for all
time, versus just true at this moment in time, at a very fine level of
granularity (per feature)?  That would permit code generators to ignore
the "at this moment in time" assertions, thereby preventing them from
generating code which could break when that thing changes.

Thoughts?

Mark.

Received on Thursday, 6 May 2004 08:40:25 UTC