Re: Action Item 2004-07-01 Solution to 168/R114

Hugo Haas wrote:

>* Umit Yalcinalp <umit.yalcinalp@oracle.com> [2004-07-07 17:02-0700]
>[..]
>  
>
>>OperationName Feature: 
>>
>>This specification defines an OperationName as an abstract Feature
>>that is required for all WSDL documents.  OperationName Feature is
>>identified with the URI value:
>>http://www.w3.org/TR/wsdl20/features/operationName.
>>
>>This Feature is assumed to be always present in the component model
>>and applicable for an interface operation component (See Section
>>2.7.1.1 Composition Model). Therefore, it is not required to be
>>declared in a WSDL document, but MUST always be supported. 
>>
>>[Note: For sake of completeness, I propose that we identify
>>this feature with a URI although it will not exhibit itself in a WSDL
>>document]
>>
>>The OperationName Feature requires the operation name to be
>>identifiable in a message exchange and thus be conveyed between the
>>requestor agent and the provider agent. Since there may be multiple
>>mechanisms that may implement this abstract Feature, such as other
>>features, binding mechanisms (i.e.  a SOAP module) or existing
>>extensibility mechanisms this specification does not mandate a
>>specific implementation. However, one the following conditions must be
>>met to satisfy the OperationName feature:
>>
>>(1) an interface operation component must have a {style} property that
>>has the URI value http://www.w3.org/@@@@/@@/wsdl/style/rpc.
>>
>>(2) The messages of all interface operation components in a particular
>>direction for a specific interface component must be unique, i.e. they
>>must have distinct GEDs. 
>>
>>(3) WSDL document MUST contain a mandatory extension (see Section 8.3
>>Processor Conformance for the definition of a mandatory extension)
>>that satisfy and implement the OperationName feature. The mandatory
>>extension MUST be in use in a scope that contains interface operation
>>component (see Section 2.7.1.1 Composition Model)
>>
>>[Note: I believe that it is also possible to restrict the previous
>>definition to binding and binding operation scopes only. I can go
>>either way]
>>    
>>
>
>This is basically what I had in mind. Please see below for more
>comments on (3).
>
>Another way to express when the OperationName is available would be to
>say that the RPC style implements it, and that using unique GEDs is
>another implementation of this abstract feature.
>
>It would probably make sense at this point to define a unique GED
>style with a URI to clearly identify when interface operation
>components have distinct GEDs, and therefore make case (2)
>crystal-clear, just like (1) is.
>
That would be ok with me. In essence, we discussed such a beast during 
the time of HTTP binding, but it never materialized if my memory serves 
me right.

>
>  
>
>>This feature also defines an abstract property that holds the URI of
>>the name of the operation. The URI of the property is 
>>http://www.w3.org/TR/wsdl20/features/operationName/Name. 
>>
>>Since there are different ways to implement the abstract OperationName
>>feature as stated above, this specification requires a unique means of
>>identifying the operation name via the Property value. The value MUST
>>be the fragment identifier that signifies the specific operation
>>engaged and MUST be made available in an interaction. (See Section C.2
>>Fragment Identifiers)
>>    
>>
>
>This wasn't in my proposal as I hadn't considered this aspect, but it
>looks reasonable to me.
>
>* Jeffrey Schlimmer <jeffsch@windows.microsoft.com> [2004-07-07 14:30-0700]
>  
>
>>WSDL 2.0 should not require identifying the operation name because doing
>>so will unnecessarily limit the applicability of WSDL 2.0.
>>
>>R114 mandates that the WSD language define a way to uniquely map, but it
>>does not mandate that each WSDL document must uniquely map.
>>
>>The RPC style (http://www.w3.org/2004/03/wsdl/style/rpc) defines a way
>>to uniquely map and therefore satisfies R114. Nothing else is needed.
>>    
>>
>
>This was my original take on R114. However, not using something like
>the OperationName features when it is needed, i.e. when situation (1)
>and (2) do not apply, essentially means that some undocumented magic
>is used which will obviously impact interoperability.
>
+1.

>
>However, I think that there is one use case where the magic required
>may actually be documented in a standardized way: as a reference to
>the infamous GetStockQuote example, let's take the
>StartMonitoringStockQuote and StopMonitoringStockQuote operations,
>which look the same on the wire: 2 pieces of information are given, a
>subscriber identifier, and a symbol. Here is an example of such a
>message:
>
>  <monitoring>
>    <id>1123</id>
>    <symbol>ABCD</symbol>
>  </monitoring>
>
>The first message received for a particular id means that the
>subscriber wants to start monitoring the stock value for the specified
>symbol, and a subsequent, identical, message means that the subscriber
>wants to stop monitoring the stock value.
>
>Although this isn't a particularly well designed Web service, I
>believe this would work if there was a choreography description along
>with the WSDL description, in which case the operation name is known
>not on the wire, but some other way.
>
>I think that in such a case, the OperationName feature would not be
>required. So I would propose as a friendly amendment:
>- Change MUST into SHOULD in (3).
>- Add to (3): If the OperationName feature is not use, there MUST be
>  another way to identify which operation a message relates to; this
>  can be accomplished for example by using a choreography description
>  language.
>
The problem that I see with your friendly amendment is that there is no 
way to ensure the "MUST" from the perspective of the tools and/or the 
infamous WSDL processor. There is a good definition of mandatory 
extensions in our spec but this definition relies on some outof band 
mechanism. In general I don't prefer writing untestable requirements. I 
would expect a marker to indicate in WSDL to designate how OperationName 
feature is used so that a processor knows what to do.

>
>* Jonathan Marsh <jmarsh@microsoft.com> [2004-07-07 16:25-0700]
>[..]
>  
>
>>But I suppose we'd also want to define how SOAPaction fulfils the abstract feature, right?  Can you write down what the whole proposal is?  I'm having trouble distinguishing where you think this proposal differs from your original OperationName proposal [1].  I don't want to repeat that bit of contention.
>>    
>>
>
>Actually, I think that much of the contention was coming from defining
>a concrete implementation of how the operation name was appearing in
>the message, so I would think that defining how SOAPAction fulfills
>the abstract feature is something we would *not* want to do.
>
+1.

>
>Regards,
>
>Hugo
>
>  
>

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