RE: Issue 6472 Proposal - WS-Eventing EventSourceUnableToProcess: Distinguish temporary v permanent failure

Hi Geoff
Yes, I agree that clearer wording would help here (actually I just 
cut-and-paste from ws-addressing :o) ). 
thanks
Katy



From:
Geoff Bullen <Geoff.Bullen@microsoft.com>
To:
Katy Warr/UK/IBM@IBMGB
Cc:
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Date:
02/02/2009 21:18
Subject:
RE: Issue 6472 Proposal - WS-Eventing EventSourceUnableToProcess: 
Distinguish  temporary v permanent failure



Katy,
Suggestion one looks like it might work the best, but the text should be 
explicit that there is no guarantee that the operation will work after 
that period.  Perhaps some wording like:
 
/wse:RetryAfter 
  This element (whose content is of type xs:unsignedLong) is a suggested 
minimum duration in milliseconds to wait before retransmitting the 
message. This element is a hint only, and there is no guarantee that the 
operation will succeed if retried after the specified duration. Omission 
of this element indicates that a retry is never likely to succeed.
 
-Geoff
 
From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Katy Warr
Sent: Friday, January 30, 2009 4:25 AM
To: public-ws-resource-access@w3.org
Subject: Issue 6472 Proposal - WS-Eventing EventSourceUnableToProcess: 
Distinguish temporary v permanent failure
 

Here are a couple of proposed solutions for 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6472. 

I've added the text changes that I think would be required for both 
proposals as concern was raised on the last call regarding the amount of 
change required for this issue. 

thanks 
Katy 

Suggestion 1: Introduction of "retryAfter" 
------------------------------------------ 

Introduce an optional retryAfter element  (in homage to ws-addressing soap 
;o) ) in the detail of EventSourceUnableToProcess and UnableToRenew. 
Absence of the retryAfter element would mean: don't bother to retry.   

This suggestion has the advantage that it reuses an existing pattern from 
another spec.  It also is more useful to the client as it gives some 
indication as to when it might be worth retrying.  This may be useful (for 
example) if an event source had too many subscribers and was therefore 
being taken off-line for a while. 

Here's an example fault using this suggestion: 

 <S:Fault> 
   <S:Code> 
     <S:Value> 
        S:Sender 
     </S:Value> 
     <S:Subcode> 
        <S:Value>wse:EventSourceUnableToProcess</S:Value> 
     </S:Subcode> 
   </S:Code> 
   <S:Reason> 
     <S:Text xml:lang="en">The event source has too many 
subscribers</S:Text> 
   </S:Reason> 
   <S:Detail> 
     <wse:RetryAfter>1000</wse:RetryAfter> 
   </S:Detail>     
 </S:Fault> 


Required Changes to the specification: 

1) Add to Section 5:Faults 

Fault detail elements: 

The following element is used to convey additional information in the 
faults. 
Retry After 
  The following describes the <wse:RetryAfter> element: 
  /wse:RetryAfter 
  This element (whose content is of type xs:unsignedLong) is a suggested 
minimum duration in milliseconds to wait before retransmitting the 
message. Omission of this element indicates that a retry is never likely 
to succeed. 
  /wse:RetryAfter/@{any} 
  Optional extensibility attributes that do not affect processing. 

2) Add "<wsa:RetryAfter> Optional" to the [Detail] section of 5.6 
EventSourceUnableToProcess and 5.7 UnableToRenew 


Suggestion 2: PermanentFailure Subsubcode 
----------------------------------------- 

A simpler, but less powerful solution, would be to enable an event source 
to set a subsubcode in the fault to indicate that the error was permanent. 
 Absence of this subsubcode would indicate to clients that it may be worth 
retrying the request. 

Here's an example fault using this suggestion: 

  <S:Fault> 
   <S:Code> 
     <S:Value> 
        S:Sender 
     </S:Value> 
     <S:Subcode> 
        <S:Value>wse:EventSourceUnableToProcess</S:Value> 
        <S:Subcode>wse:PermanentFailure</S:Subcode> 
     </S:Subcode> 
   </S:Code> 
   <S:Reason> 
     <S:Text xml:lang="en">The endpoint is no longer acting as an event 
source</S:Text> 
   </S:Reason> 

  </S:Fault> 

Required Changes to the specification: 

1) Section 5 Faults. 
In the table following "The definitions of faults use the following 
properties:" 
change the text in the subcode row from 
"The fault subcode" 
to 
"The fault subcode (with optional nested subcode)". 

2)Change [subcode] row of section of 5.6 EventSourceUnableToProcess and 
5.7 UnableToRenew to: 

wse:EventSourceUnableToProcess 
The EventSourceUnableToProcess subcode can be further narrowed in scope by 
use of an optional nested subcode <wse:PermanentFailure>. Inclusion of 
this nested subcode indicates that a retry is never likely to succeed. 



 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 












Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU