Re: [ws-rx] Anon / RM MakeConnection: [reply ep] = none

[Christopher B Ferris <chrisfer@us.ibm.com>]

+1

exactly

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

Paul Fremantle <paul@wso2.com> wrote on 08/09/2006
04:41:28 AM:

> 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
>