- From: Mark Little <mark.little@arjuna.com>
- Date: Fri, 5 Nov 2004 08:09:45 +0000
- To: tom@coastin.com
- Cc: Sanjiva Weerawarana <sanjiva@watson.ibm.com>, public-ws-addressing@w3.org
+1 On 5 Nov 2004, at 05:24, Tom Rutt wrote: > > 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 08:11:15 UTC