[tm-rg] Reminder: Next meeting 25 May 05, Use Case doc and Report

[Haugen Robert]

 >   Please do not wait to 25 May to comment (although of course your
comments then will be most welcome).   
 
Sorry about timing.   The following is, I think, an improvement over the
original text on pages 7 and 8:
 
"Failing according to a reported pattern" in this case might mean that
business rules would be applied to the reported failures, for example:  

*	
	 if one supplier did not respond, but the demand was satisfied
anyway, it doesn't matter;  
*	
	 if the demand was not satisfied, the interaction with the
supplier might be retried, or tried in some other way; 
*	
	 if a particular supplier has a service-level contract with the
client company which was violated by its failure, a penalty might be
applied.

Specific Transactional Requirements:

 

R1        Non-atomic outcomes:  the client may not want the whole
transaction to fail if one or more participants fail.

R2        Ability to apply business rules to participant failures, which
may mean that the client must know the identity of each participant.

 

The workaround for the absence of  distributed application-level
transactions may be lots of error-handling code.  Thus the benefit of
using a transaction is a reduction in error handling code and greater
certainty as to whether a successful outcome has been achieved for a
particular request.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/tm-rg/attachments/20050525/5d259da9/attachment.html