W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2006

Re: Use or abuse of [reply endpoint] property?

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Tue, 14 Mar 2006 14:14:31 -0500
To: Alastair Green <alastair.green@choreology.com>
Cc: public-ws-addressing@w3.org, ws-tx@lists.oasis-open.org
Message-id: <CA0992B2-28CC-46F1-8C3A-A7EDA9070E7D@Sun.COM>
My 2c inline.

On Mar 14, 2006, at 4:57 AM, Alastair Green wrote:
> A question (cluster of questions) has arisen in the OASIS WS-TX TC  
> re use of WS-Addressing.
> App A sends message "a" to app B, who may send "b" to A at a later  
> time, in an exchange where "a" and "b" are logically related (form  
> part of an exchange or conversation) at an application level.
> A possesses, a priori, an EPR for B (B.E) and likewise B possesses  
> an A.E, and these can be used to target the messages "a" and "b".
> Message "a" contains a non-anon, non-none value for [reply  
> endpoint] [address], A.E'.
> B chooses to ignore that value and sends "b", not to the new  
> potential target A.E' but to A.E. The A-B application-level  
> contract defines "b" not to be a "reply" to "a", but merely a one- 
> way message that is, if you like, in apposition to "a".
> B can also choose (at its whim, in any given execution of this  
> exchange) to send "b" to A.E', and not the old target A.E.
> Q.0. Is this a legitimate use of the [reply endpoint] of "a"?  
> Spiritually? Legally?
 From a WS-Addr perspective it looks OK since you state that message  
b isn't a reply (in the MEP sense) to message a. However it seems odd  
for WS-TX to promote the kind of non-deterministic behaviour wrt the  
destination for b (A.E or A.E' at the discretion of B). One might  
expect WS-TX to lock things down to one or the other unless there's a  
good reason to leave it open ?

> Related questions:
> Q.1. Must message "a", having a [reply endpoint] value, therefore  
> set a [message id] value, or can this latter property be omitted in  
> the representation?
I think it would be OK to omit a [message id] from the WS-A  
perspective but it seems like good practice to include one. This  
seems like something that WS-TX should define.

> Q.2. Closely related to Q.1. Can B ignore this message id even if  
> it is present, and refuse to express (omit) the [relationship] of  
> its message "b" to the original "a" message, in the case where it  
> chooses to target "b" on new reply target A.E'?
Given that message b isn't a reply in the WS-A sense I think that  
would be OK. However, WS-TX could require that the WS-A semantics are  
followed and that would IMO be preferable to WS-TX inventing its own  
correlation mechanism.

> Q.3. If message "a" desires no reply, should message A set [reply  
> endpoint] [address] to the "none" URI? Is the "none" value for this  
> property the effective definition of a "one way message" (one that  
> gives no indication of expected future interchanges)? Is the "none"  
> value the only circumstance in which the [message id] can be omitted?
The "none" addr is (IMO) equivalent to redirecting stdout to /dev/ 
null in Unix type OSs.

> Q.4. Closely related to Q.3. If the [reply endpoint] is instead  
> omitted in "a" and the property is therefore inferred on receipt by  
> B to be anonymous, what should B send in the underlying transport  
> response if it wishes to send no reply at an application level?
Whatever the underlying SOAP protocol binding says to do when there's  
no SOAP message. In SOAP/HTTP you'd send back a 202 status code with  
an empty entity body.

To answer these questions on a more general level I'd say its the job  
of WS-TX (and other protocols) to define how WS-Addr properties are  
used in the longer running exchanges/conversation defined by WS-TX.  
WS-Addr provides some useful building blocks for these kinds of  
exchanges but doesn't lock down their exact semantics when used this  
way. I'd also note that if WS-TX needs an EPR but [reply endpoint]  
doesn't quite fit the bill then its entirely OK to define a new EPR  
typed property that does.


Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.

Received on Tuesday, 14 March 2006 19:14:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:13 UTC