[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsdm] Thoughts on "transaction" wording for MUWS
OK, I also changed "MUST report status ..." to "MUST enable reporting of status ..." in two requirements. Otherwise I left them as is. BTW, after much thought this afternoon, rereading what you and Shel agreed to, and with the change to "description/definition", I think this is very good. Thanks. Andrea Westerinen wrote: > 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]