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

Dear Dave,

> 
> 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.

Great!

Please allow me to understand better your assertions with regards to the
architecture-related benefits of wsa:action. Note that I am not
objecting, just trying to understand.

> 
> 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

If we assume that wsa:action may contain garbage, how is greater
visibility achieved? Also, what about the cases where the semantics of
the message are content-based?

> - simpler processing of the message by applications or intermediaries

I personally don't see why wsa:action enables these. Checking the value
of the wsa:action header isn't as simple as checking the qname of the
soap:Body child in order to infer semantics or any other
protocol-specific header as suggested in [1]? Since the semantics are
not reflected by the information header itself but rather by its value,
intermediaries are required to understand the header AND to know about
its possible values. 

> - simpler development of applications
> - simpler message creation

Why adding an extra header to carry semantics of the message make the
development/creation simpler? Isn't it the case that the more
assumptions we make about what all applications may need, the more
inflexible we make the architecture? 

> - more flexible deployment of services

This is true if wsa:action is not (ab)used as an RPC mechanism :-)

> - 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.
> 

I attempted to deal with the simplicity and visibility arguments when
wsa:action does not exist in [1] and [2].


<snip />

[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0239.ht
ml

[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0177.ht
ml

Best regards,
.savas.

Received on Monday, 8 November 2004 17:12:16 UTC