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] New Proposal for i056


Title: New Proposal for i056

Counter proposal for closure:

Delete IT

Rationale

IT is evil

-bob

 


From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Thursday, November 17, 2005 11:37 AM
To: wsrx
Subject: [ws-rx] New Proposal for i056

 

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 ...>
<wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo>
<wsrm:Expires ...> xs:duration </wsrm:Expires> ?

<wsrmp:InactivityTimeout Milliseconds=600000/>
<wsrmp:AcknowledgementInterval Milliseconds=200000/>
</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
[2] http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml

----------------------

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]