RE: [wsdm] Thoughts on "transaction" wording for MUWS

["Jeff Bohren" <jbohren@opennetwork.com>]

Andrea,
 
That seems reasonable from a requirements standpoint. From a practical standpoint I don't see what this will accomplish. In practice it will allways be the service that determines if atomicity is supported. It is also very difficult for there to be any meaninful relationship between an atomic transaction on the client (of which the call to the service is a part), and the atomic transaction on the service.
 
A much simpler approach is for the service to report success or failure, where failure could have caused the service transaction to rollback, and the client does what ever transaction handling it is capable of. This was the approach we took in SPML. The SPML client can send a collaction of actions. The SPML service may or may not support atomic transactions. If there is a failure and the service can not rollback, the client gets status of which actions succeeded and which failed. If the service can rollback (and chooses to do so), the client get the status back that all actions failed. We chose not to address what should happen if some of the actions succeed and some failed, leaving that decision up to the client developers.
 
If there is really going to be interoperability, the a client will probably have to make calls to services that do not support rollbacks. From a interoperability viewpoint it is much safer to assume that none do and act accordingly.
 
Since the service will really define atomicity, there are really only three outcomes for a set of actions:
 
1) All actions succeeded, so it doesn't matter if transactions are supported by the service or not.
2) All actions in a set failed, because of rollback or because the first action failed and the service decided to fail the entire set. In this case it also doesn't matter if transactions are supported by the service.
3) Some actions failed and some succeeded because atomicity was not supported.  In this case it also doesn't matter if transactions are supported by the service, because the did not help for anything.
 
Having said all that, I have no objections to stating the requirements like this. I just don't think it will be used in practice.
 
Jeff Bohren
OpenNetwork Technologies

	-----Original Message----- 
	From: Andrea Westerinen [mailto:andreaw@cisco.com] 
	Sent: Mon 9/29/2003 11:34 PM 
	To: Jeff Bohren; wsdm@lists.oasis-open.org 
	Cc: 
	Subject: RE: [wsdm] Thoughts on "transaction" wording for MUWS
	
	
	Jeff, The rewording that Shel and I did, tried to clarify these points.  Also, I did mean to distinguish between collections of actions and transactions (hence the commit/rollback terminology that morphed into atomic transactions with Shel's help).  Note, however, that atomic transactions are NOT specified as MUST.    
	 
	I believe that a client DOES want (and wants to be aware of) transactional processing, at various points in managing a service.  If a client needs atomicity, then it should be definable.  If the service can't support that, so be it.  An error needs to be returned.  However, I believe that a client will want to take advantage of atomic transactions (in certain circumstances) versus having to dealing with error scenarios and "best effort" rollback on their own.
	 
	Andrea
	 
	-----Original Message-----
	From: Jeff Bohren [mailto:jbohren@opennetwork.com] 
	Sent: Thursday, September 25, 2003 11:19 AM
	To: wsdm@lists.oasis-open.org
	Subject: RE: [wsdm] Thoughts on "transaction" wording for MUWS
	
	
	From the discussions so for it seems we are not really talking about transactions. What we really mean is a batch of operations that may be invoked on a MUWS service. It that context the term "Collections on Management Actions" makes sense to me, but I would leave off the "and Transactions". 
	 
	I would also leave out the notion of explicit commit or rollback support. A  MUWS service may or may not use transactions when processing a batch of operations (i.e. Collection of Management Actions), but that should not be an issue the MUWS client needs to be aware of.
	 
	Use of the terms "Transaction", "Commit", or "Rollback" is going to interpreted as meaning we are requiring transaction support rather than batch operation support. I don't normally get hung up on wording, but these are extremely loaded terms.
	 
	 
	Jeff Bohren
	Product Architect
	OpenNetwork Technologies, Inc
	 

		-----Original Message-----
		From: Andrea Westerinen [mailto:andreaw@cisco.com] 
		Sent: Thursday, September 25, 2003 11:52 AM
		To: 'Shel Finkelstein'; wsdm@lists.oasis-open.org
		Subject: [wsdm] Thoughts on "transaction" wording for MUWS
		
		
		My apologies for being so late on this.  And, Shel did not get a chance to review.
		 
		Section Heading - Collections of Management Actions and Transactions
		 
		[TRANS.001] MUST support the definition of a "unit of work" that consists of multiple actions against a single device
		[TRANS.002] MAY support the definition of a "unit of work" that consists of multiple actions against multiple devices
		[TRANS.003] MUST report status, errors or lack of support for execution of collection of actions against one or more devices
		[TRANS.004] MAY support actions of commit and rollback of multiple actions against one or more devices
		[TRANS.005] SHOULD support time-out of the "unit of work" consisting of multiple actions against one or more devices
		[TRANS.006] SHOULD support user-defined preferences related to the execution of the "unit of work" consisting of multiple actions against one or more devices. 
		    [TRANS.006.1] User preferences SHOULD include whether the desired behavior is "all or nothing"
		 
		Andrea