ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: Anon / RM MakeConnection: [reply ep] = none
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: Alastair Green <alastair.green@choreology.com>
- Date: Wed, 9 Aug 2006 08:45:27 -0500
Alastair,
Please see my comments below.
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/09/2006
03:24:35 AM:
> 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.
See my previous missives on this matter. "no
response expected" does not
mean only a transport-level ack. The SOAP Request
Optional Response MEP that
is being worked on in the XMLP WG as part of the SOAP1.2
PER, to address
the WS-Addressing WG's concerns regarding the lack
of a SOAP MEP for one-way
messages, makes it clear that a SOAP envelope MAY
be carried in the HTTP
response, but that it need NOT be the "response"
message to the "request"
message, as that would be sent to the [reply endpoint]
(if any response
is expected at the application level).
>
> 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).
Point? MC is handled in the RM middleware.
>
> 3. RM would be asking WS-A implementations to stop natural, generic
> behaviours 1. and 2., and become aware of RM.
I disagree.
>
> 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
No, it doesn't if there is no application-level response.
A one-way
WSDL operation has no application-level response.
Whether the [reply
endpoint] is anon, none or anything else is irrelevant
to whether
there is an application-level response.
> 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".
We've been through this. We have agreed upon what
is currently specified.
No change is needed.
>
> 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]