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

Hi Tim!  Here's the (quite belated, my apologies) response to your last
message on this topic:

> 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?

Again, I think that this problem is not just restricted to ONM-related
stuff, it's about generally making sure that things compose together
well.  If you're going to have one interface which uses XML Schema types
and another which uses RelaxNG, for instance, you won't be able to put
those two together very profitably in most cases either.

If indeed the actual functionality is that your service uses a hybrid of
unique GEDs and unique actions, then you should put in a marker which
indicates that such a system is in use.  This marker is what allows two
types of interoperable usage - 1) if I want to implement the described
service, I need to know how to differentiate operations, and 2) if I'm
an intermediary doing some work on behalf of the described service I
likely also need to know how to differentiate operations.

> 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.

While it doesn't entirely solve the problem, it does help.  Let's say I
have one interface which specifies abstract "action" values which are
unique, and another interface which doesn't specify actions at all (but
has unique GEDs).  When I get down to the binding which binds the
interface which extends both of these, I can choose at that point
whether to a) indicate that action is the preferred technique for ONM
and apply unique actions at the binding to all the operations from the
second interface, b) confirm that the interface that spec's action
values also happens to have unique GEDs and therefore all is well, or c)
indicate at the binding level some different way to dispatch (i.e.
"append the operation name to the endpoint URI" or somesuch).  If you
have the case you described, where the unique-GED interface specified
identical action values, you would need to either override the action
values somehow or take option (c) above.

The idea, I think, is that the interface-level stuff is simply abstract
information about the available operations (including metadata like
action values), not requirements as to how the actual implementations on
the wire have to do their work.  It's up to the binding/service/endpoint
to make sure that everything for a particular instance composes well and
makes sense together.

Again, sorry for the huge delay on getting back to you here.  Please let
me/us know any further thoughts you might have on this.

Thanks,
--Glen

> 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, 6 January 2005 15:39:55 UTC