- From: Alastair Green <alastair.green@choreology.com>
- Date: Wed, 09 Aug 2006 10:33:12 +0100
- To: Paul Fremantle <paul@wso2.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
- Message-ID: <44D9ABD8.5010301@choreology.com>
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?
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
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
>>>>>>
>
>
Received on Wednesday, 9 August 2006 09:34:35 UTC