ws-rx-implement message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx-implement] FW: RE: [ws-rx] PR issue 1 - WS-Addressing comment onws-rm related to use of extended anonymous uri
- From: Doug Davis <dug@us.ibm.com>
- To: "ws-rx-implement@lists.oasis-open.org" <ws-rx-implement@lists.oasis-open.org>
- Date: Sat, 30 Sep 2006 09:32:40 -0600
Everyone ok with the attached version?
-Doug
Marc Goodner <mgoodner@microsoft.com>
09/27/2006 01:17 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS
|
cc
| "ws-rx-implement@lists.oasis-open.org"
<ws-rx-implement@lists.oasis-open.org>
|
Subject
| RE: [ws-rx-implement] FW: RE: [ws-rx]
PR issue 1 - WS-Addressing comment on ws-rm related to use of extended
anonymous uri |
|
OK, sorry you are correct.
I’m so focused on the polling for the CS in the absence of the outbound
I missed that. In this case I think you need to expand on scenario 4.3
as it isn’t clear that this new sequence is under the same security context
as the outbound sequence.
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, September 27, 2006 9:59 AM
To: Marc Goodner
Cc: ws-rx-implement@lists.oasis-open.org
Subject: Re: [ws-rx-implement] FW: RE: [ws-rx] PR issue 1 - WS-Addressing
comment on ws-rm related to use of extended anonymous uri
Isn't that scenario 3.2 step 5?
-Doug
Dug, shouldn't the interop scenarios cover the MakeConnection using the
RM anon URI to poll for the CS? That was after all the main distinguishing
feature from the SequenceID form wasn't it?
-----Original Message-----
From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Wednesday, September 27, 2006 9:33 AM
To: Alastair Green; Paul Fremantle
Cc: 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
This brings up another point. Am I the only one confused by step 1 in this
example? That's an interaction that isn't described in the spec.
Scenario 3.2 in the interop doc [1] covers initial use of the RM anon URI
as I recall our discussions. Materially it isn't any different than the
SequenceID form of MakeConnection described in scenario 3.1. The other
variant I recall for using the RM anon URI was establishing it with a MakeConnection
message before sending the CS. Essentially this is polling for an inbound
CS message without an outbound sequence. This was the variant that could
not be done with the SequenceID form and is how we wound up with two mechanisms
for the same thing.
Example 1 is not a variant of using the RM anon URI I recall any discussion
around. This example makes me wonder how else a service might receive the
RM anon URI. It implies a broader use of the RM anon URI than what is described
in the spec. I don't think we've thought through the implications of this.
1 http://www.oasis-open.org/apps/org/workgroup/ws-rx-implement/download.php/20311/InteropScenarios2.doc
-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Wednesday, September 27, 2006 9:01 AM
To: Paul Fremantle
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
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/2
>>>> 00608/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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>
InteropScenarios2.doc
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]