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
> >
>
>

Received on Thursday, 4 November 2004 17:23:24 UTC