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

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

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

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.

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

Regards,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/