- From: Tom Rutt <tom@coastin.com>
- Date: Fri, 05 Nov 2004 00:24:48 -0500
- 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 UTC