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

Marc, thanks, that is very useful.

Some thoughts in reply:

0. I conclude that the only thing that makes a message a "reply in the 
MEP sense" or a "reply in the WS-A sense" is a statement in the 
application contract saying: "we're using WS-A Section 3.4 rules." 
Absent that statement, you can use the [reply endpoint] property any way 
you want (and presumably, the [message id] property any way you want).

I confess I don't especially like that kind of approach -- I'd prefer 
that WS-A said: these standard properties are reserved for standard 
behaviours defined in this spec; you can omit them if you don't want to 
use those standard behaviours, but define extensions if you want to do 
special things, and keep your hands off the standard properties. But I 
understand that's not what the spec demands, and that it is very 
well-baked at this point.

1. The need for the "whimsical" EPR selection is real. I was trying to 
distil the essence without getting into WS-TX detail. It's one of the 
reasons why the standard reply formulation rules in 3.4 are not 
appropriate: we need a special behaviour. The cached, a priori EPR can 
be forgotten in a recovery scenario where B is resurrected, receives a 
message from A, but doesn't remember A.E and therefore needs to use A.E'.

2.  It's not clear in our context that the message id is adding 
anything, because it not used for correlation of responses thereafter. 
(When I say "response" I mean a logically-related message that isn't a 
"reply" in the section 3.4 sense). There is no need for correlation 
because duplicates are expected (are a by-product of delays and 
recovery) and are handled by the WS-TX state machines, each instance of 
which lies behind a unique target EPR.

3. As I read WS-Addressing, if you do not say reply-to=none, and omit 
reply-to, then the receiver must infer that reply-to=anon. Am I right? 
So reply-to=anon leads (in SOAP/HTTP) to the HTTP response having a 
status code of 202, and an empty entity body; whereas reply-to=none 
leads to empty entity body and status code of 200 (the practical effect 
of discarding the reply with that binding)?

Pursuing that: if I want to be really clean-living then saying 
reply-to=none causes the wire effects you would intuitively expect when 
you say "one way message", and you don't wind up the receiver 
implementation to receive an app reply that is never going to come (or 
to be more precise is always going to be null and immediate). This is 
not a completely trivial matter: an implementation infers it's an 
anonymous reply, gets ready to send back a reply on the underlying 
response of the transport, e.g. the HTTP response. It presumably creates 
a handle or reference, that is handed off to the receiving application, 
and the HTTP response is delayed. If the handle is never used, the 
response never goes back. That could create a double-ended garbage 
problem. To avoid this the receiving application has to immediately 
present the handle back to the implementation as an argument to some 
reply method, along with null reply contents.

Hence my thought: if you mean "one-way" (whack back a 200 response in 
HTTP terms), then say reply-to=none. That way the receiving 
implementation won't trouble the app.

4. I personally like the idea of a bespoke EPR property, because our 
rules and needs are special, and I don't like using a property that in 
almost every other circumstance is likely to be associated with the 
general rules of 3.4.

Alastair


Marc Hadley wrote:
> 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.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
>
>

Received on Wednesday, 15 March 2006 11:29:46 UTC