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