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:01:00 UTC