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

Glen Daniels wrote:

>RE: 2004-02-12 Action Item: Clarification to the OperationName
>featureBonjour, Jonathan (just getting ready for next week):
>
>  
>
>>Jonathan wrote:
>>    
>>
>>>>Unique message element QNames is a reasonable way to
>>>>        
>>>>
>>ensure that a
>>    
>>
>>>>service can dispatch a message to the right operation.
>>>> But as I understand it, such a mechanism would not satisfy the
>>>>OperationName feature, which would require extra (and
>>>>        
>>>>
>>unnecessary in
>>    
>>
>>>>this case) goo to be squirted into the message.
>>>>        
>>>>
>>Glen responded:
>>    
>>
>>>Hm, I think you are missing something here.  Making the
>>>      
>>>
>>operationName
>>    
>>
>>>feature an ABSTRACT feature was precisely so that we can allow
>>>      
>>>
>>multiple
>>    
>>
>>>different ways of satisfying it.  One of these ways is
>>>      
>>>
>>using the RPC
>>    
>>
>>>style, for instance - that does not require any "extra goo" in the
>>>message at all.  It simply says "when using this style, the
>>>      
>>>
>>feature is
>>    
>>
>>>satisfied because the QNames are unique".
>>>      
>>>
>>I don't want to be argumentative, but no it doesn't.  It specifically
>>says: "If an operation is defined using the style property
>>indicating RPC style, the Name of the operation is required
>>to be part of the message exchanged, because the QName of the
>>input element must match the operation targetNamespace and
>>NCName and it uniquely identifies the operation. Therefore,
>>the operations within interfaces that utilize the RPC style
>>are considered to be compliant with this feature as operation
>>names are part of the GED. However, if bindings support one
>>of the implementations as stated above, the additional header
>>defined by OperationDispatch module is allowed to be
>>included, but not required, when RPC style is used."
>>
>>My paraphrase differs from yours, and says that the feature
>>is satisfied because the operation names _are_ encoded in the
>>message.  Just using unique GEDs on your messages doesn't
>>constrain the GEDs to match the operation names, and
>>therefore fails to satisfy the feature.
>>    
>>
>
>Sorry, yes, you're quite right, I didn't phrase that as well as I might
>have.  It's not the uniqueness of element QNames that matters in the
>RPC-style case, but their precise equivalence to the operation QNames.  The
>case below is different.
>
>  
>
>>>We could also imagine another
>>>feature or style whose spec said essentially the same thing without
>>>      
>>>
>>the
>>    
>>
>>>other RPC rules about schema structure.  But you still want
>>>      
>>>
>>SOMETHING
>>in
>>    
>>
>>>the WSDL to describe what's going on - a hint to the processor that
>>>      
>>>
>>says
>>    
>>
>>>"hey I'm asserting that all my QNames are unique, so you
>>>      
>>>
>>can feel free
>>    
>>
>>>to fault if you discover duplicates".
>>>      
>>>
>>Like I said, that might be a good idea (indeed that's what I
>>thought this proposal going to look like), but I don't think
>>that would satisfy the OperationName feature, which says:
>>"OperationName feature is an abstract feature that indicates
>>that the Name of the operation will be conveyed to the
>>receiver in a message exchange."  Later on there's some stuff
>>about an "operation's fragment identifier" but I can't make
>>much sense of that so I'm taking the _Name_ as the thing that
>>must go into the message.
>>    
>>
>
>I think that a feature as described above (unique element QNames but not
>exactly those of the operations) would still carry that same information,
>but it would do it through the isomorphic relationship of the element QNames
>to the operation QNames.
>
>  
>
>>>>I agree that a service needs to be able to know what to
>>>>        
>>>>
>>do with any
>>    
>>
>>>>particular message.  That's built into my assumption about how to
>>>>build any Web service.  But constraining the solution to this
>>>>problem to the particular strategy of inserting the
>>>>        
>>>>
>>Operation Name
>>    
>>
>>>>into the message doesn't seem right.
>>>>        
>>>>
>>>Agreed, and the feature doesn't say that you must insert it
>>>      
>>>
>>into the
>>    
>>
>>>message explicitly in any way.  It just says that the
>>>      
>>>
>>information MUST
>>    
>>
>>>somehow be transmitted from the sender to the receiver.
>>>      
>>>
>>Ah, OK, if we're not constraining the message in any way I
>>have less concern.  The proposal text should make that
>>clearer.  The logical extreme of what you're saying is that I
>>can actually satisfy this feature by sending messages that
>>are indistinguishable on the wire and the server can use
>>extra-sensory perception for all I care to tell them apart.  Right?
>>    
>>
>
>Yup, exactly.  The key bit is that anyone processing the WSDL has to
>understand the way this is being done, which simply means understanding that
>"my-esp-feature" is a valid way to implement the operationName feature.
>
>  
>
>>>>In any case, if functionality is always "required", there doesn't
>>>>seem to be much point in giving it a feature URI that can
>>>>        
>>>>
>>appear in
>>    
>>
>>>>the markup and will appear in the component model,
>>>>        
>>>>
>>instead of just
>>    
>>
>>>>using text in the spec.
>>>>        
>>>>
>>>Two reasons.  First, for consistency, since it is a real feature.
>>>      
>>>
>>Currently, a feature in WSDL can be engaged or disengaged.
>>This feature is apparently always on, from which I infer that
>>it always appears in the component model.  We don't have that
>>concept in WSDL right now, which is why I'm probing at this
>>point.  Since it doesn't fit into our current framework,
>>perhaps it shouldn't be shoehorned into that framework.  And
>>if the framework needs expanding, aren't there lots of other
>>qualities/attributes/features/functionalities of a working
>>Web service that should be treated this way?
>>    
>>
>
>I don't think there's any "shoehorning" needed here.  We could certainly do
>this by saying "this is a required semantic which we aren't going to name,
>but you have to do it somehow".  The problem with that approach is that it
>becomes difficult to indicate in a binding/extension/etc that "I do *that*
>thing".  This is precisely what features are for, and if it looks like a
>duck, and quacks like a duck....  Making it a "built in" feature is
>certainly a first, yes, but doesn't seem that odd to me.
>
>  
>
>>>Second, because giving it a URI allows other specifications to be
>>>written (i.e. the operationName SOAP module, or another
>>>      
>>>
>>binding which
>>    
>>
>>>might include operation names in some transport-specific way) to
>>>unambiguously refer to the semantic we're talking about.
>>>      
>>>
>>That's the
>>    
>>
>>>whole point of naming it.  As a side benefit, you can also make RDF
>>>assertions about the feature once it has been given a URI.
>>>      
>>>
>>I can't think of useful reasoning.  It can't be turned on or
>>off, and so can only be usefully referred to as a static
>>quality of a correctly working Web service.  You can already
>>make statements about a WSDL-conformant Web service by using
>>the WSDL spec URI - this assertion could easily be part of
>>that assertion.  Or are you suggesting we give URIs to each
>>quality we can distinguish, for instance "this service
>>exchanges messages"?
>>    
>>
>
>I'm not sure if I'd go that far, but certainly MEPs and the like (which we
>do call out) are things you might reason about.  And it's not so much that
>you'd be reasoning about a particular service, but more likely that you'd be
>reasoning somehow about the feature itself.  Let's say someone wrote a
>feature which actually satisfied all the rules of the operationName feature,
>but didn't note that in their spec.  You could make an RDF assertion that
>said "feature A implements the operationName feature", and that would enable
>anyone who understood that assertion to use feature A as such an
>implementation.
>
>  
>
>>My purpose here is to clarify the proposal so we can make
>>faster progress on it - I hope you take my questions in that
>>spirit.  To recap, some things that aren't clear in my
>>reading of the proposal:
>>    
>>
>
>I need to go and read Umit's version of the proposal again, actually - some
>of my statements here are based on an earlier take, so I should vet them
>against the version on the public list.  I'll do that ASAP.  All the answers
>below should be considered prefixed with "IMO".
>
>  
>
>>1) Whether the operation name itself must appear in the message.
>>    
>>
>
>Not as such, no.
>
Jonathan, I am assuming what we are referring to as "message" is the 
soap:body, not envelope, namely the element references (GED)s, right?

It only appears in the message as a side effect of using RPC style, due 
to the definition of the RPC style only if you are using RPC style. This 
is NOT an additional requirement brought by the feature, it just happens 
because one uses RPC style. The proposal indicates this.

>
>  
>
>>2) What "operation's fragment identifier" means about what
>>goes into a message.
>>    
>>
>
>I think that's referring to the fact that operation names are in fact QName
>*tuples* made up of the interface QName and the operation QName, therefore
>there are really two QNames you need to uniquely identify an operation.
> Hm - this might actually be a problem, in that the "unique GEDs" or
>RPC-style approaches do not actually carry the interface information... but
>I guess the claim there is that the GEDs are unique for all operations in
>the aggregated interface, no matter which parent interfaces they come from,
>so it's still a good mapping.  We should change the description of how RPC
>style works to account for that.
>  
>
Due to the rules of inheritance and by limiting itself to a single 
interface, operation names are always QNames WITHIN the scope of a 
single interface and are treated as such. However, when you don't have 
this scoping, of course, they can not be treated as QNames, current 
Part1 explicitly warns about this problem.



>  
>
>>3) How a service that simply used unique GEDs for each
>>message would interact with this feature.
>>    
>>
>
>You *could* state that the "default" implementation of the feature is to
>simply map unique GEDs to their operation names, and then it would only be a
>problem if you a) didn't find anything else in the WSDL (a SOAP module /
>binding) which implemented the feature AND b) there were in fact duplicate
>or undefined GEDs.  I would prefer an approach which forces the WSDL
>developer to somehow explicitly assert (via a style or a feature
>declaration) the claim that all the relevant GEDs are unique.  This is kind
>of the same reason we have the RPC style - you *could* figure it out on your
>own by just looking at the schema, but the style helps you decide up front
>how you want to deal, and whether to bother engaging potentially expensive
>checks.
>  
>
+1.

Everything in the contract must be explicitly stated, if we would like 
it to be interoperable.

>  
>
>>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)
-- for bindings, the implementations will need to be declared as soap 
modules, etc.  As stated above, this is a good thing IMO, because 
looking at the WSDL, it is obvious to infer the implementations that are 
engaged. As Glen also stated, it is easy to find a relationship between 
the feature and its implementations when the implementation technique is 
explicitly stated in the WSDL as well.

>
>  
>
>>5) Why is an explicit feature URI useful if the feature
>>represents a static quality of any working Web service.
>>    
>>
>
>See above.  First so that you can say "hey, this here new module does *that*
>thing" and second so that you can unambiguously refer to the semantic in
>whatever way (RDF) you want.
>
I don't have much to add to Glen's comments. If we are going to allow 
different implementations of the feature, it is essential that we name 
the feature so that implementations can refer to it.

>
>--Glen
>
>
>  
>
--umit

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com