Re: [ws-rx] Anon / RM MakeConnection: [reply ep] = none

Alastair Green <>
wrote on 08/09/2006 05:33:12 AM:

> Paul,

> 

> I don't think that the behaviour I describe (where RM knowledge 

> intrudes into a WS-Addressing implementation of a core WS-Addressing

> feature) is acceptable. This is a composition/layering problem.

> 

> WS-A impl must now apply special rules (as I have described) if it

> encounters a message with [reply ep] = none which happens to be a

> WS-RM message called MakeConnection. Do you agree with that statement?

Per the WSA spec, 'none' is defined as:

---

Messages sent to EPRs whose [address] is this value
MUST be discarded 

(i.e. not sent). This URI is typically used in EPRs
that designate a reply 

or fault endpoint (see section 3.1 Abstract Property
Definitions) to 

indicate that no reply or fault message should be
sent.

---

So, let's assume the MC has a replyTo set to none.

I hope we agree that any messages targeted to that
EPR should be 

discarded - per the above text from WSA. So, the question
is, what

messages are targeted to that EPR?  From the
MC perspective _none_.

Since MC is a one-way there is no defined response.
At this point

the receiver of the MC is then free to do one of two
things:

1 - return a 202, or

2 - reuse the http response flow to send a message

Step 2 is no different, as Paul said in a previous
note, from how

RM already allows for Acks to be sent back in cases
where normally

an HTTP 202 would be sent.

Alastair - you need to understand that MC does not
generate a 

response.  You may not like it, but that is how
it is defined.

> If so, how would you go about creating a freestanding WS-A Core 

> implementation that is RM-unaware?

> 

> WS-TX decided to make all one-ways have [reply ep] = none, to make

> clear that its notification messages are indeed "one way".
I don't 

> see any problem with that. 

> 

> However, these MakeConnection messages are not the same. They 

> induce, in the broad, the back channel behaviour created by use of

> anon. But they are subtly different, in that the response may just

> be an ack. There is no well-known URI to represent that behaviour,

> at present (or at least, the RM one is not being used).

> 

> At best, this is an RM extension to WS-Addressing, and it should 

> layer cleanly on the WS-Addressing core behaviour.

> 

> Alastair