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

Mark,

I think you misunderstand me.  I'm not saying design architectures
around bad toolkits.  I am saying architecture will guide component
design.  that I'm saying by making something like Action optional, there
is a natural and predictable way that people will build toolkits. 

For example, the Web is based upon self-describing messages.  They are
self-describing because the media-type of the representation is included
the message.  This enables software to correctly dispatch n different
representation types that are retrieved as part of a given
operaion/action.  You could argue that the media-type should have been
optional for something like jpeg/gif and that any XML content type could
be determined by looking at the body.  Oh, but wait, there may be some
xml vocabularies, like XSLT and XENC, that can be embedded in others.
They are the media type but they allow an "embedded" mode where they
aren't the doc root.  So the "body" child isn't it.  By enforcing
mandatory media-type, a whole bunch of web arch problems where
prevented.

As for the meaning of addressing, which is what I think you are tilting
at, I think Action is about how a resource is addressed as much as a
URI.  There is a big distinction between our informal and not written
down definition of what "addressing" is and a formal definition of an
identifier like URIs.  In my world of what "addressing" means, the
Action of a message will disambiguate between 2 equal message body
contents, the point that Paco made ealier and I +1ed.

I'd rather not get into the age old computing discussion about whether
opcodes are data or not.  Please, let's not go there. 

Dave

> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com]
> Sent: Thursday, November 04, 2004 9:39 AM
> To: David Orchard; Francisco Curbera
> Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> Subject: 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.
> 
> That's a problem with the toolkits though. If wsa:Action is there, use
it.
> If it isn't, look in the body. To say that you always look in the body
> because of poor toolkits is the wrong reason to forge an architecture.
If
> that were the main rule for anything, we'd still be working with
TCP/IP
> and
> sendmsg/recvmsg.
> 
> > 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.
> 
> I understand. My preference would to be remove this from WS-Addr
entirely
> and put this into another spec. If we can't do that (because for some
> reason
> people really believe this is something to do with addressing), then
let's
> make it optional and assume that vendors can provide toolkits that
work :-
> )
> 
> Mark.
> 
> >
> > 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:56:34 UTC