OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]