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

[Alastair Green <alastair.green@choreology.com>]

I'm just as confused.

Here's a segment of the example from the spec. The MakeConnection is 
responded to by a SOAP envelope containing a real message in the HTTP 
response of the HTTP Request that carried the MakeConnection.

I have always understood that MakeConnection is called repeatedly (when 
needed) to solicit the next message inbound on the response.

Alastair

*Step 5* – The event consumer checks for another message pending:

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"; 
xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608"; 
xmlns:wsa="http://www.w3.org/2005/08/addressing";>
  <S:Header>
    <wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200608/MakeConnection</wsa:Action>
    <wsa:To> http://example.org/subscriptionService </wsa:To>
  </S:Header>
  <S:Body>
    <wsrm:MakeConnection>
      <wsrm:Address>http://docs.oasis-open.org/ws-rx/wsrm/200608/anonymous?id=550e8400-e29b-11d4-a716-446655440000</wsrm:Address>
    </wsrm:MakeConnection>
  </S:Body>
</S:Envelope>

Notice this is the same message as the one sent in step 2.

*Step 6* – If there is a message pending for this destination then it is 
returned on the HTTP response:

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"; 
xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200608"; 
xmlns:wsa="http://www.w3.org/2005/08/addressing";>
  <S:Header>
    <wsa:Action> http://example.org/eventType1 </wsa:Action>
    <wsa:To>http://docs.oasis-open.org/ws-rx/wsrm/200608/anonymous?id=550e8400-e29b-11d4-a716-446655440000</wsa:To>
    <wsrm:Sequence>
      <wsrm:Identifier> http://example.org/rmid-456 </wsrm:Identifier>
    </wsrm:Sequence>
    <wsrm:MessagePending pending="true"/>
  </S:Header>
  <S:Body>
    <!-- event specific data -->
  </S:Body>
</S:Envelope>



Paul Fremantle wrote:
> 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/200608/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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>