Re: "operation name" .. an alternate proposal

Hi Sanjiva,

I like this approach though it seems this essentially this amounts to 
fixing the value of SOAP Action at the WSDL spec level. Is that 
generally desirable or should that be left open?

I am also wondering if we are really trying to cover for stupid WSDL 
programming? If one uses the same element for inputs and outputs of the 
same or multiple operations it is simply bad programming. Hopefully they 
will be forced to fix things during the testing phase.

Having said that, I do think it is helpful to identify the operation and 
if it is input to the operation or output from etc. My preference would 
be towards a mechanism that captures this in the message itself  as a 
wrapper to the payload in body or at the header level (did we kill 
headers prematurely? :) as way to put the payload in proper context. 
Having it in the message makes the information available beyond the 
transfer level naturally, which is useful IMO.

Regards, Prasad

------- Original Message --------
Subject: 	"operation name" .. an alternate proposal
Resent-Date: 	Thu, 8 Jul 2004 10:27:06 -0400 (EDT)
Resent-From: 	www-ws-desc@w3.org
Date: 	Thu, 8 Jul 2004 20:26:29 +0600
From: 	Sanjiva Weerawarana <sanjiva@watson.ibm.com>
To: 	<www-ws-desc@w3.org>


As I understand it, the purpose of the "operation name" topic
we're discussing is to provide a mechanism for the service
to uniquely identify the operation that a message is targetted
at. This is necessary because we allow two operations in a
single interface to have the same input element:

    <interface>
        <operation name="o1">
            <input element="x:e1"/>
            <output ../>
        </operation>
        <operation name="o2">
            <input element="x:e1"/>
            <output ../>
        </operation>
    </interface>

The problem of course is that a message comes to the service
containing x:e1 and it doesn't know whether to do "o1" or "o2."

Now, as Paul (or was it Ugo?) pointed out recently, the exact
same problem can occur with the output messages of the service.
That is, there may be two operations o3 and o4 which respond
with the same element:

    <interface>
        <operation name="o3">
            <input .../>
            <output element="x:e1"/>
        </operation>
        <operation name="o4">
            <input ../>
            <output element="x:e1"/>
        </operation>
    </interface>
  
This is especially a problem in the case of asynchronous delivery, 
another topic we are discussing right now. In that case, there is
no implicit correlation as given by a synchronous transport and 
the receipt of x:e1 by the "client" will put the client a bit of 
a tough spot to figure out whether its a response to the o3 
invocation or the o4 invocation (as both may be pending).

While it is indeed possible to use message correlation to figure
out the relationship, it is not a very convenient or immediate
technique to solve this problem. Furthermore, I believe it gets
even messier for more complicated MEPs than simple in-out patterns.

What this leads to is the fact that in fact *each message* needs 
to indicate what is to be done with it. That is, the need to identify
the "operation" is misplaced - it needs to occur at each message 
level and not at the "operation" level in WSDL; which can capture
an arbitrary grouping of messages that are to be exchanged.

Finally, I get to my proposal. I suggest we add an attribute 
to each message reference and fault reference element to indicate
what is to be done with that message when its received:

    <operation name="xs:NCName">
        <input element="xs:QName" [action="xs:anyURI"]/>
        <output element="xs:QName" [action="xs:anyURI"]/>
        <(in|out)fault .. [action="xs:anyURI"]/>
    </operation>

Furthermore, I propose that we define a default way to compute these
as follows: 
    concatanate:
    - the target namespace of the interface that the operation
      is contained in,
    - the string "/",
    - the NCName of the operation, 
    - the string "/", and 
    - the string "input" for <input>, "output" for <output>,
      "in-fault" for <infault> and "out-fault" for <outfault>

This default rule is only defined for operations which use the MEPs
in-out or in-only. For others one can provide the action values
directly.

We can also consider providing a way to specify the action for 
faults in the fault definition component instead of the fault
reference component. In that case that value would be sent for
all uses of the fault. 

How does this get bound in the SOAP binding? If I were using 
WS-Addressing, I'd generate the <wsa:Action> headers using the
value of these action attributes. I assume WS-MD has a similar
feature, but I don't know the details enough to be sure. 

So, to avoid any political issues, I suggest we just map it to
good old "soapAction" in our binding. If someone else wants to
define additional rules for how to transmit those action values
they are free to do so using extensibility. 

I tried to use a word other than "action" in this proposal .. but
I wasn't able to come up with something that seemed natural. I'm
totally open to renaming the attribute to avoid making it look
like an attempt to support WS-Addressing .. its not. I thought
of "subject" (along the lines of the Subject: header in email)
but wasn't sure whether that would cause confusion.

Sanjiva.