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

["Andrea Westerinen" <andreaw@cisco.com>]

John, Could we go with the original wording and discuss further limiting
it, since your rewording combines the concepts of describing the unit of
work and executing it.  And, the broader concepts are better, if they
can be agreed upon.

Andrea

-----Original Message-----
From: John DeCarlo [mailto:jdecarlo@mitre.org] 
Sent: Friday, September 26, 2003 12:36 PM
To: Shel Finkelstein
Cc: Andrea Westerinen; wsdm@lists.oasis-open.org
Subject: Re: [wsdm] Thoughts on "transaction" wording for MUWS



Here are some suggestions:

[TRANS.001] The Manageability Interface MUST support, as part of the 
management information, a "unit of work" that consists of multiple 
actions against a single resource.

[TRANS.002] The Manageability Interface MUST support, as part of the 
management information, a "unit of work" that consists of the same 
action applied to multiple resources that the manageable resource knows 
about.

What do you think?

Shel Finkelstein wrote:

> My immediate thoughts on your questions; I'll defer to Andrea if she 
> joins in too:
> 
> 1. I probably wasn't around for the scope discussion, but you take 
> great minutes, so you must be correct.  I'd pick B over A.
> 
> 2. Manageable resource doesn't support definition; requirement was 
> that the spec define units of work with these characteristics.  This 
> leads to the subsequent requirements.  But I'm easy; can you suggest 
> better wording?
> 
> Thanks.
> 
> Shel
> 
> 
> John DeCarlo wrote:
> 
>>Shel,
>>
>>Thanks.
>>
>>1.  I thought we had agreed that the part of transaction management 
>>that was in scope was getting information from one manageable resource

>>through the manageability interface.
>>
>>Thus we need some clarification wherever it says "multiple resources".
>>
>>I lean toward one of these two options:
>>
>>A) "multiple resources within the manageable resource"
>>
>>or
>>
>>B) "multiple resources that the manageable resource has information 
>>about."
>>
>>AND
>>
>>2.  How can the manageability interface support a definition???? 
>>Perhaps the manageability interface must just support identification.
>>
>>Shel Finkelstein wrote:
>>
>>
>>>John, here's current version; Andrea and I are very close to 
>>>convergence, but she should have last word on some edits I made.  I'm

>>>sending on to you now only because you requested latest iteration for

>>>inclusion before you left for the day.
>>>
>>>Shel
>>>
>>>------------------------------------------------------------------
>>>
>>>Section Heading - Collections of Management Actions and Transactions
>>>
>>>NOTE:  This section may affect and be affected by requirements for 
>>>long-running business transactions/business processes and workflows.
>>>
>>>[TRANS.001] MUST support the definition of a "unit of work" that 
>>>consists of multiple actions against a single resource [TRANS.002] 
>>>MUST support the definition of a "unit of work" that consists of the 
>>>same action applied to multiple resources [TRANS.003] MUST support 
>>>the definition of a "unit of work" that consists of multiple actions 
>>>against multiple resources
>>>
>>>[TRANS.004] MAY support execution of a unit of work against multiple 
>>>resources [TRANS.004.1] MUST support execution of a unit of work 
>>>against a single resource
>>>[TRANS.005] MUST support idempotence for units of work against one or
more
>>>resources
>>>* NOTE 1:  Should this also be a requirement for single actions
against a
>>>resource?
>>>* NOTE 2:  If units of work are not supported, this requirement is
met
>>>trivially
>>>[TRANS.006] MUST report status, errors or lack of support for
execution of a
>>>unit of work against one or more resources
>>>
>>>[TRANS.007] SHOULD support requests for asynchronous execution of 
>>>actions against one or more resources, within a unit of work, with 
>>>(idempotent) callbacks
>>>* NOTE 7.1:  How are singleton asynchronous resource requests called 
>>>out?
>>>
>>>[TRANS.008] MAY support requests for atomic (all-or-nothing) 
>>>execution of a unit of work against one or more resources 
>>>[TRANS.008.1] If asynchronous actions are supported (TRANS.007) and 
>>>asynchronous actions occur in at atomic unit of work, then eventual 
>>>execution of the asynchronous actions MUST be guaranteed if the 
>>>atomic unit of work is completed, with ensuing consequent callbacks 
>>>also guaranteed [TRANS.009] MUST report status, errors or lack of 
>>>support for atomic execution of a unit of work against one or more 
>>>resources
>>>
>>>[TRANS.010] MAY allow changes for partially completed units of work 
>>>to be externally visible [TRANS.010.1] If atomic units of work are 
>>>supported (TRANS.008), then changes due to the actions in the unit of

>>>work SHOULD NOT be externally visible until the unit of work has 
>>>completed
>>>
>>>[TRANS.011] MUST support requests for rollback of atomic units of 
>>>works that have not completed [TRANS.012] MUST support status for 
>>>rollback requests for atomic units of work
>>>[TRANS.013] SHOULD support time-out for a unit of work consisting of
>>>multiple actions against one or more resources, with callback that
may
>>>result in a rollback request for that unit of work
>>>
>>
>>--
>>
>>John DeCarlo, The MITRE Corporation, My Views Are My Own
>>email:      jdecarlo@mitre.org
>>voice:      703-883-7116
>>fax:        703-883-3383
>>DISA cube:  703-882-0593
> 
> 

-- 

John DeCarlo, The MITRE Corporation, My Views Are My Own
email:      jdecarlo@mitre.org
voice:      703-883-7116
fax:        703-883-3383
DISA cube:  703-882-0593