[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] Thoughts on "transaction" wording for MUWS
I am sure that we will discuss these points at some length :-). Andrea -----Original Message----- From: John DeCarlo [mailto:jdecarlo@mitre.org] Sent: Friday, September 26, 2003 1:10 PM To: Andrea Westerinen Cc: 'Shel Finkelstein'; wsdm@lists.oasis-open.org Subject: Re: [wsdm] Thoughts on "transaction" wording for MUWS 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:jdecarlo@mitre.org] > Sent: Friday, September 26, 2003 12:36 PM > To: Shel Finkelstein > Cc: Andrea Westerinen; wsdm@lists.oasis-open.org > 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]