ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] Proposal for i056
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 17 Nov 2005 08:00:10 -0500
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]