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

[John DeCarlo <jdecarlo@mitre.org>]

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