[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Issue i024
Doug, Ok, that (sharing of inactivity TO, ack interval etc) makes sense. If the two sides do not know each other's inactivity timeout and have ack interval/retransmission interval out of synch with the inactivity TO, it may lead to Sequences unilaterally aborting prematurely. That brings another (orthogonal) question: how does one keep a sequence alive when there aren't any messages that are being sent (for a long period of time) currently, but will be in the future. Typically, protocols have a ping/keep-alive mechanism to do so. On the RMS's side, the AckRequested can serve this purpose. What does a RMD do to ping the RMS (when there aren't any new message being sent)? Or is it expected that the RMS is responsible for retransmitting old messages/sending AckRequested within the inactivity period of the RMD (when no new msgs are available to be sent)? (back to the topic) I can see some usecases where dynamic timeout/retransmission/ack interval makes sense (i.e., including the information in the CreateSequence/CreateSequenceResponse). For example, a service that communicates with resource constrained mobile devices as well as non-resource constrained devices. I also tend to think that once we agree on a typical/suggested pattern after examining the interactions, the solution would not be too difficult. -Anish -- Doug Davis wrote: > > Anish, > I've always thought they were meant to be shared since it could > influence > how the other side interacted with the RM endpoint. For example, based on > the inactivity timeout advertized by an RMD, an RMS may choose to modify > its retry interval to make sure the sequence doesn't timeout. The thing > I've > wondered about is whether these should be static value (meaning they appear > on the WSDL and probably won't change), or are they more dynamic and might > change on each sequence (perhaps based on the RMS's identity). If they are > more dynamic then perhaps they should be part of the CreateSequence > handshake > just like some people have suggested the DA in use be part of the > CreateSeqResponse. > It might be useful to examine the complete set of interactions between > an RMS and > an RMD - starting with the first MDEX Get through to the > CreateSequenceResponse - > stating what bit of data we expect each message to carry and how that is > supposed to > be used (can't remember off hand if one of Gil's use-cases fully > describes this but I > have a vague recollection that one might come close). I have a feeling > that if we could > agree on the typical (or even 'suggested') interaction pattern we expect > people to > follow that coming up with a solution will be easy and will probably > cover all of these > issues (and include Chris' issue 9 too). But I haven't done the legwork > yet to know > for sure - just guessing here. > thanks > -Doug > > > > *Anish Karmarkar <Anish.Karmarkar@oracle.com>* > > 09/15/2005 02:27 AM > > > To > Doug Davis/Raleigh/IBM@IBMUS > cc > ashok.malhotra@oracle.com, ws-rx@lists.oasis-open.org > Subject > Re: [ws-rx] Issue i024 > > > > > > > > > Doug, > > I think issues 6 and 9 make issue 24 more relevant/important and I can > see at least a solution that covers all three. It certainly makes sense > to think about them together and perhaps even find a single/common solution. > > One question though I have about the existing RM policy assertions is: > are they (inactivity timeout, base retransmission interval, ack > interval) meant to be shared between RMS and RMD or are they meant as > configuration information for implementations? By shared, I mean shared > by both the RMS and RMD (and not just attached in a WSDL document). > > Thanks. > > -Anish > -- > > Doug Davis wrote: > > > > What's the relationship between this issue and issues 6, 9? They seem > > very similar - almost like 6 and 9 are a subset of 24. Would it make > > sense to try to find a single/common solution that covers all? > > thanks, > > -Doug > > > > > > Ashok Malhotra <ashok.malhotra@oracle.com> wrote on 09/14/2005 > 03:43:40 PM: > > > > > This is in response to Sanjay's note asking for a proposal for issue > > i024. > > > In this case, though, what we are asking for may be a clarification > > and not a change. > > > > > > The WS-RM Policy spec defines a RM assertion. It also specifies how > > this assertion > > > may be attached to WSDL. What is does not specify is the motivation > > behind the > > > assertion, how it is used and the messages it applies to. We would > > like this clarified. > > > > > > It is clear that the RM assertion is an 'informational assertion' in > > that it is a > > > property of the sequence and not a property of the messages in the > > sequence. As such, > > > it does not make sense for each message to include this information. > > > > > > Second, policy information is meant to be conveyed by one party in a > > conversation to > > > the other. In this case, the assertion seems to specify > > implementation parameters > > > that may be private to the RMS or the RMD. If so, it does not need > > to be part of the > > > specification. > > > > > > If, indeed, the RM assertion is to be conveyed from the RMS to the > > RMD it can be > > > done as a header in the CreateSequence message. The RMD can respond > > with a header > > > in the CreateSequenceResponse by agreeing, disagreeing or making a > > counter proposal. > > > > > > If the RM assertion has to be conveyed from the RMD to the RMS, this > > has to be done > > > before the CreateSequence message and requires a new protocol element. > > > > > > All the best, Ashok > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]