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

Dave, in conclusion I'll just reiterate that I understand and respect your
arguments. I just don't agree with them (as you rightly assumed). I doubt I
can change your argument and vice versa. So I'm happy to leave it at that
and vote later.

Mark.

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

www.arjuna.com

----- Original Message -----
From: "David Orchard" <dorchard@bea.com>
To: "Mark Little" <mark.little@arjuna.com>
Cc: <public-ws-addressing@w3.org>
Sent: Monday, November 08, 2004 4:00 PM
Subject: RE: Mandator wsa:Action (was Re: WS-Addr issues)


> I think we are now at the point of diminishing returns of the argument.
>
> As I understand your position, the reasons against a mandatory action
> are:
> - not all applications need it so it's extra/useless
> - there will be garbage content when applications don't need it
> - it may be redundant and any redundant data is bad practice in any
> systems design.
>
> I've already admitted to these points being valid.
>
> My argument is that even with these negatives, I think in the large
> majority of cases, a mandatory Action is useful because it fundamentally
> enables self-describing messages.  This enables:
> - greater visibility into the message
> - simpler processing of the message by applications or intermediaries
> - simpler development of applications
> - simpler message creation
> - more flexible deployment of services
> - higher performant
>
> I'm using the architecture properties of interest as listed in REST for
> my comparison.  It would be helpful if we could adopt common
> terminology, such as application performance, network performance,
> visibility into messages, simplicity, etc.
>
> My guess is that you understand my arguments and remain staunch in
> disagreement :-).
>
> I'll provide some more history/justification below.
>
> I think the same arguments hold true for why HTTP has an operation.
> GET/PUT/DELETE are nice and well defined, but POST is this big juicy
> extensibility point.  And people regularly (almost invariably) build
> non-RESTful systems using POST.  An argument could be made that the HTTP
> operation should be left as optional in some of the POST cases where
> there is no "operation".  Or the operation is redundant - did you know
> that Atom uses a form of POST that wraps the body in the operation?  But
> the development of HTTP software was made significantly better by
> mandating an operation even in the face of garbage operation values.
>
> There's another lesson to be learned from HTTP wrt media-type.  In the
> case of the optional media type, the spec provides rules for how to
> generate the media-type from the content as well as a default value.
>
> I'll say again that I would have *loved it* if the SOAP 1.2 WG had
> defined a binding for SOAP to HTTP that enabled a SOAP infoset to be
> serialized using HTTP as a transfer protocol, and I had proposed such a
> thing.  Then WSA could say that an HTTP verb became the WSA:Action value
> and I could live with WSA:Action being optional as a header block *on
> the wire* but required *in the infoset*.  But we don't have that world.
> In the infoset means as a header block given the SOAP HTTP binding we
> have.  And I can't see us being able to create another binding in the
> WS-A group.  Maybe we could beg the XMLP group to figure this out, but I
> can't see that either.
>
> I just can't figure out how we can provide a way to create a WSA:Action
> infoset item from message content or bindings that fits in the standards
> environment we live in, so I'm forced to strongly advocate that
> WSA:Action is mandatory.
>
> Cheers,
> Dave
>
> <snip/>
>
> > >
> > > 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.
> >
> <snip/>
>
> >
> > > 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.
>

Received on Monday, 8 November 2004 16:08:08 UTC