RE: [ws-rx] i075 new proposal

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

I would add two items to your list of justifications:

4) Communicating these operational parameters in the
CreateSequenceResponse allows applications that are not using WSDL (for
whatever reason) to determine their value.

5) Removing these parameters from WSRM-Policy eliminates the possibility
of contention between different policies set on endpoints that share the
same sequence. I don't think it is possible for endpoints to have
conflicts about whether or not they support WSRM. If an endpoint doesn't
support WSRM it can't be a part of any sequence so (from the perspective
of WSRM) there is nothing to disagree about.

I think we need to separate the idea of presenting ack interval and max
message at runtime from the idea of removing them from WS-RM Policy.
Logically there are four combinations:

(1)    in-policy,  not-in-runtime:  current spec
(2) not-in-policy, in-runtime:      this proposal
(3)    in-policy,  in-runtime:      Anish's proposal(?)
(4) not-in-policy, not-in-runtime:  Bob Freund(?)

Do we have proposals for (3) and (4)?

- g

> -----Original Message-----
> From: Paul Fremantle [mailto:paul@wso2.com] 
> Sent: Thursday, January 05, 2006 4:44 AM
> To: wsrx
> Subject: [ws-rx] i075 new proposal
> 
> Based on the discussion at the F2F I believe that we should 
> remove AcknowledgementInterval and MaxMessageNumber from WSRM 
> Policy and make them parts of the CreateSequenceResponse message.
> 
> The justification is this:
> 
> 1) Firstly these are actually parameters of a sequence, not policy.
> 2) The issue of which values are in use on a given sequence 
> is much clearer if they are associated with the CS/CSR
> 3) It seems highly unlikely that these would be used in the 
> choice of a service. There might very very very occaisionally 
> be situations where a Source would reject the values. In that 
> case the overhead is marginally higher (a CS/CSR followed by 
> a terminate sequence versus looking at a Policy). However, I 
> think this scenario is so unlikely that it is irrelevant 
> compared to the benefits of simplification.
> 
> I also believe that this helps shape up the dependency on the 
> WS-Policy
> Framework: it means that none of the operational aspects of 
> the protocol are dependent on WS-Policy. The dependency is 
> only there if you need to find out whether a service supports 
> WSRM. (which by the way I *do* consider to be a "policy" in 
> the sense of the WS-Policy model).
> 
> So as an amendment to the previous proposal (thanks Anish), 
> here is the new proposal.
> 
> Modification to the WSRM-Policy spec
> -----
> Section 2.1 add new text to follow line 109:
> "When a RM Destination provides RM services for more than one 
> endpoint it is RECOMMENDED that all the endpoints should have 
> the same values for RM Policy parameters. If the RM Policies 
> are not the same then the RM Policy parameters in effect for 
> each Sequence is governed by the endpoint that was used for 
> the <wsrm:CreateSequence> message."
> -----
> Remove lines 113-114 (AI and MM parameters) Remove lines 
> 125-134 (AI and MM parameters) Remove line 164 (AI example) 
> Remove text: "Line (13) indicates the RM Destination may 
> buffer acknowledgements for up to two-tenths of a second."
> 
> ------
> Modifications to the WSRM spec:
> After line 302 insert:
> 
> <wsrm:AcknowledgementInterval Milliseconds="xs:unsignedLong" ... /> ?
> <wsrm:MaxMessageNumber Number="xs:unsignedLong" ... /> ?
> 
> After line 326 Insert:
> /wsrm:CreateSequenceResponse/wsrm:AcknowledgementInterval
> This element, if present, specifies the duration after which 
> the RM Destination will transmit an acknowledgement. If 
> omitted, there is no implied value.
> /wsrm:CreateSequenceResponse/wsrm:AcknowledgementInterval/@Mil
liseconds
> The acknowledgement interval, specified in milliseconds.
> /wsrm:CreateSequenceResponse/wsrm:MaxMessageNumber
> This element, if present, specifies the maximum message 
> number that the RM Destination will accept. If omitted, the 
> default value of the maximum unsigned long will be assumed.
> /wsrmp:RMAssertion/wsrm:MaxMessageNumber/@Number
> The maximum message number.
> -----
> 
> Paul
> 
> -- 
> 
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> 
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
> 
> "Oxygenating the Web Service Platform", www.wso2.com
> 
>