[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Proposal for i055
It seems to me that it might be worthwhile to talk about various ways
the RMS/RMD can keep the Sequence alive when there are no new messages.
I'll file a new issue for this. I don't envision the spec saying
anything normatively, but merely mention a few ways implementors can
keep the Sequence alive.
I don't have connectivity right now, but I hope the WSRMP spec does not
define IT in terms of *new* messages in the Sequence. If so, this might
be another issue.
-Anish
--
Doug Davis wrote:
>
> Anish,
> That was my assumption but it might need to be stated in the spec.
> -Doug
>
>
>
> *Anish Karmarkar <Anish.Karmarkar@oracle.com>*
>
> 11/03/2005 02:16 PM
>
>
> To
> Christopher B Ferris/Waltham/IBM@IBMUS
> cc
> ws-rx@lists.oasis-open.org
> Subject
> Re: [ws-rx] Proposal for i055
>
>
>
>
>
>
>
>
> Slightly related question, thought about implementation rather
> than the
> spec:
>
> It is possible that in a Sequence there may be periods where there isn't
> any activity (no new messages are being sent by the RMS), but the
> RMS/RMD do not want to terminate the Sequence, because there is more
> stuff coming down the pipe later.
>
> An obvious way to send 'keep-alive' messages is to send req-for-ack
> message on the RMS side and for the RMD to resend an ack. These are very
> small messages (with only one header). Is this what implementors are
> thinking off? Are there better ways?
>
> Thx.
>
> -Anish
> --
>
> Christopher B Ferris wrote:
> >
> > -1
> >
> > I don't see a need for the InactivityTimeout to apply to the RMS. It is
> > free to discard/terminate
> > a Sequence whenever it wants to do so.
> > I am preparing an alternate
> > resolution to i055, but
> > we're still circling the wagons internally.
> >
> > Cheers,
> >
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > blog: http://webpages.charter.net/chrisfer/blog.html
> > phone: +1 508 377 9295
> >
> > "Yalcinalp, Umit" <umit.yalcinalp@sap.com> wrote on 11/02/2005
> 04:48:57 PM:
> >
> > > Issue i055:
> > > This proposal is to resolve i055[1] based on the clarification that
> > > we propose for resolution of Issue i054 [2].
> > > We observe that although the InactivityTimeout should be specified
> > > by the RMD in the policy, it should be possible for RMS to align its
> > > own inactivity timeout with respect to RMDs specification of the
> > timeout.
> > > In this regard, we propose to modify the definition of
> > > InactivityTimeout which is currently a single value. Instead, we
> > > propose that RMD should specify the InactivityTimeout to be a range
> > > of values, with a lower and upper bound as well as a default value.
> > > We think that this change will allow RMS to be able to configure the
> > > IT to be able to send messages in an appropriate interval to the
> > > RMD, still complying with the configuration of the RMD. How this
> > > particular configuration may be addressed will be the subject of a
> > > subsequent message as it is a separate issue (i056 [3])
> > > We propose to add the following two attributes to the definition of
> > > InactivityTimeout at Line 158 [4] and move the specified value as
> > > the content value of the element as follows:
> > > Remove the lines 154-155 [4]
> > > {
> > > /wsrmp:RMAssertion/wsrm:InactivityTimeout/@Milliseconds
> > > The inactivity timeout duration, specified in milliseconds.
> > > }
> > > Replace the lines 151-153 with
> > > {/wsrmp:RMAssertion/wsrm:InactivityTimeout
> > > A parameter that specifies a period of inactivity for a Sequence. If
> > > omitted, there is no
> > > implied value. The value of the element indicates the default
> > > inactivity timeout duration in milliseconds.
> > > }
> > > Add the lines:
> > > {/wsrmp:RMAssertion/wsrm:InactivityTimeout/@minValue
> > > A parameter that specifies a minimum value of inactivity for a
> > > Sequence. If omitted, there is no
> > > implied value. This attribute is only present when the @maxValue is
> > present.
> > > /wsrmp:RMAssertion/wsrm:InactivityTimeout/@maxValue
> > > A parameter that specifies a maximum value of inactivity for a
> > > Sequence. If omitted, there is no
> > > implied value.
> > > }
> > > You probably noticed that we are also pointing out a small
> > > problem/anomaly in the specification, where the values are specified
> > > by attributes (i.e @Milliseconds attribute) instead of element
> > > content. We propose that the definition of the InactivityTimeout to
> > > be changed so that it should be using the value of the element
> > > instead of the attribute. Further, minValue and maxValue attributes
> > > are used to define a range.
> > > If the TC wishes to retain the usage of attribute values instead of
> > > element content as proposed, it may be retained along with minValue
> > > and maxValue proposal we are making. However, we really want to know
> > > the rationale for which the values are specified as attributes
> > > instead of elements contrary to the general practice used today with
> > XML.
> > >
> > > Thanks.
> > > --umit
> > > [1]
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i055
> > > [2]
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i054
> > > [3]
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i056
> > > [4] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.
> > > php/14986/wsrmp-1.1-spec-wd-01.pdf
> > >
> > > ----------------------
> > > Dr. Umit Yalcinalp
> > > Standards Architect
> > > NetWeaver Industry Standards
> > > SAP Labs, LLC
> > > umit.yalcinalp@sap.com
> > > Tel: (650) 320-3095
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]