

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

From: Savas Parastatidis <Savas.Parastatidis@Newcastle.Ac.Uk>
Date: Mon, 8 Nov 2004 17:10:33 -0000
Message-ID: <37E80E80B681A24B8F768D607373CA800172CB04@largo.campus.ncl.ac.uk>
To: "David Orchard" <dorchard@bea.com>

Dear Dave,

> I think we are now at the point of diminishing returns of the
> 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.


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



Best regards,
Received on Monday, 8 November 2004 17:12:16 GMT
