[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]