- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Thu, 04 Nov 2004 14:35:30 -0500
- To: David Orchard <dorchard@bea.com>
- Cc: Francisco Curbera <curbera@us.ibm.com>, public-ws-addressing@w3.org, Mark Little <mark.little@arjuna.com>
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 Thursday, 4 November 2004 19:35:38 UTC