Re: [ws-rx] Proposal for i055

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

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