OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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