Re: 2004-02-12 Action Item: Clarification to the OperationName feature

Hi folks:

>> [description of using unique GEDs to map to operation names]
>
> This fits nicely into my concept of a style, less nicely into my
> concept of a feature declaration.  This is reflected in the component
> model - a style would not change the mapping to the component model,
> a built-in feature would.

Does the style attribute exist in the component model somewhere?  I would
think it would have to.  Assuming yes, then I don't see much difference
between another style URI and another feature URI.  As long as either one
can be used to confirm that the OName feature has been satisfied, we're
good.

>> 4) What is the implication of a built-in required
> feature on
>> the syntax and the component model.
>>
>> No impact on the syntax, and the component model gets a single
>> required
>> feature component which is always assumed to be there, I think.
>>
>> That is what the clarification indicated. The implications on the
>> syntax are
>>
>> -- none (for declaring the feature, because it is equivalent to be
>> declared to be "always present" as if it was declared to be required)
>
> The syntax might change (syntactic validity might be affected),
> depending on how you choose to specify the processing of <wsdl:feature
> uri="...OperationName" required="false"/>, which is currently allowed
> in the syntax.  I'd think a concrete proposal on this would be
> valuable. Is this particular element an error, silently ignored, or
> result in duplicate feature components?
>
> Which uncovers an issue; currently the component model for...
>
>   <wsdl:interface>
>     <wsdl:feature uri="myURI" required="true"/>
>     <wsdl:feature uri="myURI" required="false"/>
>   </wsdl:interface>
>
> ... would have two conflicting (I assume) feature components.  What is
> the meaning of such conflicting components?  Should the syntax or the
> mapping prevent such conflicts?

I don't think there's a conflict, but I think you're right, we need to
specify this, and a few other things besides (i.e. how features + properties
combine when specified in the interface/operation/binding).

IMHO, the above should be allowed and would have the same effect as if there
were just the required="true" version.

>> -- for bindings, the implementations will need to be declared as soap
>> modules, etc.
>
> Glen said I could use ESP.  I'm not sure whether you include that in
> the "etc."

To be clear - I said you could use ESP as long as you had a feature URI for
it, and accepted the fact that if someone you were talking to didn't
understand ESP, they were out of luck.

>> As stated above, this is a good thing IMO, because looking
>> at the WSDL, it is obvious to infer the implementations that are
>> engaged.
>
> I'm not sure what is obvious here, part of my ignorance of features
> and properties is showing.  There are two things that could be
> influenced by a feature - whether the WSDL should be rejected by a
> processor, and what appears on the wire.  There appears to be an

Actually, that's the wonder of extensibility - features can actually
influence whatever they want, in a very similar way to that of SOAP headers.
If I see a recognized feature in the WSDL, and I know that the meaning of
that feature is "I agree to let the messages that flow between us be
published in the New York Times", then I might not see any difference at all
on the wire when using this service and one which does not specify such a
feature.  However my expectations of seeing my message on tomorrow's front
page certainly would be affected.

> assumption that a required feature, when no corresponding
> implementation feature can be found, results in a bad WSDL.  There

Correct, although not all features actually need an implementation per se
(some might be self-contained).

> also appears to be an assumption that a required feature may
> interact, or override, the corresponding implementation feature.

I'm not sure what you mean by this last bit.

> The concept of relating two features (abstract and implementation) is
> not supported by the WSDL spec, and not detailed in the OperationName
> proposal.  The precise outcomes (for the WSDL processor and for the
> messages on the wire) need to be detailed.

The relationship between features is up to the feature specification writers
and to the user of the WSDL, just as the relationship between SOAP headers
is up to the module specification writers and the user of the SOAP envelope.

> For instance, let me create a matrix of options, using the
> OperationName feature (pretending it's not built-in) and soap:action
> module as examples.
>
>   OperationName   SOAPAction  |  WSDL  Behavior
>   Feature         feature     |
>   ----------------------------------------------------
>   required        required    |  OK    Messages       contain
> soap:action
>   required        present     |  ?     ?

In this case the availability of the SOAPAction feature (by which I'm
assuming you mean the operation dispatch SOAP action feature that we
proposed, not the generic one in SOAP 1.2) means that the processor can
choose to use it to satisfy the OName feature if desired.  If it's the only
way indicated, then the action parameter will hold the operation info in
messages.  If there is another way as well, it might use either.  To be
clear, when you say "contain soap:action" here, you mean that the operation
info is carried in the action parameter.

The WSDL is OK for a given processor if there is an implementation (either
required or optional) of the OName feature which that processor understands
in the context it is dealing with.  So if I say in a given service "you can
either do the SOAPAction thing or the SOAP header thing, but neither are
themselves required" (this would generally be a "pick one"), then as a
client you're fine if you do either of those things.  As a server
implementing this WSDL, however, you're going to have to do both, since you
won't know which one a given client is going to pick.

This is equivalent to making statements about other extensions, like
security policy.  If a WSDL says you can use either username/pw or x.509
certificates, and you want to implement that WSDL as a service provider, you
need to support both.

>   required        absent      |  ?     ?

If there is nothing else in the WSDL (i.e. the OName module, RPC style...)
which satisfies the feature, you can't process the WSDL.

>   present         required    |  OK    Messages       contain
> soap:action
>   present         present     |  OK    Messages may   contain
> soap:action
>   present         absent      |  OK    ?

In this case, your message aren't likely to contain the operation info in
the action parameter.

>   absent          required    |  OK    Messages       contain
> soap:action
>   absent          present     |  OK    Messages may   contain
> soap:action
>   absent          absent      |  OK    Messages don't contain
> soap:action

--Glen

Received on Wednesday, 25 February 2004 11:26:24 UTC