W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

Re: WS-Addr issues

From: Tom Rutt <tom@coastin.com>
Date: Fri, 05 Nov 2004 00:24:48 -0500
Message-ID: <418B0EA0.7020107@coastin.com>
To: Mark Little <mark.little@arjuna.com>
CC: Sanjiva Weerawarana <sanjiva@watson.ibm.com>, public-ws-addressing@w3.org

I agree it seems superfluous, give soap:action  in http header, and the 
name of the child of soap:body also carrying the same information.

It is not only in the EPR, but is a  mandatory header element at run time.

Tom Rutt
Fujitsu

Mark Little wrote:

> 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 <http://www.arjuna.com>
>
>     ----- Original Message -----
>     *From:* Sanjiva Weerawarana <mailto:sanjiva@watson.ibm.com>
>     *To:* public-ws-addressing@w3.org
>     <mailto: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 <mailto:Steve.Vinoski@iona.com>
>         *To:* Doug Davis <mailto:dug@us.ibm.com>
>         *Cc:* public-ws-addressing@w3.org
>         <mailto: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
>             <mailto: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
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133
Received on Friday, 5 November 2004 06:23:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT