[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] [i090] Use of offered sequences unclear in current spec
Matt Maybe I misunderstood Dan's scenario. I assumed that A made the offer. I think we should leave the spec as is but clarify the text. I also agree that the interop scenarios are important because we the specification does very little to define patterns for request response usage. Paul Matthew Lovett wrote: > > Hi Paul, > > I'm not sure that I agree with all of your reasoning. You said: > > "In fact, one implementation (Apache Sandesha) will treat the scenario > you describe below as you desire. In other words two sequences are used > for responses. For messages to A the initial offered sequence will be > used and for messages to B a new sequence will be created." > > Here, you seem to be stating that A is aware of the sequence, and that > B is not. What if the messages were assigned to the sequence in the > other order? (Perfectly possible given Dan's original scenario.) I > assume you would then state that B was aware of the sequence, and A is > not. That's a bit of a contradiction. > > I see 3 useful ways out: > > a) State that both A and B are aware of the sequence, in which case > you don't need to establish new Sequences, though you are free to if > you choose. To aid interop we should say something like "When using a > wsa:replyTo for application messages assigned to a Sequence, the RMD > accessible at the replyTo endpoint MUST be aware of any Offered > sequence". I don't like that much, and perhaps a SHOULD works better > than a MUST, but equally, it damages interoperation. We seem to be > making the RM layer care about the interaction pattern (e.g. > WS-Addressing options) more than it has to. Yuck! > > b) Assume that neither A or B are aware of the sequence, which reduces > the applicability of Offered sequences to the anonymous replyTo. > > c) Leave the spec as is, or possibly add prose to warn implementations > that there is more than one interpretation here and give some > guidance. With or without new text, the interop scenarios that we are > building then become a de facto standard. > > Talking to Dan's original issue, I agree that there are different > interpretations of the current spec, and that some clarification would > aid interop. At the same time, I really don't want to start getting > into meta-issues about message exchange patterns, or documenting the > expected composition of WS-A and WS-RM. > > Matt > > > > > > *Paul Fremantle <paul@wso2.com>* > > 23/01/2006 16:10 > > > To > Daniel Millwood/UK/IBM@IBMGB > cc > ws-rx@lists.oasis-open.org > Subject > Re: [ws-rx] [i090] Use of offered sequences unclear in current spec > > > > > > > > > > Daniel > > The assignment of messages to sequences is an application level concern, > and one that neither the submitted specification nor the latest work of > the TC covers. This seems to be making assumptions about the mapping > between messages and sequences that are not in the specification. > > In particular you seem to be assuming that the return sequence is > decided based on the ReplyTo address. Another different assumption would > be that the return sequence is decided based on the incoming sequence or > a combination of the incoming sequence plus the ReplyTo address. I don't > believe it is part of role of this specification to decide this. I think > that that is an implementation specific issue. > > In fact, one implementation (Apache Sandesha) will treat the scenario > you describe below as you desire. In other words two sequences are used > for responses. For messages to A the initial offered sequence will be > used and for messages to B a new sequence will be created. > > I think Offer is a useful feature and I do not believe that removing it > helps make the semantics of your scenario any simpler. In either case > the responding agent has to make decisions about which sequence to use > for each message, and there are multiple options. > > Paul > > > > Daniel Millwood wrote: > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > -- > > Paul Fremantle > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > http://bloglines.com/blog/paulfremantle > paul@wso2.com > > "Oxygenating the Web Service Platform", www.wso2.com > > -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle paul@wso2.com "Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]