Re: "operation name" .. an alternate proposal

+1

Sanjiva Weerawarana wrote:

>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:44:15 UTC