- From: Francisco Curbera <curbera@us.ibm.com>
- Date: Sat, 6 Nov 2004 18:56:44 -0500
- To: "David Orchard" <dorchard@bea.com>
- Cc: "Mark Little" <mark.little@arjuna.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Just think about it: if we stuff WS-Addressing with lots of optional
fields, after we are done with it in w3c (if we ever are) we can take it to
WS-I and try to fix it by defining another interoperability profile - that
will keep us employed for a few more years. Not a bad business for those of
us making a living arguing about standards. :-)
Paco
"David Orchard"
<dorchard@bea.com> To: "Mark Little" <mark.little@arjuna.com>
Sent by: cc: <public-ws-addressing@w3.org>
public-ws-addressing-req Subject: RE: Mandator wsa:Action (was Re: WS-Addr issues)
uest@w3.org
11/06/2004 03:20 PM
This is another time somebody has misinterpreted what I've said and
implied something sinister or that I'm not listening. Please stop.
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.
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. I posit that a
WS-A Rec that has optional Action may be less interesting to the
community at large. 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've yet to hear the positive architectural properties that an optional
Action field induces in a system compared to a mandatory Action field.
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 Sunday, 7 November 2004 03:40:14 UTC