RE: [ws-rx] PR issue 1 - WS-Addressing comment on ws-rm related touse of extended anonymous uri

[Marc Goodner <mgoodner@microsoft.com>]

Please also explain if you are talking about the SequenceID or RM anon URI variant of MakeConenction.

-----Original Message-----
From: Paul Fremantle [mailto:paul@wso2.com]
Sent: Wednesday, September 27, 2006 8:46 AM
To: Alastair Green
Cc: Marc Goodner; Gilbert Pilz; Doug Davis; ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] PR issue 1 - WS-Addressing comment on ws-rm related to use of extended anonymous uri

Alastair

I'm really really confused by your note. Are you talking about anon on the original request or on the MakeConnection. On the MakeConnection its irrelevant because its logically one-way (just opening the connection).

Paul

Alastair Green wrote:
> Paul,
>
> Can we pursue the second point just a little?
>
> Does the use of [reply endpoint] = anon with SOAP Binding imply that a
> failure to deliver a SOAP envelope in the HTTP response entity body is
> incompatible with a 200/202 HTTP status code?
>
> Or is there only a "moral obligation" to try one's best to reply?
>
> I'm thinking here about the case of responding to a MakeConnection. If
> the former interpretation is correct, then WS-A anon URI won't do,
> because the needed behaviour is "response is optional".
>
> The other case you refer to is one where the "set up message" is the
> first message of the actual conversation, and a reply is immediately
> available.
>
> Variant 1. A sends a set up message, like the one in the spec example,
> that says, in application-specific terms, "get ready to receive
> MakeConnections for connection with UUID X , but don't reply directly
> to this message". This message is a prelude to the real conversation
> or stream.
>
> Variant 2. A sends a message, which contains the connection
> identifier, and an anonymous (or anon-or-none) reply address. The
> expectation is that B will send a message straight back on the HTTP
> response, if it has one, or will "ack" (send an empty, 202), if it
> doesn't want to hang around  till a reply is generated. If the
> conversation style is ping-pong then this could be repeated
> indefinitely, without use of MakeConnection (assuming no failures,
> and/or resent messages are tolerable). However, it is always possible
> that MC will be needed.
>
> To indicate Variant 2 behaviour, would we need to put the connection
> identifier in a special place (e.g. as a header element) which is
> reserved for the semantic "I want a response right now for this
> connection, and be ready to receive a MC if you can't reply"?
>
> In other words, am I right in understanding the general requirement to
> be expressed in a conversation something like this?
>
> A req: message 1, connection X, reply to anon if available.
> B resp: message 2
> A req: message 3, connection X, reply to anon if available B resp: no
> envelope, 202, i.e. message not available A req: MakeConnection, X B
> resp: message 4, MessagePending A req: MakeConnection, X B resp:
> message 5
>
> ["message n" means "real message, not the MC that jollies things
> along"]
>
> Presence of X in message 1 or message 3 has special meaning: it
> implies potential use of MakeConnection to continue the exchange.
>
> Alastair
>
>
>
>
>
>
> Paul Fremantle wrote:
>> Alastair
>>
>> So what you describe is almost exactly the SequenceID-based model for
>> MakeConnection.
>>
>> The "CreateConnection" is implied exactly if and only if there is a
>> CS+Offer with the Offer's EPR as anonymous.
>> The SequenceID then becomes the UUID for the MakeConnection.
>> The "TerminateConnection" is the terminate sequence.
>>
>> As regards this:
>>> 2) *Here's the one that bothers me*. I've raised it before, but seen
>>> no discussion on the point.
>>>
>>> [reply endpoint] = anon does not, in my view, mean "response is
>>> optional". I think, after very careful textual reading of e.g. WS-A
>>> SOAP Binding, that it means (for that binding) -- there must be an
>>> envelope in the transfer protocol's response. Why it means that, is
>>> not clear to me. If that restriction is indeed present, then I think
>>> it would be reasonable to ask WS-A WG to explain/consider change. If
>>> I am imagining things, then great -- no problem, WS-A anon URI will
>>> do the trick. As I have put it before, I think that the [reply
>>> endpoint] is a hybrid of anon and none -- the receiver decides.
>> It is my belief that the server should do everything in its ability
>> to respond on the backchannel when the replyto=anon. I don't think
>> that it should see that RM is on and automatically reply 202 and wait
>> for a MakeConnection. I think that RM should only be there to add
>> reliability in that case. In other words when the socket dies or
>> times out, then the message can be reliably delivered. So I agree
>> with your reading of the WS-A SOAP binding. We are making significant
>> changes to Axis2 and Sandesha to ensure that we try to deliver the
>> response on the backchannel whenever possible.
>>
>> Paul
>>
>>
>> Alastair Green wrote:
>>> I don't think you need to use reference parameters, in order to use
>>> plain WS-A anon URI.
>>>
>>> I raised a number of points relating to this discussion in an
>>> exchange with Doug, Chris and Paul from 4th to 11th August, which I
>>> think could usefully be revisited in the light of the WS-A PR
>>> comments. In the archive the thread starts with
>>>
>>>
>>> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/20
>>> 0608/msg00011.html
>>>
>>>
>>> which is a reply from Doug to an initial posting of mine that is not
>>> archived for some reason. I suggested a scheme that does not require
>>> a special URI, and I shall repeat it here.
>>>
>>> My general thrust was: "why doesn't RM use a normal anon"? I
>>> concluded as the thread progressed that there was little chance of
>>> RX revisiting its design, and as a very part-time member of this
>>> group, didn't want to push the point. However, as it comes up again ...
>>>
>>> There are two items that need to appear on the wire to support the
>>> RM requirement.
>>>
>>> 1) An identifier for a stream of messages (connection).
>>> 2) A message that invites an optional response on the back-channel.
>>>
>>> The identifier type could be left to the application, but it seems
>>> reasonable to define a wsrm:ConnectionIdentifier, and specify its
>>> type (e.g. UUID).
>>>
>>> When app A tells app B that it wants to establish a connection, it
>>> does so by application-defined means. E.g. the Subscribe message in
>>> the spec example.
>>>
>>> [RM could define a message CreateConnection, and then relabel
>>> MakeConnection something like SolicitConnectionMessage, and also add
>>> a BreakConnection, but that's by the by.]
>>>
>>> The connection establishment message has to contain the connection
>>> identifier, e.g. "UUID X". Where it lives (header, body etc) is up
>>> to the application contract.
>>>
>>> Now, by virtue of having received this identifier, the recipient
>>> expects that at some future point it will be asked to send messages
>>> on the back-channel, relating to the identified connection. The app
>>> connection set-up message instigates behaviour in the RM: something
>>> like createBackChannelQueue ("UUID X").
>>>
>>> A's RM endpoint sends MakeConnection, containing the
>>> wsrm:ConnectionIdentifier (what is currently called the
>>> wsrm:Address), and B's RM endpoint either sends an envelope in the
>>> transfer response (consuming the queue), or sends a simple ack (no
>>> message to send to A currently).
>>>
>>> There is in fact no need to use WS-Addressing because the message
>>> MakeConnection already communicates the semantic: "send message for
>>> this connection, if you are ready to".
>>>
>>> But, if you want the addressing layer to do its stuff (hold the HTTP
>>> exchange open) then set MakeConnection [reply endpoint] = WS-A anon
>>> URI.
>>>
>>> The message that is sent on the back-channel does not require any
>>> identification (no need for WS-A [destination endpoint]) because its
>>> destination is fixed, and correlates to the author of MakeConnection
>>> (A), who knows the context. In WS-Addressing terms wsa:To is absent,
>>> but that's OK because that defaults to anon, so the WS-A layer is
>>> satisfied).
>>>
>>> I think that's all that is required. Ref-params have not been
>>> mentioned.
>>>
>>> Elaborations and problems:
>>>
>>> 0) Sequence wsrm:Identifier can also be used to identify the stream
>>> (is a superimposed synonym for an underlying connection).
>>>
>>> 1) A wants to tell B to target all messages for connection X to a
>>> qualifed anon (one that does specify ref-params, that it, A, has
>>> authored). It does so by sending a set-up message (like Subscribe)
>>> that contains a target EPR which is anon + ref-params, /in addition
>>> to/ the connnection identifier.
>>>
>>> When MC comes in for connection X, B sets the ref-params it knows
>>> are associated with connection X. They are received and processed
>>> (only by A) in the normal fashion. I can't quite imagine why you'd
>>> want to do this, but it can be done.
>>>
>>> (If you really hate the idea of using something other than an EPR to
>>> state that a connection is desired, then I don't believe that WS-A
>>> prohibits, or can meaningfully prohibit, private, app-layer
>>> contracts on presence, content, meaning and comparability of
>>> reference-parameters. I think WS-A didn't want to insert complex
>>> rules about comparison and identity of ref-params at its level. You
>>> could move the connection identifier into a ref-param, in that
>>> spirit.)
>>>
>>> 2) *Here's the one that bothers me*. I've raised it before, but seen
>>> no discussion on the point.
>>>
>>> [reply endpoint] = anon does not, in my view, mean "response is
>>> optional". I think, after very careful textual reading of e.g. WS-A
>>> SOAP Binding, that it means (for that binding) -- there must be an
>>> envelope in the transfer protocol's response. Why it means that, is
>>> not clear to me. If that restriction is indeed present, then I think
>>> it would be reasonable to ask WS-A WG to explain/consider change. If
>>> I am imagining things, then great -- no problem, WS-A anon URI will
>>> do the trick. As I have put it before, I think that the [reply
>>> endpoint] is a hybrid of anon and none -- the receiver decides.
>>>
>>> Alastair
>>>
>>>
>>>
>>>
>>> Marc Goodner wrote:
>>>> These are some interesting points, but don't they apply equally to
>>>> the URI as well? Shouldn't the URI be treated as no less opaque? As
>>>> it is the server has to recognize and deconstruct the URI in order
>>>> to understand that not only is the client identifying a new queue
>>>> to poll for messages but also the backchannel required to send
>>>> those messages on. Doesn't that mean that the RM anon URI
>>>> identifies two resources rather than one? Is that legal?
>>>>
>>>> -----Original Message-----
>>>> From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
>>>> Sent: Tuesday, September 26, 2006 2:37 PM
>>>> To: Paul Fremantle; Doug Davis
>>>> Cc: ws-rx@lists.oasis-open.org
>>>> Subject: RE: [ws-rx] PR issue 1 - WS-Addressing comment on ws-rm
>>>> related to use of extended anonymous uri
>>>>
>>>> The origins of this go back to a struggle in WS-Addressing between
>>>> "reference parameters" and "reference properties". Reference
>>>> parameters are supposed to be opaque to everyone except the minter
>>>> of the EPR. The proto-usecase is a service consumer disambiguating
>>>> callback operations by placing unique parameters in its ReplyTo
>>>> EPRs. Using reference parameters to communicate identity
>>>> information from the service consumer to the service provider
>>>> (which is what this idea entails) basically turns them into
>>>> "reference properties". The problem with reference properties is
>>>> that there is *no* such thing (the WS-Addressing WG said so).
>>>>
>>>> It's ironic that the WS-Addressing WG first said "there is no such
>>>> thing as reference properties" then turns around and says "maybe
>>>> you should solve this problem using reference properties".
>>>>
>>>> - gp
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Paul Fremantle [mailto:paul@wso2.com]
>>>>> Sent: Tuesday, September 26, 2006 9:32 AM
>>>>> To: Doug Davis
>>>>> Cc: ws-rx@lists.oasis-open.org
>>>>> Subject: Re: [ws-rx] PR issue 1 - WS-Addressing comment on ws-rm
>>>>> related to use of extended anonymous uri
>>>>>
>>>>> Doug
>>>>>
>>>>>
>>>>>> - rather than looking at the bigger issue of how a new URI
>>>>>>
>>>>> defined by
>>>>>
>>>>>> some specification can compose with WSA's wsaw:Anonymous
>>>>>>
>>>>> URI, the WSA
>>>>>
>>>>>> WG kept wanting to reexamine whether or not RM's solution was the
>>>>>> right choice.  For example, could WSA's anon+ref-p's be
>>>>>>
>>>>> used instead.
>>>>> Didn't we discuss this option (anon+refps)? Can you remind me why
>>>>> we didn't go for it?
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>