Andrea,
I agree with your suggestion to leave it the original way you posted,
especially for the first two, since we need to be able to describe units
of work.
I just changed "definition" to "description/definition". As you
mentioned in an earlier message.
Thanks.
Andrea Westerinen wrote:
> 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:]
> Sent: Friday, September 26, 2003 12:36 PM
> To: Shel Finkelstein
> Cc: Andrea Westerinen;
> 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:
>>>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
