RE: Mandator wsa:Action (was Re: WS-Addr issues)

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

Received on Thursday, 4 November 2004 17:33:41 UTC