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:]
Sent: Friday, September 26, 2003 12:29 PM
To: John DeCarlo
Cc: Andrea Westerinen;
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:
> voice: 703-883-7116
> fax: 703-883-3383
> DISA cube: 703-882-0593
