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] Proposal for i055


The value of IT at the RMD would specify how long the RMD should wait for the next reliable message (argh!) to show up before giving up on an open sequence. Where as I believe it is the RMS who is in a better position to specify the time interval between the different messages it intends to send out. So although the IT parameter would apply to the RMD, it makes sense to allow the RMS to ask for a particular value for IT (to be used by the RMD), IMHO.
 
Thanks,
Sanjay


From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Thursday, Nov 03, 2005 9:03 AM
To: Christopher B Ferris; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposal for i055

Chris,
 
I think you missed the point and I possibly did not clearify it.
 
We are proposing to include IT for RMD for Policy Attachment.
RMS may have its private IT, but what is specified and applies to the endpoint applies to RMD.
 
The interval definition we are proposing applies to RMD.
This information may be used in a private or optimized way by RMS, which is a separate decision.
 
Hopefully, this email makes it clearer.
 
--umit
 


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, Nov 03, 2005 8:54 AM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] Proposal for i055


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