"operation name" .. an alternate proposal

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.

Received on Thursday, 8 July 2004 10:27:04 UTC