[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] New Proposal for i056
Counter proposal for closure: Delete IT Rationale IT is evil -bob From: Yalcinalp, Umit
[mailto:umit.yalcinalp@sap.com] Folks,
After
some internal debate, this is our new position and new proposal for i056. This
is an amendement to the proposal we are making before for this issue [1]. As
you may know for i055, we are withdrawing our original proposal for defining
ranges of IT values for the RMD, but we would like to retain that IT specified
in the policy document that is attached to WSDL applies to RMD as indicated to
an email sent earlier today. Rationale
for New Proposal for i056: For
RMS, the two values that the RMD's policy should specify will be of interest IT
and AI and may require runtime adjustment. We
consider two use cases: (a)
The configuration of RMD's IT affects the rate that RMS has to send the
messages. This is helpful when RMS has prior knowledge of the
application's rate of generating messages. Although,
an application's rate of generating messages is an application concern, it
affects the rate of an application to be able to send messages to an RMS. These
application level concerns may be dictated by higher level standards or
specifications in the spec, such as RozettaNet PIPs or simply prior knowledge
that exists in the application in a vendor specific setting. A
mismatch would occur when the applications rate of sending messages is slower
than the IT specified by the RMD. In order to avoid sequence closure, RMS
may try to retain a "sequence" activity with the priori knowledge
that its own rate of sending messages is actually going to be less than the IT
specified by the RMD. In
order to accommodate this use case, either the RMS has to send keep-alive
messages or specify the IT on the RMD side. We
do prefer the latter since we do not want to architect keep-alive messages. In
order to adjust its rate of sending messages, we believe that the RMS has to
configure the RMD's IT so that RMD does not timeout before the RMS has the
chance to send the next message in the sequence. (b)
The configuration of RMD's AI affects the way RMS will reclaim its resources as
AI affects the rate of acknowledgements being received from the RMS side.
Hence, RMS may be interested in configuring the RMD's AI parameter, at least
within the boundaries of the range. (The spec has to assert clearly that AI is
a range). Hence
if the RMS needs to have a AI which is less than the AI specifies by the RMD,
it should be able to specify it accordingly. Basically, internal IT which is
private to RMS must align with the RMD(AI). If
this alignment does not hold, the RMS may be claiming resources too early, and
hence needs to adjust its IT to match with RMD (AI). In order to accommodate
this, RMS should be able to transmit its own IT value to match the RMD(AI) and
hence SET the value of RMD(AI) value. We
think that both of these use cases are essential for configuration of RMS and
RMD and may be accomplished in a very simple manner. Further, we do not think
that specifying the values of IT or AI need to be ranges, but "simple
values" as currently specified in the specification. Therefore, this is a
change from our previous proposal as well. Here
is the proposed text: {Section
XX: Optimization for specifying parameters within WS-RM Protocol When
RMS needs to specify the InactivityTimeout value for a sequence or specify the
AcknowledgementInterval value for a sequence, the selection of the inactivity
timeout {or Acknowledgement Interval} may be part of the create sequence
protocol as specified in Section 3.4 of [WS-RM]. RMS MAY include the
wsrmp:InactivityTimeout element {or the wsrmp:AcknowledgementInterval element}
as a child of wsrm:CreateSequence element to designate the Inactivity Timeout
{or Acknowledgement Interval} value. <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 {or
AcknowledgementInterval} element(s) as part of the [Detail] to indicate that
the 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
[2] that has been posted earlier that can be easily fixed to enable addition of
[Detail] content. Regards,
--umit
[1]
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i056
----------------------
Dr.
Umit Yalcinalp |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]