This will be i090 in
the next rev of the issue list, please change NEW ISSUE to i090 in subsequent
posts.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Friday, January 20, 2006
3:41 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [NEW ISSUE]
Use of offered sequences unclear in current spec
Eoghan,
I
purposely said "the right place" because I don't like the idea
of using
either replyTo or acksTo - nor do I think that the spec
should
choose one. If we examine the initial CS there is nothing
in the RM
spec at all that says where this message should go. The
RMS just
knows "the right place" - it might be the same EPR as the
AD or it
could be some RM manager - we don't know. I think the
response
sequence should be handled the same way - the RMD should
send any
possible CS to "the right place". It might be the replyTo
from one of
the requests, it might be the AcksTo EPR - we don't
know.
You're statement about the replyTo being short-lived w.r.t. the
entire
sequence (or sequences) is true. However, the same could
be said
about the acksTo EPR - it could live just for the duration
of the
original sequence - once the sequence goes away so could
the AcksTo
EPR. This would mean that the response sequence could
not use this
EPR any more for CS, Close or Terminate. Remember, the
response
sequence could be totally out of sync with the request one.
It might
live quite a bit longer (in most cases it should since the
responses
will be delivered after the requests) and in some extreme
cases its
possible that the response sequence might not even be
created
until after the request sequence is terminated.
This
all gets to my general complaint about offer - it hints at trying
to make some
kind of correlation between the request and response
sequences
that the RM spec just does not make. And by doing so it
leads to all
of these questions (valid questions when those hints
are there)
but the RM spec can not offer any answers, so IMO its
better to
remove this confusion by removing offer all together.
thanks,
-Doug
ps. in the
attached note I had to choose between acksTo and replyTo,
and I chose
replyTo for the response sequence CS because as I
stated above
the acksTo EPR could go away before the response
is sent but
the replyTo EPR would need to live at least long
enough to
get the reply, so sending the CS to this EPR should
always work.
Of course, sending a Close or Terminate to that
EPR might
not work but I'd probably choose to send those to the
last replyTo
EPR received since that one might have the best
chance of
still being alive. But this is all just speculation
and my own
opinion and shows, yet again, why offer is just
a
trouble-maker. :-)
"Glynn,
Eoghan" <eoghan.glynn@iona.com> wrote on 01/20/2006 04:27:31 PM:
>
>
> I think there's ambiguity around the endpoint
that an RMD should use for
> RM protocol messages other than the
CreateSequenceResponse.
>
> Putting it as a question, what precisely is
the scope of the endpoint
> specified in the <wsa:ReplyTo> of the
original CreateSequence message
> sent by the RMS?
>
> Under my reading of WS-Addressing, the
wsa:ReplyTo is intended only as
> the endpoint for the response message of the
SOAP request/response MEP
> (the CreateSequenceResponse in this case),
not also as the endpoint for
> an arbitrary set of "related"
messages.
>
> By related messages in this context, I'm
referring to other RM protocol
> messages that flow from RMD to RMS, e.g.:
> - outbound CreateSequence if the original
inbound CreateSequence doesn't
> contain an offer, and the RMD needs a new
sequence for application
> response messages
> - even if the original CreateSequence did
contain an offer, and this is
> accepted by the RMD, a TerminateSequence
message for the outbound
> sequence will need to be eventually sent by
the RMD
>
> It seems to me that of the two addresses
specified in the CreateSequence
> message (wsa:ReplyTo and wsrm:AcksTo),
assuming these are different and
> both non-anonymous, it's only the AcksTo that
should be assumed to be
> long-lived. Obviously an non-anonymous AcksTo
endpoint must have
> lifecycle comparable to that of the sequence,
as it must be capable of
> receiving ACKs throughout. The ReplyTo
endpoint on the other hand, may
> only exist for the extent of the CS/CSR
request/response MEP and
> thereafter the underlying transport resource
(e.g. HTTP listener, JMS
> destination etc.) may be released or put to
some other use.
>
> The reason this is a concern is that a client
transport could be
> designed to create client-side endpoints on
demand, and to associate
> these explicitly with a single
request/response MEP. These lightweight
> endpoints would obviously need simpler
lifecycle management, e.g. they
> could be pooled transiently, but wouldn't
necessarily need to be
> reconstituted after a client application
crash & restart. The AcksTo
> endpoint on the other hand would need be
managed differently by such a
> transport, specifically to exist for at least
the lifetime of the RM
> sequence, potentially encompassing client
restarts.
>
> There's also the question of where non-ACK RM
protocol messages may be
> sent by the RMD if the RMS specifies
different ReplyTos in the
> application messages within a single
sequence. May the RMD send for
> example to TerminateSequence to any of the
ReplyTos specified by the RMS
> within the sequence or just the ReplyTo
specified in the original
> CreateSequence?
>
> In the mail trail of the internal IBM
discussion on this subject, the
> argument is made that since the RMS just
sends the original
> CreateSequence to "the right place"
(i.e. the server-side endpoint that
> it will be invoking on), then the RMD should
also just send non-ACK
> protocol messages to the "right
place" (i.e. the client-side endpoint
> specified in the CreateSequence ReplyTo).
However I'd argue that from a
> transport lifecycle management point of view,
the cases are not
> symmetric. The server-side endpoint must be
long-lived as it forms part
> of the Service contract. However there's no
such implication that
> client-side endpoint specified in the ReplyTo
is part of contract that
> persists after the initial request/response
MEP is complete.
>
> So my view would be to take a broad
interpretation of AcksTo, as the
> endpoint for all destination->source RM
protocol messages (i.e.
> SequenceAcknowledgement for the inbound
sequence, CreateSequence,
> TerminateSequence for the corresponding
outbound sequence etc.)
>
> Comments?
>
> Regards,
> Eoghan Glynn
>
> Principal Engineer, IONA
Technologies.
>
>
> -----Original Message-----
> From: Daniel Millwood
[mailto:MILLWOOD@uk.ibm.com]
> Sent: 16 January 2006 15:05
> To: ws-rx@lists.oasis-open.org
> Subject: [ws-rx] [NEW ISSUE] Use of offered
sequences unclear in current
> spec
>
>
>
>
>
> Title: Use of offered sequences unclear in
current spec
>
> Description/Justification:
> When an RMS sends a CreateSequence that
includes an offer, the offer is
> meant to be an optimisation for creating a
sequence back from the RMD to
> the RMS. Closer inspection highlights
issues with this approach.
>
> The RMS knows the endpoint of the RMD and
sends it the CreateSequence
> message with the Offer, but the RMD is not
informed of the endpoint it
> should use to send protocol messages back to
the RMS for the offered
> sequence, or which AD endpoints the sequence
can be used for.
> Now, the RMD could assume that
> a) It should send
protocol messages to the same endpoint that it
> sends the CreateSequenceResponse message to
for the inbound sequence.
> b) It should send
protocol messages to the same endpoint that it
> sends Acks to for the inbound sequence
> c) It should send
protocol messages to the same endpoint that it
> would have done if it had created the
outbound sequence itself, which
> could be a, or b, or another endpoint as yet
unknown to it.
>
> but assumptions break interoperability and
the RMD still doesnt know
> which application messages can use the
sequence.
>
> As an optimisation, the offer should not
change the behaviour that would
> be observed without the optimisation.
>
> Lets take an example. Two applications
A and B use reliable messaging
> to query addresses from an address book
application at endpoint X. They
> both use the same RMS and share the same sequence,
and the RMD at
> endpoint X passes the messages onto the
address book app where addresses
> are queried and need to be sent back.
Application A sets a wsa:ReplyTo
> of Endpoint A
> for its replies. Application B sets a
wsa:ReplyTo of Endpoint B for
> its
> replies. Both these endpoints support
WSRM. When the replies are sent
> back, two sequences are established.
One to endpoint A and one to
> endpoint B.
>
> Now try and do the same with offer. The
RMS creates the outbound
> sequence and offers a sequence the other way.
Its accepted by the RMD.
> Now the application messages arrive at the
RMD, are processed by the
> address book app and the replies need to be
sent back to Endpoint A and
> Endpoint B.
> Which endpoint does the offered sequence
service? None, A, B, or both?
>
> Further more, since the spec doesn't limit
the offered sequence to just
> replies (it can be used for any msg going
from the RMD to the RMS) this
> problem is made even worse. Even before
the first application message
> from the RMS to the RMD is sent, the RMD
could have a message for the
> RMS. How does the RMD know whether or not the
wsa:To EPR in this message
> matches one of the possibly many RMS EPRs
that the offered sequence is
> for?
>
> The result is the creation of an offered
sequence where its not clear
> which application messages can use it, or
where to send the protocol
> messages.
>
> Target: core
>
> Type: design
>
> Proposal:
>
> Whilst there may be a subset of WSRM usecases
where offer could make
> sense, I believe it is too open to
interpretation to be interoperable.
> For the benefit of interoperability, it
should be removed from the spec.
>
> Delete from <wsrm:CreateSequence> in
line 274, through to 277 Delete
> lines 309 through to 330 Delete lines 369
through to 384 Delete line
> 1043 Delete line 1060 Delete lines 1090
through to 1106
>
> Thanks, Dan
>
> WS-Reliable Messaging Architect and Team Lead
IBM WebSphere Messaging
> Design and Development MP 211 Hursley Tel.
Internal 248617 Tel. External
> +44 1962 818617 Email. millwood@uk.ibm.com
>
>
>
>
>
>
Doug
>
>
Davis/Raleigh/IBM
>
>
@IBMUS
> To
>
Christopher B
>
>
12/01/2006 14:04
Ferris/Waltham/IBM@IBMUS
>
>
> cc
>
Daniel Millwood/UK/IBM@IBMGB,
>
>
Matthew Lovett/UK/IBM@IBMGB,
> Peter
>
Niblett/UK/IBM@IBMGB
>
>
> Subject
>
Re: Spec review comments(Document
>
>
link: Daniel Millwood)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> It might be worth trying to kill it :-)
Dan, would you like to write
> up
> the issue for it? I think just listing
out all of the various issues
> and questions raise by this thread could
convince the TC that it might
> be better to just remove it.
> -Doug
>
>
>
>
>
>
Christopher B
>
>
Ferris/Waltham/IB
>
>
M
> To
>
Doug Davis/Raleigh/IBM
>
>
01/12/2006 08:57
> cc
>
AM
Daniel Millwood/UK/IBM@IBMGB,
>
>
Matthew Lovett/UK/IBM@IBMGB,
> Peter
>
Niblett/UK/IBM@IBMGB
>
>
> Subject
>
Re: Spec review comments(Document
>
>
link: Doug Davis)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Offer is, as I argued many a time, a
premature optimization. I say nuke
> it, but 4 may be the most likely course of
action to be agreed by the
> TC.
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry
Architecture
> email: chrisfer@us.ibm.com
> blog:
http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
>
>
>
>
Doug
>
>
Davis/Raleigh/IBM
>
>
> To
>
01/12/2006 08:39 Daniel
Millwood/UK/IBM@IBMGB
>
>
AM
> cc
>
Christopher B
>
>
Ferris/Waltham/IBM@IBMUS, Matthew
>
>
Lovett/UK/IBM@IBMGB, Peter
>
>
Niblett/UK/IBM@IBMGB
>
>
> Subject
>
Re: Spec review comments(Document
>
>
link: Christopher B Ferris)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Dan,
> In that case I would assume that even
though the two wsa:ReplyTo EPRs
> are different they would both use the same
sequence for their responses
> - so I think its 'b'. This is one the
problems I have with offer - it
> tries to make some kind of associations that
are not really there. In
> this case its trying to associate ALL
responses with one particular
> sequence (the offered sequence). While
this may be the desired result
> at times, look at the pain
> its causing you :-) I have
a feeling you don't like the choice of
> 'b' -
> I suspect you'd prefer that the offered
sequence only be used when the
> wsa:ReplyTo matched some specific EPR (like
maybe the AcksTo -
> personally, if I were to try to make some
kind of statement of matching
> I think it should be the wsa:ReplyTo of the
CS and not the AcksTo - but
> we shouldn't be doing either).
> Hmmm, here's something interesting..I
just checked and the spec
> doesn't actually say that offer is for
replies. It says that offer is
> for messages going from the RMD to the RMS.
Since both the RMS and RMD
> can span multiple endpoints I think trying to
scope the offer down to
> just one EPR would be a mistake. So
then the question is "what is the
> RMS?" Since we don't require a
wsa:From (and WSA might even get rid of
> it), can we really treat the AcksTo EPR or
even the wsa:ReplyTo EPR as
> "the EPR of the RMS"? I don't think
so. The AcksTo EPR might be just
> for RM specific messages (like Acks) which
means no app-level messages
> would ever be targetted for it; sending just
messages that targeted to
> it would mean the offered
> sequence would never be used. sigh
> It seems like we need to clear this up
a bit. I see a couple of
> options:
> 1 - add text to offer to say that it is just
for replies (in the WSA
> sense) to messages sent on the original
sequence
> 2 - add text to help the RMD determine when
the it is sending messages
> to the RMS
> 3 - kill offer all together
> 4 - leave it as is - ambiguous
>
> I think '1' might be a bit too restrictive
but it would definately solve
> the problem.
> '2' sounds nice but it gets close to EPR
comparision and since an RMS
> can span multiple endpoints how can we ever
really say anything I like 3
> or 4. Killing it removes the issue.
While leaving it as is might leave
> things vague perhaps that the best way to go
since depending on how
> things are setup and implemented there are
just too many options to be
> more clear in the spec - and I do like the
idea of saving a message
> exchange.
> If I had to vote right now I'd probably
choose '4' but I'm not thrilled
> with it.
>
> thanks
> -Doug
>
>
>
>
>
>
Daniel
>
>
Millwood/UK/IBM@I
>
>
BMGB
> To
>
Doug Davis/Raleigh/IBM@IBMUS
>
>
01/12/2006 06:54
> cc
>
AM
Christopher B
>
>
Ferris/Waltham/IBM@IBMUS, Matthew
>
>
Lovett/UK/IBM@IBMGB, Peter
>
>
Niblett/UK/IBM@IBMGB
>
>
> Subject
>
Re: Spec review comments(Document
>
>
link: Doug Davis)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Doug,
>
> I a bit confused by your response on offer.
>
> Lets take an example that assumes no special
out of band agreements as
> to where to send WSRM protocol messages.
>
> I have two applications running in WAS, that
both access a remote
> address book webservice using WSRM. The
RM Source implementation uses a
> single sequence to send the messages from
both applications to the
> webservice at the RM Destination. App1
sets wsa:ReplyTo of its messages
> to Endpoint1.
> App2 sets wsa:ReplyTo of its messages to
Endpoint2.
>
> If I dont use offer, then when the addresses
are returned, I would
> expect the RM Destination to use two
sequences to send them:- One
> sequence to endpoint1, the second sequence to
endpoint2.
> If I do use offer, then what happens?
The RMD accepts an offered
> sequence but does not know where to send the
messages to. So does it
> a) not use it
> b) send both lots of
messages down it assuming that as they came
> down the same sequence, the responses can be
sent down the offered
> sequence.
> c) something else?
>
>
> Thanks, Dan
>
> WS-Reliable Messaging Architect and Team Lead
IBM WebSphere Messaging
> Design and Development MP 211 Hursley Tel.
Internal 248617 Tel. External
> +44 1962 818617 Email. millwood@uk.ibm.com
>
>
>
>
>
>
Doug
>
>
Davis/Raleigh/IBM
>
>
@IBMUS
> To
>
Daniel Millwood/UK/IBM@IBMGB
>
>
11/01/2006 18:27
> cc
>
Christopher B
>
>
Ferris/Waltham/IBM@IBMUS, Matthew
>
>
Lovett/UK/IBM@IBMGB
>
>
> Subject
>
Re: Spec review comments(Document
>
>
link: Daniel Millwood)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Comments in this pen.
> -Doug
>
>
>
>
>
>
Daniel
>
>
Millwood/UK/IBM@I
>
>
BMGB
> To
>
Doug Davis/Raleigh/IBM@IBMUS,
>
>
01/11/2006 07:49 Christopher B
>
>
AM
Ferris/Waltham/IBM@IBMUS, Matthew
>
>
Lovett/UK/IBM@IBMGB
>
>
> cc
>
>
>
> Subject
>
Spec review comments
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Having read through the latest spec level,
there are a couple of things
> I wanted to discuss.
>
> Sequence Expiry
>
> I dont like the fact that expiry could cause
a sequence to end without
> both the RMS and RMD knowing the state of the
sequence. If the RMD
> expires a sequence before the RMS, then the
RMS cant always know the
> final sequence state. The RMS cant
always proactively close the
> sequence, as there could be a network failure
stopping them
> communicating. Id prefer the spec
without expires in it.. I can see
> why messages might have a lifetime, but
> not the transport. (I realise we can
always use PT0S and that was the
> proposal in the current SDD - not exposing
expiry at all).
> <dug> this is a good point but I'm at a
loss at how we can fix it. Even
> if we say that when a sequence expires what
it really means is that its
> just Closed so that the RMS can still ask for
the ack state - how long
> should it remain like that? seems like
we still have the same problem
> that at some point the RMD will need to
forget about the sequence and at
> that point the RMS is stuck. </dug>
>
> Offer
>
> From discussions with Matt, we thought that
messages in an offered
> inbound sequence would be sent to the AcksTo
EPR of the outbound
> sequence. I cant find in the spec where
this is stated and wanted to
> confirm it. <dug> I don't believe
this is true. the AcksTo EPR is just
> where Acks are sent - there is no statement
in the spec that says where
> the offered inbound sequence messages (either
replies or RM ops) should
> go - nor should it.
> Replies go to the wsa:ReplyTo of each
individual message. RM messages
> go
> to "the right place" :-)
Just like the RM spec doesn't say where the
> CreateSequence or the TerminateSequence
should go for the outbound
> sequence it shouldn't say where they should
go for the reverse. </dug>
> Without an offered sequence, the
CreateSequence needed to establish a
> sequence for response msg A would be sent to
the ReplyTo EPR of the
> request msg A.
> <dug> and it won't be established
(probably) until the response is
> actually ready to be sent </dug> But
with the offer, request msg A has
> not been sent yet, so is the assumption that
the sequence is only used
> for response messages that need to be
targetted to the same EPR that
> acks will be sent too, or the same EPR that
the initial
> CreateSequenceResponse message uses?
> <dug> When the replies need to be sent
(and there was no offered
> sequence) then a CreateSequence would need to
be sent to "the right
> place". In most cases I would
assume that it would be the wsa:ReplyTo
> EPR but this isn't required if there's some
out of band agreement that
> it should go some place else. If there
was an offered sequence then
> there is no correlation that can be made
between the offered sequence
> and the AcksTo EPR. The RM spec says
that the AcksTo EPR is there for
> Acks - nothing else. Whether or not it
happens to match some other
> wsa:ReplyTo EPR is just a coincidence and
should not be used to
> determine whether or not the offered sequence
should be used. </dug>
>
> Secure Conversation
>
> Whats happening with this missing token?
We need a fix to this and it
> could provoke a lot of discussion so its
probably best to address it
> soon.
> <dug> I think my proposal to remove the
optionality of extensions should
> fix this </dug>
>
> Thanks, Dan
>
> WS-Reliable Messaging Architect and Team Lead
IBM WebSphere Messaging
> Design and Development MP 211 Hursley Tel.
Internal 248617 Tel. External
> +44 1962 818617 Email. millwood@uk.ibm.com
>
>
>
>
>
>
>
>
>
>
>
>