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


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


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