- From: Paul Fremantle <paul@wso2.com>
- Date: Wed, 09 Aug 2006 10:55:59 +0100
- To: Alastair Green <alastair.green@choreology.com>
- CC: Christopher B Ferris <chrisfer@us.ibm.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org, ws-rx@lists.oasis-open.org
Alastair
As I said, I have no problem adding reply=none.
However, I'm not sure that means I agree with you.
> 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?
I don't agree. Since the message is a one-way, the WS-A implementation
should be ignoring any replyTo set on that message.
The behaviour you are describing is already in our model and was
introduced with our piggybacking of acks onto one-way messages.
It does have implications at the level of the SOAP stack, because it
requires the ability to add SOAP messages into responses when the
operation is a one-way. This must already exist in all implementations
that support WSRM.
But I do not believe it affects the WS-A implementation. Certainly I
don't believe it affects the Apache Axis2 WS-A implementation.
> At best, this is an RM extension to WS-Addressing, and it should layer
> cleanly on the WS-Addressing core behaviour.
Yes I agree it should layer cleanly onto WS-A core behaviour.
Paul
>
> Paul Fremantle wrote:
>> Alastair
>>
>> I don't think there's anything wrong with [reply= none]. On the other
>> hand, I don't expect to have to put [reply=none] on every one-way
>> interaction I make. I don't believe there is anything wrong with the
>> current situation.
>>
>> Paul
>>
>> Alastair Green wrote:
>>
>>> Chris, Paul:
>>>
>>> *What's wrong with [reply endpoint = none]?
>>>
>>> *1. None URI means "no response expected", implies transport ack only.
>>> Contents of transport response body would reasonably be ignored by a
>>> WS-A implementation.
>>>
>>> 2. WS-A receiver of [reply endpoint] = None URI will not stall for an
>>> application handoff or for application response: it will pass the
>>> inbound message, and immediately ack the sender, and lose all context
>>> (transport response, message id correlation information).
>>>
>>> 3. RM would be asking WS-A implementations to stop natural, generic
>>> behaviours 1. and 2., and become aware of RM.
>>>
>>> 4. None URI means ack only. Anon means SOAP envelope in the transport
>>> response, always. New URI needed to mean: "May be SOAP, may be ack".
>>> Receiver of new URI (APAO below) knows to stall for application
>>> release before acking (empty response body) or SOAPing (full response
>>> body).
>>> *
>>> **Alternatives
>>> *
>>> 1. We can't use [reply endpoint] = anon (the default) because the WS-A
>>> SOAP Binding limits this to cases where there is always a SOAP
>>> envelope in the transport response (ack only forbidden). I believe
>>> this is the /only/ obstacle. Everything else is proceeding from that
>>> WS-A limitation. (If this perceived limitation does not exist, then I
>>> would see no reason not to use anon URI.)
>>>
>>> 2. Create a special URI, as anticipated by the WS-A SOAP Binding, that
>>> means: "Transport response can either be message or ack-alone".
>>>
>>> 3. Call this special URI .../anonymous/permittingAckOnly (APAO). [Not
>>> a good name, a strawman]
>>>
>>> 4. Send MakeConnection/ReplyTo/Address=APAO. Allow ref-params in the
>>> normal manner. (Ref params can't be handled with current solution).
>>>
>>> 5. Permit MakeConnection to contain a sequence Identifier, if desired,
>>> (as per current solution).
>>>
>>> 6. Allow for an extension element in MC, if the app wants to identify
>>> the conversation. The identity of the conversation only has to be
>>> unambiguous between the application parties, so UUID is bound to be
>>> right, but not always needed. The type of the identification is an app
>>> issue. If you don't like that, permit MC to contain a connection
>>> identifier, type is UUID (closest to current solution).
>>>
>>> 7. Decide who's going to own the special APAO URI. It really should be
>>> WS-Addressing, as this is a general, app-level requirement. RM is
>>> permitting an /application /behaviour (the message stream is
>>> application content, which may, in the RM context, be bracketed by
>>> some RM set-up and tear-down, as it happens).
>>>
>>> 8. If process/timescales force RM to "stand in" for WS-Addressing,
>>> then this means worrying about impact on WS-A implementations (which
>>> is where this started from for me). See above re implications for WS-A
>>> implementations of use of none URI
>>>
>>> Alastair
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Christopher B Ferris wrote:
>>>
>>>> Alastair,
>>>>
>>>> I don't think that MakeConnection "invites a response"... rather, it
>>>> opens up the back-channel
>>>> (when transmitted over a protocol such as HTTP that has an inherent
>>>> back-channel) for the
>>>> transmission of a message.
>>>>
>>>> I think that there is a difference... a large one at that.
>>>>
>>>> A SOAP Response is entirely different than a protocol response
>>>> message. In the context
>>>> of a oneway message, carried over a protocol such as HTTP, there is a
>>>> response message
>>>> that may not carry a SOAP envelope in its entity body. It is a
>>>> protocol-level response, not necessarily
>>>> a SOAP level-response. The fact that we are exploiting this is what
>>>> MakeConnection is all about.
>>>>
>>>> As Paul indicated, I would be happy if we suggested that WS-A none
>>>> URI be specified as the
>>>> ReplyTo address, but frankly, I think that that is something for the
>>>> WS-A WG to work out.
>>>>
>>>> Cheers,
>>>>
>>>> Christopher Ferris
>>>> STSM, Software Group Standards Strategy
>>>> email: chrisfer@us.ibm.com
>>>> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
>>>> phone: +1 508 377 9295
>>>>
>>>> Alastair Green <alastair.green@choreology.com> wrote on 08/08/2006
>>>> 11:42:10 AM:
>>>>
>>>>
>>>>> Chris,
>>>>>
>>>>> Redoing part of WS-A in RM creates difficulty in WS-A WSDL (start of
>>>>> thread). Raises question: Why won't standard WS-A anon facility work?
>>>>>
>>>>> You have to say something about where you reply to. If you want the
>>>>> reply to come on the back-channel then WS-A has a way of saying that
>>>>> (and you get that by default).
>>>>>
>>>>> If you say there is no reply, then you are saying: don't send a
>>>>> response. But MC precisely invites a response. How is a WS-A
>>>>> implementation supposed to understand (without being RM aware) that
>>>>> reply=none really means (functionally) reply=anon? I perceive
>>>>> unnecessary layering tangle. WS-A layer now expected to hold HTTP
>>>>> response for app, even though told that there is no response.
>>>>>
>>>>> Researching further, I don't understand why an RM-specific
>>>>> alternative to reply=anon has been introduced for the "address"
>>>>> case, but not for the "sequence" case.
>>>>>
>>>>> I believe regular "use back channel" feature of WS-A can be used,
>>>>> and the RM layer can handle RM "sessions", in both cases.
>>>>>
>>>>> Does my example of sequence case indicate expected behaviour? Would
>>>>> it be wrong to say MC/reply=anon with sequence case?
>>>>>
>>>>> First part of long message addresses Doug's points about the
>>>>> application-level set-up message: I don't understand the relevance
>>>>> of that type of message.
>>>>>
>>>>> Alastair
>>>>>
>>>>>
>>>>>
>>>>> Christopher B Ferris wrote:
>>>>>
>>>>> Alastair,
>>>>>
>>>>> Is this a long and drawn out manner of stating that when a message
>>>>> is a true oneway (e.g. no
>>>>> response is expected) then the wsa:ReplyTo should be the WS-A none
>>>>> URI rather than
>>>>> simply leaving it absent and hence falling trap to the "if not
>>>>> present, default to anon" gotcha?
>>>>>
>>>>> I guess I am not seeing an issue here, although I guess it would be
>>>>> fine if we recommended or required
>>>>> that the MakeConnection wsa:ReplyTo MAP carry the WS-A none URI.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Christopher Ferris
>>>>> STSM, Software Group Standards Strategy
>>>>> email: chrisfer@us.ibm.com
>>>>> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
>>>>> phone: +1 508 377 9295
>>>>>
>>>>> public-ws-addressing-request@w3.org wrote on 08/08/2006 07:06:32 AM:
>>>>>
>>>>>
>>>>>> Doug, Paul --
>>>>>>
>>>>>> I'm going to try to address both your comments. if I can summarize
>>>>>> Paul's it was: what's the big deal about [reply endpoint] when
>>>>>> MakeConnection is "one-way"?.
>>>>>>
>>>>>> Given RX timescales you may want to treat these remarks as "early
>>>>>> public review".
>>>>>>
>>>>>> * * *
>>>>>>
>>>>>> Doug's message 1 is an application-level set-up call which
>>>>>> establishes common understanding of the UUID. This type of message
>>>>>> is exemplified by that shown in the CD example Step 1, unless I have
>>>>>> completely misunderstood.
>>>>>>
>>>>>> In that example, a subscriber, who cannot listen, sends a subscribe
>>>>>> message to a publisher, saying something like "subscribe me for
>>>>>> topics A, B, C. The identity of this subscription request is UUID
>>>>>> X". Thereafter, the publisher knows that X equals "subscription for
>>>>>> topics A, B, C".
>>>>>>
>>>>>> Assertion 1 (please correct me if I am wrong): The format, content
>>>>>> etc of this type of message (and its manner of transmission) are
>>>>>> entirely application-specific. It may or may not require an
>>>>>> acknowledgement. It could be sent by carrier pigeon, or by fax. The
>>>>>> subscribe message, if sent as SOAP-with-Addressing, might receive a
>>>>>> reply, or might not receive a reply, and if it did, it might receive
>>>>>> it anon or addressable. There are no RM rules that apply to this
>>>>>> message. There are only application rules. It cannot do its job
>>>>>> usefully unless it passes the UUID: that is all we can say.
>>>>>>
>>>>>> Assertion 2. At present there is an RM rule which says: "the
>>>>>> mutually understood UUID must be reflected in the [destination
>>>>>> endpoint] according to an RM URI scheme". There are no RM rules to
>>>>>> say whether the connection UUID, during the course of establishing
>>>>>> mutual understanding, travels alone, embedded in a URI, in a body
>>>>>> element or a header element. These are all matters of bilateral
>>>>>> agreement at an app level between (in this case) the
>>>>>> consumer/subscriber and the producer/publisher.
>>>>>>
>>>>>> [The example is potentially a bit misleading in this respect.
>>>>>>
>>>>>> The use of the full "anon-URI?id={uuid}" value in the <targetEPR/>,
>>>>>> and the use of the element name "targetEPR" make one think
>>>>>> "addressing", when one would be better off thinking "subscription
>>>>>> identity" (at an app level). The example set-up message would work
>>>>>> perfectly well if it read:
>>>>>>
>>>>>> <S:Body>
>>>>>> <!-- subscription details -->
>>>>>> <SubscriptionIdentity>{uuid}</SubscriptionIdentity>
>>>>>> </S:Body>
>>>>>>
>>>>>> Btw, given that the use of MakeConnection requires a prior
>>>>>> understanding between two parties of the connection identity, there
>>>>>> seems no reason why {uuid} has to be a UUID. It does need to be
>>>>>> bilaterally unambiguous.]
>>>>>>
>>>>>> * * *
>>>>>>
>>>>>> Message 2 is MakeConnection. If the subscriber sends a
>>>>>> MakeConnection, specifying UUID X, then the publisher knows it is
>>>>>> dealing with traffic relating to subscription X, i.e. for topics A,
>>>>>> B and C. At an application level, we assume that the contract
>>>>>> thereafter is: start reliably communicating a stream of messages,
>>>>>> relating to topics A, B and C, therefore implying sequence creation
>>>>>> etc, until something causes the stream to close.
>>>>>>
>>>>>> So the subscriber will repeatedly send MakeConnection, citing the
>>>>>> UUID X, read the HTTP response, and handle the response as if it
>>>>>> were an inbound RM/RM-app message.
>>>>>>
>>>>>> The exchange that RM defines (rather than illustrates) is the
>>>>>> MakeConnection, back-call-on-the-connection one. It's this exchange
>>>>>> that I am discussing. MakeConnection is the message affected by the
>>>>>> WSAW anon=required discussion, as I see it.
>>>>>>
>>>>>> [While it is probably helpful for diagnostic reasons to repeat the
>>>>>> UUID back to the sender of MakeConnection in the [destination
>>>>>> endpoint], it is actually redundant, as the HTTP Response is
>>>>>> automatically and uniquely correlated with the HTTP Request. This
>>>>>> might lead one to the conclusion that the simple solution would have
>>>>>> been: send UUID on MakeConnection, and then respond to it on the
>>>>>> anonymous back-channel without reflection of UUID in any form
>>>>>> However, this would reduce the symmetry with the Sequence identified
>>>>>> use of MakeConnection, see comments later]
>>>>>>
>>>>>> * * *
>>>>>>
>>>>>> There are two modes in which this exchange can work (reflecting the
>>>>>> joint proposal, as I understand it):
>>>>>>
>>>>>> a) Send response as part of a sequence that already exists
>>>>>> b) Use response to create a new sequence, etc
>>>>>>
>>>>>> This is relevant to answering Paul F's question, relating to the
>>>>>> significance of ReplyTo.
>>>>>>
>>>>>> If there is a sequence, then the sequence Identifier is a
>>>>>> correlation synonym for the UUID. The reply message may be sent on
>>>>>> the back-channel; it must carry the wsrm:Identifier (as a separate
>>>>>> header element), it need not carry the UUID.
>>>>>>
>>>>>> If there is no sequence, then the reply message must carry or imply
>>>>>> the UUID. (I'm going to assume that carrying the UUID is better than
>>>>>> implying it.) The question is how?
>>>>>>
>>>>>> Looking at these two cases, it is striking that both
>>>>>>
>>>>>> a) require a response on the back-channel,
>>>>>> b) need to carry an identifier (one of the sequence, one of the
>>>>>> "connection"/"session")
>>>>>>
>>>>>> Doug's comment that there is no wsa:ReplyTo on the MakeConnection,
>>>>>> that it is "one way", is relevant here. In fact there is no such
>>>>>> thing (in the XML infoset) as a non-existent [reply endpoint]. If
>>>>>> wsa:ReplyTo is absent, then it is inferred to be the anon-URI. The
>>>>>> only way you can stop that inference is to set the [reply endpoint]
>>>>>> to none or to a "real address". I don't think you want to do either
>>>>>> of those things, in this context.
>>>>>>
>>>>>> With these points in mind, I think it is worth looking again at my
>>>>>> previous postings.
>>>>>>
>>>>>> The orthodox way of saying "respond on the back-channel" is setting
>>>>>> [reply endpoint] to anon. This can be done explicitly or by
>>>>>> inference from absence.
>>>>>>
>>>>>> I think there has to be a good reason to invent a new way of
>>>>>> expressing this semantic. Doing so has repercussions (see the
>>>>>> original starting point of this thread, re WSA W anon/required). The
>>>>>> (very valuable) use case of MakeConnection does not require an
>>>>>> alternate mechnanism for stating the back channel semantic.
>>>>>>
>>>>>> We can illustrate all of this by placing three examples side by side:
>>>>>>
>>>>>> * * *
>>>>>>
>>>>>> 1. Example using sequence Identifier: MakeConnection and reply
>>>>>>
>>>> [asper CD 04]
>>>>
>>>>>> 2. Example using hypothetical connection identifier: MakeConnection
>>>>>> and reply [as it could be, simplified]
>>>>>> 3. Example using current Address [as per CD 04]
>>>>>>
>>>>>> 1a. Example using sequence Identifier: MakeConnection
>>>>>>
>>>>>> <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:MessageID>http://example.org/subscriptionService/
>>>>>> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:MessageID>
>>>>>> <wsa:Action>http://docs.oasis-open.
>>>>>>
>>>>> org/wsrx/wsrm/200608/MakeConnection
>>>>>
>>>>>> </wsa:Action>
>>>>>> <wsa:To>http://example.org/subscriptionService</wsa:To>
>>>>>> <!-- absent wsa:ReplyTo is equivalent to:
>>>>>> <wsa:ReplyTo>
>>>>>> <wsa:Address>http://docs.oasis-open.
>>>>>>
>>>>> org/wsrx/wsrm/200608/anonymous
>>>>>
>>>>>> </wsa:Address>
>>>>>> </wsa:ReplyTo>
>>>>>> -->
>>>>>> </S:Header>
>>>>>> <S:Body>
>>>>>> <wsrm:MakeConnection>
>>>>>> <wsrm:Identifier>http://Business456.
>>>>>> com/SubscribeTopics/Sequence/7456-3278</wsrm:Identifier>
>>>>>> </wsrm:MakeConnection>
>>>>>> </S:Body>
>>>>>> </S:Envelope>
>>>>>>
>>>>>> 1b. Example using sequence Identifier: reply to MakeConnection
>>>>>>
>>>>>> <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:MessageID>http://example.org/subscriptionService/
>>>>>> guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e</wsa:MessageID>
>>>>>> <wsa:RelatesTo>http://example.org/subscriptionService/
>>>>>> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:RelatesTo>
>>>>>>
>>>>>>
>>>> <wsa:ReplyTo><wsa:Address>http://example.org/subscriptionService
>>>>
>>>>>> </wsa:Address></wsa:ReplyTo>
>>>>>> <wsa:Action>http://example.com/subscriptionService/publish
>>>>>> </wsa:Action>
>>>>>> <wsrm:Sequence>
>>>>>> <wsrm:Identifier>http://Business456.
>>>>>> com/SubscribeTopics/Sequence/7456-3278</wsrm:Identifier>
>>>>>> <wsrm:MessageNumber>1</wsrm:MessageNumber>
>>>>>> </wsrm:Sequence>
>>>>>> </S:Header>
>>>>>> <S:Body>
>>>>>> <!-- Publication re A, B or C -->
>>>>>> </S:Body>
>>>>>> </S:Envelope>
>>>>>>
>>>>>> 2a. Example using hypothetical connection identifier: MakeConnection
>>>>>>
>>>>>> <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:MessageID>http://example.org/subscriptionService/
>>>>>> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:MessageID>
>>>>>> <wsa:Action>http://docs.oasis-open.
>>>>>>
>>>>> org/wsrx/wsrm/200608/MakeConnection
>>>>>
>>>>>> </wsa:Action>
>>>>>> <wsa:To>http://example.org/subscriptionService</wsa:To>
>>>>>> <!-- absent wsa:ReplyTo is equivalent to:
>>>>>> <wsa:ReplyTo>
>>>>>> <wsa:Address>http://docs.oasis-open.
>>>>>>
>>>>> org/wsrx/wsrm/200608/anonymous
>>>>>
>>>>>> </wsa:Address>
>>>>>> </wsa:ReplyTo>
>>>>>> -->
>>>>>> </S:Header>
>>>>>> <S:Body>
>>>>>> <wsrm:MakeConnection>
>>>>>> <wsrm:ConnectionIdentifier>http://Business456.com/
>>>>>> SubscribeTopics/Stream/7457</wsrm:ConnectionIdentifier>
>>>>>> </wsrm:MakeConnection>
>>>>>> </S:Body>
>>>>>> </S:Envelope>
>>>>>>
>>>>>> 2b. Example using hypothetical connection identifier: reply to
>>>>>> MakeConnection (CreateSequence)
>>>>>>
>>>>>> <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:MessageID>http://example.org/subscriptionService/
>>>>>> guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e</wsa:MessageID>
>>>>>> <wsa:RelatesTo>http://example.org/subscriptionService/
>>>>>> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:RelatesTo>
>>>>>> <wsa:Action>http://docs.oasis-open-
>>>>>>
>>>>> org/wsrx/wsrm/200608/CreateSequence
>>>>>
>>>>>> </wsa:Action>
>>>>>>
>>>>>>
>>>> <wsa:ReplyTo>http://example.org/subscriptionService</wsa:ReplyTo>
>>>>
>>>>>> <wsrm:ConnectionIdentifier>
>>>>>> http://Business456.com/SubscribeTopics/Stream/7457
>>>>>> </wsrm:ConnectionIdentifier>
>>>>>> </S:Header>
>>>>>> <S:Body>
>>>>>> <wsrm:CreateSequence>
>>>>>> <wsrm:AcksTo>
>>>>>> <wsa:Address>http://example.org/subscriptionService
>>>>>> </wsa:Address>
>>>>>> </wsrm:AcksTo>
>>>>>> </wsrm:CreateSequence>
>>>>>> </S:Body>
>>>>>> </S:Envelope>
>>>>>>
>>>>>> 3a. Example using wsrm:Address: MakeConnection
>>>>>>
>>>>>> <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:MessageID>http://example.org/subscriptionService/
>>>>>> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:MessageID>
>>>>>> <wsa:Action>http://docs.oasis-open.
>>>>>>
>>>>> org/wsrx/wsrm/200608/MakeConnection
>>>>>
>>>>>> </wsa:Action>
>>>>>> <wsa:To>http://example.org/subscriptionService</wsa:To>
>>>>>> <!-- absent wsa:ReplyTo is equivalent to:
>>>>>> <wsa:ReplyTo>
>>>>>> <wsa:Address>http://docs.oasis-open.
>>>>>>
>>>>> org/wsrx/wsrm/200608/anonymous
>>>>>
>>>>>> </wsa:Address>
>>>>>> </wsa:ReplyTo>
>>>>>> -->
>>>>>> </S:Header>
>>>>>> <S:Body>
>>>>>> <wsrm:MakeConnection>
>>>>>> <wsrm:Address>
>>>>>> http://docs.oasis-open.
>>>>>>
>>>>>>
>>>> org/wsrx/wsrm/200608/anonymous?id=550e8400-e29b-11d4-a716-446655440000
>>>>
>>>>>> </wsrm:Address>
>>>>>> </wsrm:MakeConnection>
>>>>>> </S:Body>
>>>>>> </S:Envelope>
>>>>>>
>>>>>> 3b. Example using wsrm:Address: reply to MakeConnection
>>>>>>
>>>> (CreateSequence)
>>>>
>>>>>> <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:MessageID>http://example.org/subscriptionService/
>>>>>> guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e</wsa:MessageID>
>>>>>> <wsa:RelatesTo>http://example.org/subscriptionService/
>>>>>> guid/61e0654e-5ce8-477b-bb9d-34f05cdcbc9e</wsa:RelatesTo>
>>>>>> <wsa:Action>http://docs.oasis-open-
>>>>>>
>>>>> org/wsrx/wsrm/200608/CreateSequence
>>>>>
>>>>>> </wsa:Action>
>>>>>> <wsa:To>
>>>>>>
>>>>>> <!-- I believe this is WS-A illegal: reply To must equal request
>>>>>> ReplyTo/Address. -->
>>>>>>
>>>>>> http://docs.oasis-open.org/wsrx/wsrm/200608/anonymous?
>>>>>> id=550e8400-e29b-11d4-a716-446655440000
>>>>>> </wsa:To>
>>>>>>
>>>>>>
>>>> <wsa:ReplyTo>http://example.org/subscriptionService</wsa:ReplyTo>
>>>>
>>>>>> </S:Header>
>>>>>> <S:Body>
>>>>>> <wsrm:CreateSequence>
>>>>>> <wsrm:AcksTo>
>>>>>> <wsa:Address>http://example.org/subscriptionService
>>>>>> </wsa:Address>
>>>>>> </wsrm:AcksTo>
>>>>>> </wsrm:CreateSequence>
>>>>>> </S:Body>
>>>>>> </S:Envelope>
>>>>>>
>>>>>> Yours,
>>>>>>
>>>>>> Alastair
>>>>>>
>>>>>> Doug Davis wrote:
>>>>>>
>>>>>> Alastair,
>>>>>> I think you're mixing up the messages a bit. There are two
>>>>>>
>>>> messages
>>>>
>>>>>> at play:
>>>>>> 1 - the message containing the EPR to send subsequent messages to.
>>>>>> In some cases this message will have the EPR in its wsa:ReplyTo
>>>>>> header, but it could also be placed someplace else depending
>>>>>> on its use. And it is this EPR that needs to be tagged as the
>>>>>> polling one (ie. it has the RM anon URI).
>>>>>> This message will contain application specific data in the Body
>>>>>> so your suggestion of placing some UUID in there will not work.
>>>>>> This gets back to the necessity to keep all info about where to
>>>>>> send messages encapsulated into whatever EPR we want to be
>>>>>>
>>>> tagged
>>>>
>>>>>> as the polling one.
>>>>>>
>>>>>> 2 - the MakeConnection message.
>>>>>> This message does not have a wsa:ReplyTo, its a one-way. This
>>>>>> message does contain a Body which is the correlation info used
>>>>>> by the receiver of this message to find an appropriate message
>>>>>> to send back. So, basically the stuff in the Body must match
>>>>>> the EPR from message 1. And given that in some cases the only
>>>>>> thing remaining from the EPR in message 1 is the serialized
>>>>>> version of it, we must be able to find messages based solely
>>>>>> on what's in the outgoing message itself. Which means the
>>>>>> wsa:To field. Again, ref-p's are bad for this purpose. :-)
>>>>>>
>>>>>> HTH
>>>>>>
>>>>>> thanks
>>>>>> -Doug
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alastair Green <alastair.green@choreology.com> wrote on 08/07/2006
>>>>>> 02:02:55 PM:
>>>>>>
>>>>>>
>>>>>>> Doug,
>>>>>>>
>>>>>>> I think I'm connecting, if you'll pardon the pun.
>>>>>>>
>>>>>>> 1. As I read WS-A, the [destination endpoint][address] must be set
>>>>>>> to [reply endpoint][address] for a reply.
>>>>>>>
>>>>>>> 2. If [reply endpoint] is omitted (as per the CD example), then
>>>>>>> [reply endpoint] = anon, by default.
>>>>>>>
>>>>>>> 3. If [destination endpoint] = "anon-URI?id={uuid}", then
>>>>>>> [destination endpoint] <> [reply endpoint][address] (which was
>>>>>>> simple, unornamented anon-URI), which contradicts premise 1.
>>>>>>>
>>>>>>> Does that make sense? If so, then I think you would need to set
>>>>>>> [reply endpoint] to none, explicitly, to avoid that clash (given
>>>>>>> RM's current approach). But this causes
>>>>>>>
>>>>>>> 4. The WS-A processor that sent MakeConnection to get very
>>>>>>>
>>>> confused.
>>>>
>>>>>>> It wasn't expecting anything but an HTTP 200 series by way of a
>>>>>>> response, but is about to get a full-scale SOAP message
>>>>>>>
>>>> bounding back.
>>>>
>>>>>>> +++
>>>>>>>
>>>>>>> Further thoughts, which continue, in my mind, to question the
>>>>>>> current RM approach, but which may ease the WSA W problem.
>>>>>>>
>>>>>>> a) You could have defined an extension element in the [reply
>>>>>>> endpoint] for the UUID.
>>>>>>>
>>>>>>> b) Or, you could have chosen to send the UUID in the body element.
>>>>>>>
>>>>>>> c) In either case, this could team up with setting [reply
>>>>>>>
>>>>>> endpoint] to anon.
>>>>>>
>>>>>>> d) As in 3. above, you shouldn't then set response [destination
>>>>>>> endpoint] to anon?id={uuid}.
>>>>>>>
>>>>>>> e) So, you need to set [reply endpoint] to anon, and set
>>>>>>> [destination endpoint][address] to anon.
>>>>>>>
>>>>>>> f) which begs the question, where does the UUID go?
>>>>>>>
>>>>>>> g) If you passed an extension element UUID, or a UUID in the body
>>>>>>> element, and then passed it back as an extension element in the
>>>>>>>
>>>> anon
>>>>
>>>>>>> EPR that should be OK, because you have followed the rules for
>>>>>>>
>>>> reply
>>>>
>>>>>>> formulation with respect to the [destination endpoint][address]
>>>>>>> /[reference parameters]. The fact you have chosen to put an
>>>>>>> extension element in the response is WS-A 3.3/3.4 legal, as I read
>>>>>>> it. That's a higher-layer behaviour that does not contradict WS-A
>>>>>>> base behaviour, which is constrained.
>>>>>>>
>>>>>>> +++
>>>>>>>
>>>>>>> Why is g) not viable in your view? The processors that need to
>>>>>>> understand the body/extension UUID element are the RM senders and
>>>>>>> responders (not the WS-A processors, which passively pass on the
>>>>>>> UUID to the RM receiver of MakeConnection, and pass on the
>>>>>>>
>>>> extension
>>>>
>>>>>>> element to the RM receiver of the response).
>>>>>>>
>>>>>>> In other words, the awareness of RM-ness that is demanded in
>>>>>>> formulating MakeConnection, and in replying to it, resides in the
>>>>>>> same place, and at the same level, as in the current (CD) solution.
>>>>>>>
>>>>>>> The difference being: that the MakeConnection is now a regular
>>>>>>> [reply endpoint] = anon. At which point special WSAW rules are
>>>>>>>
>>>> not needed.
>>>>
>>>>>>> I don't see any lesser or greater problem with intermediaries,
>>>>>>> onward transmission etc than would apply with the current
>>>>>>>
>>>> solution,
>>>>
>>>>>>> if that is a concern. On this point, I think I may be missing
>>>>>>> something, or misunderstanding your area of concern?
>>>>>>>
>>>>>>> So, to summarize:
>>>>>>>
>>>>>>> 1. asimple-non out, special, ornamented-anon back is a problem.
>>>>>>> 2. none out, anon back is a problem.
>>>>>>> 3. extension element UUID out, extension element UUID back, is no
>>>>>>> different, in layer terms, than body UUID out, ornamented address
>>>>>>> back, i.e. is not a problem.
>>>>>>> 4. anon out means no problem with anon = required.
>>>>>>>
>>>>>>>
>>>>>>> * * *
>>>>>>>
>>>>>>> My last point was indeed completely beside the point of your
>>>>>>>
>>>> issue :
>>>>
>>>>>>> -) -- it is an independent issue about WSAW, and a limitation that
>>>>>>> the proposed syntax seems to impose by applying the flag across
>>>>>>>
>>>> all
>>>>
>>>>>>> "response endpoints".
>>>>>>>
>>>>>>> Alastair
>>>>>>>
>>>>>>> Doug Davis wrote:
>>>>>>>
>>>>>>> Alastair,
>>>>>>> We did consider adding some extra metadata to the EPR
>>>>>>>
>>>> (outside of
>>>>
>>>>>>> the wsa:Address and ref-p's), but there's a problem - this
>>>>>>>
>>>> metadata
>>>>
>>>>>>> is not copied over into the response message - just the
>>>>>>>
>>>> wsa:Address
>>>>
>>>>>>> and ref-p's are. This means that any data placed elsewhere in the
>>>>>>> EPR is lost once the message is serialized. So unless we
>>>>>>>
>>>> assume the
>>>>
>>>>>>> impl can hold on to the original EPR for the entire message path
>>>>>>> (which we can't in distributed systems), the identity part must be
>>>>>>> in either the address or ref-p's. And, as you said, ref-p's
>>>>>>>
>>>> aren't
>>>>
>>>>>>> good for this.
>>>>>>>
>>>>>>> What's interesting about your anon?unique-id example is that
>>>>>>>
>>>> that
>>>>
>>>>>>> solution might work very nicely (we talked about this in the
>>>>>>>
>>>> past) -
>>>>
>>>>>>> but as you said it would require WSA to say anon URIs 'start
>>>>>>> with...' - and WSA is closed :-(
>>>>>>>
>>>>>>> I got a bit lost on your last point - it almost sounded like a
>>>>>>> complaint about the current WSA WSDL spec instead of my issue -
>>>>>>>
>>>> or
>>>>
>>>>>>> did I not follow it?
>>>>>>>
>>>>>>> I noticed that on the agenda for tomorrow's WSA call (I think
>>>>>>>
>>>> its
>>>>
>>>>>>> tomorrow) is a CR issue that mentioned how this wording in the
>>>>>>>
>>>> WSDL
>>>>
>>>>>>> spec prevents the use of "none". I can't help but think that both
>>>>>>> issues (mine and the other CR issue) would be solved nicely if the
>>>>>>> wording were turned around a bit and said something about how this
>>>>>>> flag indicates whether or not the endpoint supports addressable
>>>>>>> endpoints in the response EPRs. Not sure of the exact wording,
>>>>>>>
>>>> but
>>>>
>>>>>>> if instead of taking about specific URIs (like anon and none) it
>>>>>>> talked about whether the endpoint supported the notion of creating
>>>>>>> it own connections to the EPR then it wouldn't need to get into
>>>>>>>
>>>> the
>>>>
>>>>>>> business of listing all of the URIs that are valid. And I
>>>>>>>
>>>> think it
>>>>
>>>>>>> would relay the exact same information.
>>>>>>>
>>>>>>> thanks
>>>>>>> -Doug
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Alastair Green <alastair.green@choreology.com>
>>>>>>> 08/04/2006 10:57 AM
>>>>>>>
>>>>>>> To
>>>>>>>
>>>>>>> Doug Davis/Raleigh/IBM@IBMUS
>>>>>>>
>>>>>>> cc
>>>>>>>
>>>>>>> public-ws-addressing@w3.org, public-ws-addressing-request@w3.org,
>>>>>>> ws-rx@lists.oasis-open.org, abbieb@nortel.com, aclark@novell.com,
>>>>>>> akira.tanaka.pr@hitachi.com, aleyfer@actional.com,
>>>>>>>
>>>> anash@reactivity.com,
>>>>
>>>>>>> andreas.bjarlestam@ericsson.com, anil.edakkunni@soa.com, anil.
>>>>>>>
>>>>>> john@jhuapl.edu
>>>>>>
>>>>>>> , Anish.Karmarkar@oracle.com, Anthony Nadalin/Austin/IBM@IBMUS,
>>>>>>> asakala@iona.com, ash@rainingdata.com, ashok.malhotra@oracle.com,
>>>>>>> asirveda@microsoft.com, atarashi@sv.nec-labs.com,
>>>>>>>
>>>> atmanes@gmail.com,
>>>>
>>>>>>> audet@nortel.com, barreto@adobe.com, bhakti.mehta@sun.com, blake.
>>>>>>> dournaee@intel.com, bob.freund@hitachisoftware.com,
>>>>>>>
>>>> bob.sunday@pwgsc.gc.ca
>>>>
>>>>> ,
>>>>>
>>>>>>> b.eckenfels@seeburger.de, carolina.canales@ericsson.com,
>>>>>>>
>>>>> chamikara@wso2.com
>>>>>
>>>>>> ,
>>>>>>
>>>>>>> chappell@sonicsoftware.com, Charles Levay/Raleigh/IBM@IBMUS,
>>>>>>> chouthri@sv.nec-labs.com, Christopher B Ferris/Waltham/IBM@IBMUS,
>>>>>>> Christopher.Kurt@microsoft.com, chris.hipson@bt.com, "'von
>>>>>>>
>>>>> Riegen, Claus'"
>>>>>
>>>>>>> <claus.von.riegen@sap.com>, coevans@microsoft.com,
>>>>>>>
>>>>> cunningham_david@bah.com
>>>>>
>>>>>> ,
>>>>>>
>>>>>>> dan@actional.com, "'Burdett, David'" <david.burdett@sap.com>,
>>>>>>> dconnelly@openapplications.org, Diane Jordan/Raleigh/IBM@IBMUS,
>>>>>>> dkmin@konkuk.ac.kr, dleshc@tibco.com, dmoberg@us.axway.com,
>>>>>>>
>>>>>> dnickull@adobe.com
>>>>>>
>>>>>>> , "'David Orchard'" <dorchard@bea.com>, doug.bunting@sun.com,
>>>>>>> eisaku.nishiyama.dd@hitachi.com, email@cbvenkat.net,
>>>>>>>
>>>> eoghan.glynn@iona.com
>>>>
>>>>> ,
>>>>>
>>>>>>> Eric.Newcomer@iona.com, eric.rajkovic@oracle.com, eric.
>>>>>>> wells@hitachisoftware.com, ganga.sah@oracle.com,
>>>>>>>
>>>> gatfora@uk.ibm.com,
>>>>
>>>>>>> gboschi@sonicsoftware.com, gdaniels@sonicsoftware.com,
>>>>>>>
>>>> "'Gilbert Pilz'"
>>>>
>>>>>>> <Gilbert.Pilz@bea.com>, girish.juneja@intel.com,
>>>>>>>
>>>> gregcarp@microsoft.com,
>>>>
>>>>>>> greg.pavlik@oracle.com, hbenmalek@us.fujitsu.com,
>>>>>>>
>>>> heiko.braun@jboss.com,
>>>>
>>>>>>> ian.c.jones@bt.com, ian_robinson@uk.ibm.com,
>>>>>>>
>>>> james.speer@capgemini.com,
>>>>
>>>>>>> jamie.clark@oasis-open.org, jdurand@us.fujitsu.com, jeff.
>>>>>>> mischkinsky@oracle.com, jekanaya@cs.indiana.edu,
>>>>>>>
>>>> Jiri.Tejkl@systinet.com,
>>>>
>>>>>>> jjchoe@tmax.co.kr, jkchoi@methodi.com, jmarsh@microsoft.com, joeri.
>>>>>>> van_cleynenbreugel@alcatel.be, john.gotze@oasis-open.org, john.
>>>>>>>
>>>>>> kemp@nokia.com
>>>>>>
>>>>>>> , joseph.2.waller@bt.com, junghc@nca.or.kr, jypyon@nca.or.kr, k-
>>>>>>> seki@da.jp.nec.com, kcyee@cecid.hku.hk, kiwasa@jp.fujitsu.com,
>>>>>>> lburch@novell.com, lily.liu@webmethods.com, "'Lei Jin'"
>>>>>>>
>>>> <ljin@bea.com>,
>>>>
>>>>>>> machi@nca.or.kr, "'Mark Little'" <mark.little@jboss.com>,
>>>>>>> "'Schenecker, Mark'" <mark.schenecker@sap.com>, "'de Boer,
>>>>>>>
>>>> Martijn'"
>>>>
>>>>>>> <martijn.de.boer@sap.com>, "'Raepple, Martin'"
>>>>>>>
>>>> <martin.raepple@sap.com>,
>>>>
>>>>>>> mary.mcrae@oasis-open.org, matsuki.yoshino.pw@hitachi.com,
>>>>>>>
>>>>>> mckierna@uk.ibm.com
>>>>>>
>>>>>>> , mgoodner@microsoft.com, mhb@itst.dk, "'Bechauf, Michael'"
>>>>>>> <michael.bechauf@sap.com>, mike.grogan@sun.com,
>>>>>>>
>>>> millwood@uk.ibm.com,
>>>>
>>>>>>> mlovett@uk.ibm.com, mlyons@layer7tech.com, mschenecker@e2open.com,
>>>>>>> mwang@tibco.com, nickr@enosis.com, nilo.mitra@ericsson.com,
>>>>>>> nobuyuki.yamamoto.vw@hitachi.com, Ondrej.Hrebicek@microsoft.com,
>>>>>>>
>>>>>> paul@wso2.com
>>>>>>
>>>>>>> , pauld@mitre.org, paul.cotton@microsoft.com,
>>>>>>>
>>>> paul.knight@nortel.com,
>>>>
>>>>>>> peter.furniss@erebor.co.uk, peter_niblett@uk.ibm.com,
>>>>>>>
>>>> pete.wenzel@sun.com
>>>>
>>>>> ,
>>>>>
>>>>>>> prateek.mishra@oracle.com, pyendluri@webmethods.com, Richard
>>>>>>> Salz/Cambridge/IBM@IBMUS, robin@oasis-open.org,
>>>>>>>
>>>> sada@jp.fujitsu.com,
>>>>
>>>>>>> "'Patil, Sanjay'" <sanjay.patil@sap.com>, sanka@wso2.com,
>>>>>>>
>>>>> scayron@acord.org
>>>>>
>>>>>>> , Scott Hinkelman/Austin/IBM@IBMUS, shengsong.ni@oracle.com,
>>>>>>> shivajee@tibco.com, srcarter@novell.com, stefanba@microsoft.com,
>>>>>>> "'Rossmanith, Stefan'" <stefan.rossmanith@sap.com>, "'Winkler,
>>>>>>>
>>>> Steve'"
>>>>
>>>>>>> <steve.winkler@sap.com>, sumit.gupta@oracle.com,
>>>>>>>
>>>> tboubez@layer7tech.com,
>>>>
>>>>>>> tejeswar.das@iona.com, thomas.erl@soasystems.com,
>>>>>>>
>>>> thomas.t.bui@boeing.com
>>>>
>>>>> ,
>>>>>
>>>>>>> timothy@drummondgroup.com, toby.considine@unc.edu,
>>>>>>>
>>>> tom@coastin.com,
>>>>
>>>>>>> "'Yalcinalp, Umit'" <umit.yalcinalp@sap.com>,
>>>>>>>
>>>> vfurman@webmethods.com
>>>>
>>>>>>> , "'Shipkowitz, Vicki'" <vicki.shipkowitz@sap.com>,
>>>>>>>
>>>> vikas@sonoasystems.com
>>>>
>>>>>>> , "'Videlov, Vladimir'" <vladimir.videlov@sap.com>, Martin Chapman
>>>>>>> <martin.chapman@oracle.com>
>>>>>>>
>>>>>>> Subject
>>>>>>>
>>>>>>> Re: Comment on WSDL spec: use of Anonymous Element
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Doug,
>>>>>>>
>>>>>>> Comments interspersed:
>>>>>>>
>>>>>>> Doug Davis wrote:
>>>>>>>
>>>>>>> Alastair,
>>>>>>> There are a couple of different things at play here. First, sorry
>>>>>>> about the long cc-list but the wsrx mailing list still doesn't
>>>>>>> appear to work so I need to include the entire wsrx team
>>>>>>>
>>>> manually :-(
>>>>
>>>>>>> I thought my mail client was going to expire when I just did
>>>>>>>
>>>> "reply all".
>>>>
>>>>>>> In a non-anonymous world the wsa:Address field represents both the
>>>>>>> fact that the destination can access connections and it identifies
>>>>>>> the party. And I think that makes sense. There is no reason
>>>>>>>
>>>> to not
>>>>
>>>>>>> have a single URI do that (let's not get into the 'identity' issue
>>>>>>> w.r.t. ref-p's :-). So, if we then switch over to the anonymous
>>>>>>> case, IMO, I don't believe the implementation should need to
>>>>>>>
>>>> change
>>>>
>>>>>>> w.r.t. the purpose of this URI.
>>>>>>> Here's what I don't understand. In the non-anon case an EPR
>>>>>>>
>>>> (address
>>>>
>>>>>>> + stuff) is used to target. In the anon case, so far as I can
>>>>>>>
>>>> tell,
>>>>
>>>>>>> there is nothing in WS-A to stop the same "full EPR" (address +
>>>>>>> stuff) be
>>>>>>>
>>
>>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Received on Wednesday, 9 August 2006 09:56:20 UTC