Re: Mandator wsa:Action (was Re: WS-Addr issues)

About wsa:Action but not related to this MIH being mandatory:

One of the uses of wsa:Action that I have seen is when two wsdl 
operations (of the same portType/interface) have the same QName for the 
1st child of the SOAP body. In such a case it makes it hard for the 
service to disambiguate the wsdl operation based on the content of the 
SOAP Body.

The way WS-I resolved this was by disallowing such operations in WS-I 
compliant portTypes. But, WSDL 2.0 does not disallows this.

WS-A spec does not require that the wsa:Action be unique -- which means 
one may not be able to use wsa:Action for such disambiguation. Although, 
the default wsa:Action rules do result in a unique value for the 
wsa:Action. Should we require wsa:Action attribute value to unique 
within the portType/interface?

Comments?

-Anish
-- 

Francisco Curbera wrote:

> I think the issue is not whether you invoke a method or not (who cares what
> happens under the cover?) but the fact that when you don't provide a clear
> mechanism for indicating message intent you end up with many more than you
> wish you had. I think that we would do a disservice to the WS community if
> we didn't take this chance to sort out this mess once for all.
> 
> Paco
> 
> 
> 
> 
>                                                                                                                                         
>                       Marc Hadley                                                                                                       
>                       <Marc.Hadley@Sun.        To:       David Orchard <dorchard@bea.com>                                               
>                       COM>                     cc:       Francisco Curbera/Watson/IBM@IBMUS, public-ws-addressing@w3.org, Mark Little   
>                       Sent by:                  <mark.little@arjuna.com>                                                                
>                       Marc.Hadley@Sun.C        Subject:  Re: Mandator wsa:Action (was Re: WS-Addr issues)                               
>                       OM                                                                                                                
>                                                                                                                                         
>                                                                                                                                         
>                       11/04/2004 02:35                                                                                                  
>                       PM                                                                                                                
>                                                                                                                                         
> 
> 
> 
> 
> On Nov 4, 2004, at 12:33 PM, David Orchard wrote:
> 
>>The real problem is the same problem we had with the optional soap 1.1
>>action http header.  Software can't count on it being there, so they
>>end
>>up looking inside the body as "the one true and certified source of
>>action" which effectively pushed everybody into RPC land.
> 
> 
> I think the association between looking at the payload of a message and
> RPC is false. One could just as easily argue that requiring an action
> is *more* RPC-like where action==method and message payload==method
> parameters.
> 
> RPC is in the eye of the beholder, its not defined by the presence or
> lack of an action.
> 
> Marc.
> 
> 
>>  This happened
>>because all the toolkits had to support at least looking in the body
>>and
>>then not all did the look at action and thus the world was a worse
>>place.
>>
>>I predict that an optional WSA:Action will have the same effect IF
>>there
>>is no mandatory/normative way of generating a WSA:Action infset
>>property
>>from any binding that hasn't serialized the WSA:Action as a soap header
>>block.
>>
>>I don't want to live in the message bodies always contain the verb
>>world
>>any more.
>>
>>Dave
>>
>>
>>>-----Original Message-----
>>>From: Mark Little [mailto:mark.little@arjuna.com]
>>>Sent: Thursday, November 04, 2004 9:24 AM
>>>To: David Orchard; Francisco Curbera
>>>Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
>>>Subject: Mandator wsa:Action (was Re: WS-Addr issues)
>>>
>>>David, I changed the subject line - you're right in that regard.
>>>
>>>As for keeping wsa:Action mandatory, I think you're wrong ;-)
>>>
>>>What is the real problem with making this optional? What would break
>>
>>as a
>>
>>>result?
>>>
>>>Mark.
>>>
>>>----
>>>Mark Little,
>>>Chief Architect,
>>>Arjuna Technologies Ltd.
>>>
>>>www.arjuna.com
>>>
>>>----- Original Message -----
>>>From: "David Orchard" <dorchard@bea.com>
>>>To: "Francisco Curbera" <curbera@us.ibm.com>; "Mark Little"
>>><mark.little@arjuna.com>
>>>Cc: <public-ws-addressing@w3.org>;
>>
>><public-ws-addressing-request@w3.org>
>>
>>>Sent: Thursday, November 04, 2004 4:40 PM
>>>Subject: RE: WS-Addr issues
>>>
>>>
>>>
>>>>+1.
>>>>
>>>>Arguing against action is like arguing against HTTP operations.
>>
>>Having
>>
>>>>one spot for Action will give all WS-A applications a much simpler
>>>>processing model and enable a doc/literal world.
>>>>
>>>>Separately, can we pick better subject lines and focus the
>>
>>conversation
>>
>>>>a bit?  I think this thread is on mandatory Action.  I expect we are
>>>>going to debate every single component's mandatory/optional nature
>>
>>and
>>
>>>>separating them would help a lot.
>>>>
>>>>Dave
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: public-ws-addressing-request@w3.org
>>>>
>>>>[mailto:public-ws-addressing-
>>>>
>>>>>request@w3.org] On Behalf Of Francisco Curbera
>>>>>Sent: Thursday, November 04, 2004 6:26 AM
>>>>>To: Mark Little
>>>>>Cc: public-ws-addressing@w3.org;
>>
>>public-ws-addressing-request@w3.org
>>
>>>>>Subject: Re: WS-Addr issues
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>The idea that the intent of the message is *always* embedded in
>>
>>the
>>
>>>>body
>>>>
>>>>>of
>>>>>the message smells like SOAP-RPC in sheep clothes to me. I am not
>>>>
>>>>saying
>>>>
>>>>>that will never be the case, but you need to allow for the case in
>>>>
>>>>which
>>>>
>>>>>the same document type is used in different interactions - for
>>>>
>>>>example, a
>>>>
>>>>>customerInfo document could be sent as input to both an "update"
>>
>>and a
>>
>>>>>"create" operations.This "document centric" model is actually very
>>>>>frequent
>>>>>(it is no uncommon in CICS applications for example). To support
>>
>>this
>>
>>>>>model
>>>>>you need either an Action header or something functionally
>>
>>equivalent.
>>
>>>>>Paco
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                      "Mark Little"
>>>>>                      <mark.little@arjuna.com>        To:
>>>>
>>>>"Sanjiva
>>>>
>>>>>Weerawarana" <sanjiva@watson.ibm.com>,
>>
>><public-ws-addressing@w3.org>
>>
>>>>>                      Sent by:                        cc:
>>>>>                      public-ws-addressing-req        Subject:
>>
>>Re:
>>
>>>>WS-
>>>>
>>>>>Addr issues
>>>>>                      uest@w3.org
>>>>>
>>>>>
>>>>>                      11/04/2004 05:05 AM
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Hi Sanjiva. Although not an answer to your question, I think it's
>>>>
>>>>worth
>>>>
>>>>>bringing up generally: personally I think wsa:Action should be
>>
>>dropped
>>
>>>>or
>>>>
>>>>>made optional. Why have an "op code" (which is essentially what it
>>
>>is)
>>
>>>>>embedded in an address? I can see that there are optimizations
>>
>>that
>>
>>>>could
>>>>
>>>>>be made to dispatching directly on the Action rather than having
>>
>>to
>>
>>>>parse
>>>>
>>>>>the body, but surely that's an implementation specific issue? I'd
>>
>>be
>>
>>>>>interested in knowing how many users of WS-Addressing actually use
>>>>
>>>>this
>>>>
>>>>>versus those that ignore it.
>>>>>
>>>>>Mark.
>>>>>
>>>>>----
>>>>>Mark Little,
>>>>>Chief Architect,
>>>>>Arjuna Technologies Ltd.
>>>>>
>>>>>www.arjuna.com
>>>>>----- Original Message -----
>>>>>From: Sanjiva Weerawarana
>>>>>To: public-ws-addressing@w3.org
>>>>>Sent: Wednesday, November 03, 2004 7:42 PM
>>>>>Subject: Re: WS-Addr issues
>>>>>
>>>>>Hi Steve,
>>>>>
>>>>>What's your view of dispatching with wsa:Action? Since those are
>>>>
>>>>required
>>>>
>>>>>to be unique that gives enough info to find the operation to
>>
>>dispatch
>>
>>>>>to within a service. The service itself is of course identified
>>
>>from
>>
>>>>>the <To> somehow.
>>>>>
>>>>>Sanjiva.
>>>>> ----- Original Message -----
>>>>> From: Vinoski, Stephen
>>>>> To: Doug Davis
>>>>> Cc: public-ws-addressing@w3.org
>>>>> Sent: Thursday, November 04, 2004 12:58 AM
>>>>> Subject: RE: WS-Addr issues
>>>>>
>>>>> +1 to having a pointer to the WSDL itself in the EPR. We have
>>
>>found
>>
>>>>in
>>>>
>>>>> working with our customers that having access to the service
>>>>
>>>>definition
>>>>
>>>>>is
>>>>> critical for applications that rely on pure dynamic dispatching.
>>>>>
>>>>> --steve
>>>>>       -----Original Message-----
>>>>>       From: Doug Davis [mailto:dug@us.ibm.com]
>>>>>       Sent: Wednesday, November 03, 2004 11:02 AM
>>>>>       To: public-ws-addressing@w3.org
>>>>>       Subject: WS-Addr issues
>>>>>
>>>>>
>>>>>       I might have missed a formal request for "issues" from the
>>>>
>>>>public
>>>>
>>>>>       but since it appears there is now an issues list I thought
>>
>>I'd
>>
>>>>make
>>>>
>>>>>       some suggestions on possible issues for the WG's
>>
>>consideration:
>>
>>>>>       issue: EPRs have WSDL bits - e.g. PortType, ServiceName.
>>
>>But
>>
>>>>no
>>>>
>>>>>       pointer to the actual WSDL itself - why not?  W/o the WSDL
>>
>>do
>>
>>>>these
>>>>
>>>>>       values mean anything?  And if we assume the consumer of the
>>
>>EPR
>>
>>>>has
>>>>
>>>>>       the WSDL why can't we assume they know the PortType and
>>>>>ServiceName?
>>>>>       Perhaps an example of how this would be used would clarify
>>
>>it
>>
>>>>for
>>>>
>>>>>       me.
>>>>>
>>>>>       issue: If a response message is expected then a wsa:ReplyTo
>>>>
>>>>MUST be
>>>>
>>>>>       included.  Does the absence of a wsa:ReplyTo imply a
>>
>>one-way
>>
>>>>>       message?  The spec seems to come very close to saying that.
>>>>
>>>>And
>>>>
>>>>>       does the presence of wsa:ReplyTo imply a two-way message?
>>
>>My
>>
>>>>>       preference would be to have a clear statement so that upon
>>>>>       inspection of the message itself a processor can know if
>>
>>its a
>>
>>>>>       one-way or two-way w/o having to go back to the wsdl.
>>>>>
>>>>>       issue: wsa:FaultTo:  "This property may be absent if the
>>
>>sender
>>
>>>>>       cannot receive fault messages (e.g. is a one-way
>>
>>application
>>
>>>>>       message)."  But it also says that in the absence of
>>
>>wsa:FaultTo
>>
>>>>the
>>>>
>>>>>       wsa:ReplyTo/From may be used.  So, how does a client really
>>
>>say
>>
>>>>>that
>>>>>       it doesn't want ANY fault messages at all but still be
>>
>>allowed
>>
>>>>to
>>>>
>>>>>       specify a wsa:From?
>>>>>
>>>>>       thanks
>>>>>       -Doug
>>>>>
>>>>
>>>>
>>
>>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
> 
> 
> 
> 

Received on Friday, 5 November 2004 01:05:29 UTC