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

[Shel Finkelstein <shel.finkelstein@sun.com>]

Okay by me, but pen is in Andrea's hands if she sees email in time.  --Shel

John DeCarlo wrote:
> 
> 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