RE: [ws-rx] NEW ISSUE: Target of RM Assertion parameters are confusing withrespect to how they are specified and attached

[Ashok Malhotra <ashok.malhotra@oracle.com>]

Title: NEW ISSUE: Target of RM Assertion parameters are confusing with respect to how they are specified and attached

I have a question of clarification.  Can the values of these parameters change during

the life of a reliable sequence?

All the best, Ashok

 

---

From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Tuesday, October 18, 2005 3:43 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] NEW ISSUE: Target of RM Assertion parameters are confusing with respect to how they are specified and attached

Title: Target of RM Assertion parameters are confusing with respect to how they are specified and attached

Description:

Currently the WS-RM Policy Assertion describes four distinctive parameters in Section 2.1 [1]: Base Retransmission Interval, Exponential Backoff, Inactivity Timeout and Acknowledgement Interval. Further, these parameters are scoped with respect to two distinct roles as summarized below:

RMS:
-- Base Retransmission Interval (BRI)
-- Exponential Backoff (EB)
-- Inactivity Timeout (IT)

RMD:
-- Inactivity Timeout (IT)
-- Acknowledgement Interval (AI)

Clearly there is a separation between which roles these assertions would apply in the specification.  However, the definition of the RM assertion includes ALL of the parameters regardless of the role.  This causes a problem in interpreting what is being intended in Section 2.3 [1] which describes attachment of the policy.

From the perspective of WSDL, the service is always described from the perspective of the provider and lists the requirements of the provider. Hence the WS-Policy attachment of RM Assertion will appear to apply to RMD alone. If we were to take this assumption into consideration, semantics of supplying all the 4 parameters in a RM Assertion is not very clear.

There are two possible interpretations:

(1) Although, there are two separate roles of RMS and RMD, it is the RMD who owns the WSDL and dictates all these parameters. This means the BRI, EB although are defined for RMS, are not really defined by RMS. RMS in essence has no control over these parameters.  Note that this interpretation appears to contradict the Lines 112-113 and 117-119.

(2) All the parameters appearing in a WSDL for RMD are applicable for the RMD only. However each parameter is scoped to request and/or response. For example, the BRI, EB and IT will apply when the RMD acts in a sender role (for a response message), and only the IT and AI apply in the RMD’s receiver role (for a request message). RMS is free to use its own parameters. Note that this interpretation appears to conflict with the example provided in Section 2.3, lines  225-227 where RMS is mentioned, but it is not stated that the RMD will be in the role of sender when these parameters apply.

It is not clear which of the above interpretations is correct. Further, different sections of the specification are in conflict with each other regardless of the interpretation assumed as illustrated above.

Justification:

It should be clear in the specification where the assertion parameters apply and how. Currently, there are two distinct and possible interpretations leading to confusion. Further, not making the clarification affects resolution of issues that pertain to attachment of policy in general since it is not obvious how the RM Assertion parameters apply with respect to the roles that are acknowledged in the specification.

Target: policy

Type: design

Proposal:

Clarify and explicitly state in the specification that each role manages its own parameters. Update the example to include in the WSDL only the parameters that are applicable to RMD: IT and AI. In addition, clarify whether the parameters that apply to RMS may be used within the content of RM Assertions and when.

Detailed proposal: TBD.

Related Issues: i021, i006

References:

[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/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