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 i056



Jacques,

Please see my comments embedded below.

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


Jacques Durand <JDurand@us.fujitsu.com> wrote on 11/17/2005 03:17:17 AM:

> If IT there is - and so far there is one -, I see it useful in the
> following case:
> - A Source application is using a sequence but is unable to
> close/terminate it properly (e.g. it dies prematurely, or simply it
> has not been designed to handle terminations for whatever reason.)
> In that case, IT allows for timely reclaiming of resources.


The RMD can deal with this administratively without advertising an IT.
Still, before the Sequence is unilaterally terminated by the RMD, wouldn't
you think that someone should investigate?

> - given this, I tend to think that IT-defined-by-RMS is actually
> more meaningful than IT-imposed-by-RMD: after all, only a Source app
> will know its frequency of service calls, and an IT appropriate for
> app X may not be for app Y.


How many times have you seen an application down for the better part
of a day for maintenance or otherwise? Would you want to have all of
the Sequence state for that application automagically reclaimed? I certainly
would not.

> - Sure this is no guarantee that the RMD will always respect that IT
> - we know an RMD can interrupt and fault any sequence anytime
> anyway. But if clients have a say on their IT, that allows an
> optimal use of RMD resources.


I disagree.

> (e.g. RMS A and RMS B with respective IT of 200s and 2000s, will be
> better served by a common RMD that can observe each one of these,
> rather than imposing IT=1100s to everyone, while not saving more
> resources. And the RMD can still put a cap.)

>  
> There seems to be an implicit expectation that protocol parameters,
> like DAs, are decided by RMD only. Although I can accept that DAs
> are defined on Dest side , I do believe that protocol parameters
> actually need be tuned as much on RMS capacity as on RMD capacity
> (even more for AI than IT). An RMS may not want to incur the
> overhead of getting too frequent acks because of its limited
> capacity and lax time requirements. But another RMS using the same
> RMD may need this. Why should they both be treated the same? RMS-
> based AIs would help an RMD to satisfy everyone for same resource cost.

> Jacques
> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Wednesday, November 16, 2005 11:26 AM
> To: Christopher B Ferris
> Cc: Yalcinalp, Umit; ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] Proposal for i056

> Chris,
> I'm struggling with trying to figure out why it is necessary to have
> IT(RMD) but not IT(RMS) (Bob's emails makes me think that we should
> perhaps get rid of both).
> Is it because:
> 1) RMS has the ability to send a AckRequested message, triggering an Ack
> from the RMD (regardless of AckInterval) and RMD does not have such a
> mechanism to trigger a message from RMS OR
> 2) that you think that since we already have AckInterval, RMS can adjust
> its IT accordingly OR
> 3) something else

> Thanks!
> -Anish
> --

> Christopher B Ferris wrote:
> >
> > -1
> >
> > See my previous post. I don't believe that there is any need for the RMS
> > to have an InactivityTimeout
> > nor for the RMD to have any knowledge of what the RMS's policy is with
> > regards to when the RMS
> > might become impatient and terminate a sequence for inactivity.
> >
> > I would propose that i056 be closed with no action.
> >
> > 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 05:12:27 PM:
> >
> >  > Issue 56:
> >  > We are making this proposal to address i056 [1] by building on our
> >  > previous proposals to resolve issues i022[2], i054[3], i055[4].
> >  > By exclusion of BTI and EB in the specification, the RMS does not
> >  > have to communicate with RMD for setting up the retransmission.
> >  > However, there is one thing that is of interest to the RMS which is
> >  > its own Inactivity Timeout. This IT may be specified to the RMD
> >  > within the boundaries of RMD's InactivityTimeout configuration on a
> >  > per sequence basis.
> >  > We think that the proposal we made for closing issue i055 [1] can be
> >  > used by RMS to communicate a specific IT for the sequence. The next
> >  > question is how RMS can specify the value of IT on a per sequence basis.
> >  > There are two ways to look at this problem.
> >  > (1) The communication of this parameter value is out of scope and
> >  > part of protocol preconditions which are glossed over in Line 230
> >  > and 231 of the WS-RM specification. This means that either this
> >  > configuration is done at some point in deployment, or there is
> >  > unspecified protocol between RMS and RMD that determines the
> >  > exchange of parameters prior to creating a sequence.
> >  > (2) Since this exchange is establishing the RMSs choice of IT on the
> >  > RMD side, it can be transmitted as part of the CreateSequence
> >  > message with the RMD. We note that this is a per sequence basis and
> >  > this optimization is of great value to RMS, instead of leaving it
> >  > out of scope.
> >  > SAP favors option (2) as there is a indeed cheap solution to support
> >  > the use case without changing the protocol with an optional simple
> > extension.
> >  > The proposal below does not change proprietory deployment decisions
> >  > and assumptions. It does not add additional message exchanges to the
> >  > protocol either. It is an optimization that can be used within the
> > protocol.
> >  > Add the following section to the  wsrmp specification (which may be
> >  > subject to further editorial modification)
> >  > {Section XX: Optimization for specifying parameters within WS-RM
> > Protocol
> >  > When RMS needs to specify the InactivityTimeout value for a
> >  > sequence, the selection of the inactivity timeout may be part of the
> >  > create sequence protocol as specified in Section 3.4 of [WS-RM]. RMS
> >  > MAY include the wsrmp:InactivityTimeout element as a child of wsrm:
> >  > CreateSequence element to designate the Inactivity Timeout value.
> >  > When specified as such, the maxValue and minValue attributes MUST
> >  > not be present.
> >  > <wsrm:CreateSequence ...>
> >  > <wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo>
> >  > <wsrm:Expires ...> xs:duration </wsrm:Expires> ?
> >  > ...
> >  > <wsrmp:InactivityTimeout>600000</wsrmp:InactivityTimeout>
> >  > </wsrm:CreateSequence>
> >  > This specific optimization may be rejected by the RMD and the RMD
> >  > MUST use the CreateSequenceResponse Fault as the response to the
> >  > Create Sequence request. In this case, the RMD MAY include the
> >  > specified InactivityTimeout element as part of the [Detail] to
> >  > indicate that the inactivity timeout value specified by RMS is not
> > valid.
> >  > }
> >  > We think that this is a very cheap solution which specifies an
> >  > optimization extension and RMD that do not support this extension
> >  > may reject the sequence with the specified methods that are already
> >  > within the protocol.
> >  > Note that there is a small issue with respect to the
> >  > CreateSequenceResponse Fault [5] that has been posted earlier that
> >  > can be easily fixed to enable addition of [Detail] content.
> >  > This optimization does NOT require changes to the existing protocol,
> >  > but uses existing extensibility mechanisms to allow  RMS to
> >  > configure the InactivityTimeout value.
> >  > Cheers,
> >  > --umit
> >  > [1]
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i056
> >  > [2] http://www.oasis-open.org/apps/org/workgroup/ws-
> >  > rx/email/archives/200511/msg00021.html
> >  > [3] http://www.oasis-open.org/apps/org/workgroup/ws-
> >  > rx/email/archives/200511/msg00023.html
> >  > [4] http://www.oasis-open.org/apps/org/workgroup/ws-
> >  > rx/email/archives/200511/msg00037.html
> >  > [5] http://www.oasis-open.org/apps/org/workgroup/ws-
> >  > rx/email/archives/200511/msg00017.html
> >  >
> >  > ----------------------
> >  > 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]