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

["Andrea Westerinen" <andreaw@cisco.com>]

John, On the second item, "definition" is really description of a unit
of work.  The interface must be able to support the
description/definition of the unit of work.

Andrea

-----Original Message-----
From: Shel Finkelstein [mailto:shel.finkelstein@sun.com] 
Sent: Friday, September 26, 2003 12:29 PM
To: John DeCarlo
Cc: Andrea Westerinen; wsdm@lists.oasis-open.org
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