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

RE: Last Call issue: How does the Operation Name Mapping Requirement (Part 1, section 2.2.1.1) relate to interface inheritance?

From: Tim Ewald <tewald@microsoft.com>
Date: Thu, 16 Sep 2004 11:46:28 -0700
Message-ID: <7C5CC590304B6E41AE2A0E97D54DDF5603B61874@RED-MSG-31.redmond.corp.microsoft.com>
To: "Glen Daniels" <gdaniels@sonicsoftware.com>, <www-ws-desc@w3.org>

Glen,

Thanks for the response. I'm not sure whether this really addresses my
concern or not. I see two obvious ways to handle the ONM: a unique GED
for every operation or the WS-Addressing Action header (wsa:Action).
Obviously other approaches are possible.

In my perfect world, people would do both, but there's certainly not
reason why they have to. What I worry about, though, is that some
interfaces may use unique GEDs but the same action (maybe none or "")
and others may use duplicate GEDs and different actions (this is
mandatory if you use #any or #element for any operations). What happens
if a service wants to implement interfaces of both sorts? Because a
service can only specify one mechanism to meet the ONM requirement, will
it even be possible out of the box? Or will someone have to make up a
new mechanism that relies on some weird combination of GED and action
header?

In short, I'm afraid that ONM may leave us in a world where there are
different types of interfaces and a service can't derive from two
different types. Worse, the difference between the types will be subtle
indeed. As far as I can tell, specifying the ONM mapping on the service
doesn't solve that problem. It just moves it away from the interfaces.

BTW, I'm not on the www-ws-desc list, so please CC me if this turns into
a thread.

Thanks,
Tim-

> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@sonicsoftware.com] 
> Sent: Wednesday, September 15, 2004 4:09 PM
> To: Tim Ewald; www-ws-desc@w3.org
> Subject: RE: Last Call issue: How does the Operation Name 
> Mapping Requirement (Part 1, section 2.2.1.1) relate to 
> interface inheritance?
> 
> 
> Hi Tim!
> 
> We discussed this at the WSDL face-to-face, and resolved the 
> following:
> 
> First, the particular implementation choice you make for the 
> way you do Operation Name Mapping will generally be specified 
> in a binding or even a <service>, and not so much at the 
> abstract interface level.  When this is the case, you 
> wouldn't need to worry about clashes in the way you inquire 
> about below, since there generally would be only one way to 
> meet the requirement for a particular service's component model.
> 
> Since nothing actively prevents you from in fact declaring 
> Operation Name Mapping (ONM) mechanisms at the interface 
> level, however, your questions are still very valid and 
> interesting to consider.
> 
> > Can a derived interface meet the Operation Name Mapping Requirement 
> > using a mechanism different from the mechanism(s) used by its base 
> > interface(s)?
> 
> We ended up resolving this by deciding to move the Operation 
> Name Requirement to the service component, rather than the 
> interface.  The rule will now be that either all the GEDs in 
> the interface operations *of a given service* must be unique, 
> or some extension or feature *in scope for that service* must 
> define how the name disambiguation is being accomplished.  
> Since there is already a scoping rule for features, it's easy 
> to determine which ones are active.  With custom 
> extensibility elements, it's up to the author of the 
> extension to decide how to determine what the scoping is 
> (i.e. "if you see this extension in the <interface>, it holds 
> for any service with the enclosing interface in its 
> inheritance hierarchy", etc).
> 
> A larger point - the questions you raise apply not only to 
> ONM, but also to extensions in general.  Since we don't 
> constrain the meaning of extensions, it's up to the authors 
> of individual WSDLs to ensure that the set of active 
> extensions/features for a given scope compose well together.  
> Just as it's possible to declare two different extensions 
> which disambiguate operations in incompatible ways, it's 
> possible to declare two security profiles which each require 
> a different (and
> incompatible) type of encryption.  We are adding some 
> clarification text which discusses this.
> 
> > If not, is it a requirement that a derived interface only 
> extend base 
> > interfaces that use the same mechanism to meet the Operation Name 
> > Mapping Requirement?
> 
> As mentioned, the requirement is now that for each service, 
> either the GEDs are unique or some in-scope extension 
> declares the disambiguating technique.  Therefore it's fine 
> for interfaces to extend anything they want, as long as a 
> compatible set of semantics results when the most-derived 
> interface is used in a service.
> 
> > If so, is it then the case that a single derived interface can not 
> > extend multiple base interfaces that use different 
> mechanisms to meet 
> > the Operation Name Mapping Requirement?
> 
> Same answer as above.
> 
> We will be updating the spec to reflect the changes I 
> mentioned, and we hope this satisfactorily answers your questions.
> 
> --Glen on behalf of the WSDL WG
> 
> 
Received on Thursday, 16 September 2004 18:46:59 GMT

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