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:
>>voice: 703-883-7116
>>fax: 703-883-3383
>>DISA cube: 703-882-0593
>
>
--
John DeCarlo, The MITRE Corporation, My Views Are My Own
email:
voice: 703-883-7116
fax: 703-883-3383
DISA cube: 703-882-0593
