- From: Mark Little <mark.little@arjuna.com>
- Date: Fri, 5 Nov 2004 16:06:33 +0000
- To: Marc Hadley <Marc.Hadley@Sun.COM>
- Cc: Francisco Curbera <curbera@us.ibm.com>, David Orchard <dorchard@bea.com>, public-ws-addressing@w3.org
+1 I have yet to see anyone arguing for wsa:Action showing how it is fundamentally required for the architecture. What I'm looking for is a reason why it is simply impossible to build *any* Web Services applications without it. I (and I'm sure others) can point at a plethora of examples to the contrary. Mark. On 5 Nov 2004, at 15:46, Marc Hadley wrote: > > On Nov 4, 2004, at 4:52 PM, David Orchard wrote: >> >> So you are arguing that action may or may not be RPC. > > I'm arguing that the presence of action is orthogonal to the > programming model. One can build an RPC-like mechanism based on > dispatching on action or on the message payload. Similarly one can > build a message oriented mechanism on either. The presence or lack of > action doesn't mandate a particular programming model. > >> Without going >> further on that (which I could but we've got an overload of messages >> already), my point was that people ended up always looking into the >> message to determine the "action" under the optional soap 1.1 action >> header. A mandatory WSA:Action breaks that cycle and an optional >> Action >> perpetuates it. >> > I'm OK with a particular service requiring the presence of an action. > I'm not OK with requiring every message to carry one even when the > service they are destined for doesn't use it. This is where we ended > up in the XMLP WG and I think its a good compromise position. > > Marc. > >> >>> -----Original Message----- >>> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM] >>> Sent: Thursday, November 04, 2004 11:36 AM >>> To: David Orchard >>> Cc: Francisco Curbera; public-ws-addressing@w3.org; Mark Little >>> Subject: Re: Mandator wsa:Action (was Re: WS-Addr issues) >>> >>> 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. >> >> > --- > Marc Hadley <marc.hadley at sun.com> > Web Technologies and Standards, Sun Microsystems. > >
Received on Friday, 5 November 2004 16:17:39 UTC