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

> This is another time somebody has misinterpreted what I've said and
> implied something sinister or that I'm not listening.  Please stop.

Dave, apologies if you didn't mean something sinister, but it was fairly
easy to read that in what you said. I'll try to turn paranoia-mode off for
now.

> If you notice, in my discussion, I frame my arguments in terms of
> counter-arguments.  I present actual and even imagined opposing views in
> a reasoned light.  I believe one of the best ways to get to consensus is
> to understand the other side's POV and be able to express it back to
> them in a manner that they agree represents their POV.

I'd hope that the emails I've sent back are reasonable too. In no email have
I said that you are simply wrong to have wsa:Action in the spec., for
example: only that in my experience it is wrong the make it mandatory. I
think others have said the same too, but I won't put words in their mouths.

>
> Now enough on style, back to substance.
>
> I'm certainly not talking about changing from WS-A submission to WS-A
> Rec problems.
>
> I am talking about everybody that implements a WS-A Rec having the
> certainty of an Action field and the benefits from that.

But the problem is that the certainty of the field means nothing if it isn't
used correctly, and from my experience there are applications and
specifications that simply don't need it. Hence it is wrong to impose it on
them, especially in situations where it simply is not possible to associate
anything meaningful with the field. If we make it optional then
implementations/specifications that need it will use it and use it
correctly; the recipient of a wsa:Action can then use it with a level of
certainty that isn't present today. Its lack in a message conveys
information to the receiver as well.

> I posit that a
> WS-A Rec that has optional Action may be less interesting to the
> community at large.

I understand that, and I also understand that your supposition is based on
your experiences. However, my (and others) experiences tell me differently.
Now I'd hope that we could come to a mutual understanding and propose a
solution that helps satisfy us both.

> I assert and evidence has shown that mandatory
> items accrue benefits compared to optional items.  I still have the
> scars from various WGs of optional items :-(

I'd agree if those mandatory items had universal applicability. I don't
believe this one does.

> I've yet to hear the positive architectural properties that an optional
> Action field induces in a system compared to a mandatory Action field.

See above and several emails I've sent and (I think) Savas.

Mark.

----
Mark Little,
Chief Architect,
Arjuna Technologies Ltd.

www.arjuna.com

>
> Dave
>
> > -----Original Message-----
> > From: Mark Little [mailto:mark.little@arjuna.com]
> > Sent: Saturday, November 06, 2004 12:50 AM
> > To: David Orchard
> > Cc: public-ws-addressing@w3.org
> > Subject: Re: Mandator wsa:Action (was Re: WS-Addr issues)
> >
> >
> >
> > > I can imagine more thoughts like "My point is still made!  The site
> has
> > > the choice of making it mandatory or not, an optional Action that a
> > > service requires is the same thing".
> > >
> > > But this is where the analogy breaks down.  The vendors at the table
> > > build SOAP processing software and standardization of SOAP
> constructs
> > > facilitates interop.  We are not building standardized data entry
> > > languages - though UBL exists in a separate forum.  If we can
> > > standardize WSA:Action, we can accrue benfits to all software that
> > > leverages WSA:Action.
> >
> > Hmmm, I don't think this is an objective statement. What you're saying
> > is that the vendors who have implemented products against a
> proprietary
> > specification (as it was then) would suffer if this changed. However,
> > those vendors who haven't used WS-Addr, have implemented their own, or
> > have used something like WS-MD, shouldn't be listened to? I hope not.
> > If it is the case, then come clean now. I, and I'm sure others, aren't
> > in this to rubberstamp something.
> >
> > I want a WS-Addressing standard as quickly as possible for a number of
> > reasons: product related as well as other standard/specification
> > related. So it's not in my interest to see this drag on and on.
> > However, what those vendors who weren't involved in the original
> closed
> > and proprietary specification development do have, is experience that
> > perhaps the other vendors don't have. I hope that you and others would
> > treat that with the same level of respect as you would give to each
> > other - on it's merits, rather than on who the individual(s) work for.
> >
> > >
> > > By retaining the status quo of Mandatory Action, all WS-A processors
> > > have certainty about it's presence.
> > >
> > > Certainty has often led to accrued benefits.  An example that I love
> is
> > > the certainty of the Java Class libraries was a key reason that
> people
> > > switched from various flavours of Unix C++ to Java.
> > >
> > > There's also an old standards saw, which is that there should be as
> few
> > > optional components as possible.  There's a reason why that saw
> exists,
> > > to minimize interop problems.
> >
> > There's also the old proverb about the Emperor's New Clothes.
> >
> > Mark.
> >
> > >
> > > Cheers,
> > > Dave
> > >
> > >> -----Original Message-----
> > >> From: Mark Little [mailto:mark.little@arjuna.com]
> > >> Sent: Friday, November 05, 2004 12:36 AM
> > >> To: David Orchard
> > >> Cc: Francisco Curbera; public-ws-addressing-request@w3.org;
> public-ws-
> > >> addressing@w3.org
> > >> Subject: Re: Mandator wsa:Action (was Re: WS-Addr issues)
> > >>
> > >> David, apologies for the delay in replying and I see that the
> > >> discussion has moved on since last night (my time). Nevertheless
> I'll
> > >> respond inline.
> > >>
> > >> On 4 Nov 2004, at 17:56, David Orchard wrote:
> > >>
> > >>> 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.
> > >>
> > >> Understood. However, there are a couple of points I need to make:
> > >>
> > >> (i) the financial saying of "past performance is no indicator of
> > >> current or future performance" comes into play. Just because you've
> > >> seen this happen before doesn't mean it will happen again. If there
> > >> really is a need for this in some applications, then people will
> use
> > >> it.
> > >>
> > >> (ii) building on (i), as I've said before, I've seen quite a few
> > >> implementations that just see wsa:Action as baggage they have to
> fill
> > >> in but don't use. I think we should be looking to make mandatory
> only
> > >> those elements that are used in every situation. If you can show me
> > >> that that is the case for wsa:Action then I'd be interested. This
> > > model
> > >> of mandatory elements only for global requirements works for other
> > >> specifications, so I don't see why it won't work for us.
> > >>
> > >>>
> > >>> 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.
> > >>
> > >> I don't see this as the same thing at all. Firstly, MIME types can
> be
> > >> strongly argued as required on all interactions. Secondly, this
> isn't
> > >> addressing, it's dispatch. I think it's simply the wrong place in
> the
> > >> architecture to put this (if it needs defining at all).
> > >>
> > >>>
> > >>> 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.
> > >>
> > >> We'll have to disagree then about what is and isn't addressing in
> this
> > >> case. However, I think if you look at other distributed
> architectures
> > >> over the past 30 years you'll be in the minority ;-)
> > >>
> > >>>
> > >>> I'd rather not get into the age old computing discussion about
> > > whether
> > >>> opcodes are data or not.  Please, let's not go there.
> > >>
> > >> Agreed.
> > >>
> > >> Mark.
> > >>
> > >>>
> > >>> 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 Monday, 8 November 2004 10:44:30 UTC