[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [bt-spec] re issue 108 - not for atoms (long email)
Bill, It meets my personal definition of editorial - making the text say differently/more clearly what it is intended to say anyway. I've added the sentence you suggest - it fits well. I'm less sure about the first paragraph - we seem to be equating the user with the client/terminator application element. Peter > -----Original Message----- > From: William Cox [mailto:william.cox@bea.com] > Sent: 01 May 2002 18:53 > To: Peter Furniss > Cc: William Z Pope; Mark Little; BT - spec > Subject: Re: [bt-spec] re issue 108 - not for atoms (long email) > > > Peter - > > It didn't become editorial until a few minutes ago... > > One suggestion (adds the second sentence): > > In BTP that is still the case if we work purely with atoms. > While an Atomic Coordinator knows its participants it cannot pick > and choose > among them. > In contrast, a Cohesive Terminator must have significant, > detailed knowledge and > visibility... > > bill cox > > Peter Furniss wrote: > > > Bill, > > > > I missed including this in 0.9.6, sorry. > > > > For 0.9.6.1 (as yet uncirculated - two drafts in a day would be a bit > > much), I've added your option one text into the lead-in > paragraph to the a), > > b) choice, making it two paragraphs: > > > > <quote> > > For this control of the Inferiors to be useful, the Terminator > application > > element will need to be able to associate particular parts of the > > application work with each Inferior. In a traditional > transaction system, > > users do not see participants, but they see services or objects. What > > participants are enlisted with a transaction on behalf of those > services and > > objects is not really of interest to the user. When it comes to > commit or > > rollback the transaction, it acts on the transaction and not on the > > individual participants. > > > > In BTP that is still the case if we work purely with atoms. In > contrast, a > > Cohesive Terminator must have significant, detailed knowledge > and visibility > > of both the identities of its inferiors and association of parts of the > > application work with each Inferior. The user must be able to > identify which > > participants to cancel/prepare/confirm.This identification can > be achieved > > by various means. Taking the case of an application element > controlling a > > Cohesion Composer: > > </quote> > > > > Is that ok with people ? > > > > Peter > > > > > -----Original Message----- > > > From: William Cox [mailto:william.cox@bea.com] > > > Sent: 30 April 2002 17:01 > > > To: William Z Pope; Peter Furniss; Mark Little > > > Cc: BT - spec > > > Subject: Re: [bt-spec] re issue 108 - not for atoms (long email) > > > > > > > > > Bill and Peter and Mark - > > > > > > I think this is almost entirely editorial. Repeating Mark's > original issue > > > (Issue 108): > > > > > > Basically, in a traditional transaction system > users don't see > > > participants they see > > > services or objects. What participants are enlisted with a > > > transaction on behalf of > > > those services and objects isn't really of interest to > > > the user. When > > > it comes to > > > commit or rollback the transaction, it acts on the > > > transaction and > > > not on the > > > individual participants. > > > > > > Now in BTP that's still the case if I work purely > with atoms. > > > However, in the > > > cohesive world, we're in a completely different ball > > > park . Now the > > > "user" has to > > > know explicitly what the participants are and how they > > > are tied to > > > services. > > > Otherwise, it can't use business logic to say "cancel > > > that insurance > > > quote and > > > prepare that one". How does the "user" get this > > > information when all > > > it typically sees > > > is the mechanisms to begin and end a cohesion? When an > > > invocation is > > > made within > > > the scope of a cohesion+atom then the user will have to > > > remember the > > > atom id. But > > > if the invocation is made within a top-level cohesion > > > (no atom) then > > > the user will > > > need to somehow keep track of what participants were > > > enrolled for > > > each service > > > invocation. Otherwise, if the user simply asks "what are the > > > participants" (e.g., via a > > > statuses message) it has no way of knowing that > > > participant X was for > > > service Y. > > > > > > Now if memory serves, the original proposed solution to > > > this was that > > > participant > > > identifiers could contain service identifying text, e.g., > > > "TaxiService:1234". OK, but > > > this service identification needs to be unique too > > > (obviously). If > > > participants can only > > > be used within atoms then this becomes less of an > > > issue, but I'm not > > > keen on that > > > restriction. > > > > > > The current specification doesn't mention this problem > > > at all and > > > paints a fairly rosey > > > picture that cohesions can be used out-of-the-box and > > > are going to > > > simplify our > > > lives. If I can't identify which participants to > > > cancel/prepare/confirm then this isn't > > > going to happen. So, I think whatever we decide (and > > > decide we must) > > > we need to > > > put appropriate text in the specification. Otherwise I > > > think people > > > will stick with > > > atoms or end up doing things in a proprietary > manner which then > > > breaks one of the > > > basic principles behind BTP (interoperability). > > > > > > > > > What I asked for was a clearer, simpler statement based on Mark's > > > first two > > > paragraphs--the proposed wording is bogged down in the > details of why, and > > > doesn't pre-summarize the what. This is a truth-in-advertizing issue. > > > > > > I'd like a simple, editorial addition of a separate paragraph > > > that says (OPTION > > > ONE or TWO) followed by the text in the suggested revision. > > > > > > OPTION ONE: > > > > > > "A Cohesive Terminator must have significant knowledge and > > > visibility of both > > > the identities of its inferiors and association of parts of the > > > application > > > work with each Inferior. For an Atom Coordinator, visibility of > > > the inferiors > > > is not required to conclude the transaction." > > > > > > > > > OPTION TWO: > > > > > > "In a traditional transaction system users don't see > participants they see > > > services or objects. What participants are enlisted with a > transaction on > > > behalf of those services and objects isn't really of interest to > > > the user. When > > > it comes to commit or rollback the transaction, it acts on the > > > transaction and > > > not on the individual participants. > > > > > > "In BTP that is still the case if we work purely with atoms. In > > > contrast, a > > > Cohesive Terminator must have significant, detailed knowledge and > > > visibility of > > > both the identities of its inferiors and association of parts of the > > > application work with each Inferior. The user must be able to > > > identify which > > > participants to cancel/prepare/confirm." > > > > > > SUMMARY: > > > > > > So what I'd like to see is a clear, distinct, summary statement as a > > > stand-alone paragraph (such as my suggestion above), followed > by the more > > > detailed explanations in the proposed change. > > > > > > I do believe that this is purely editorial, and can be taken > > > without a specific > > > vote - it brings out the issue that Mark brought up, but only > > > restates what is > > > less obvious in the mass of detailed explanation in the proposed > > > resolution. > > > > > > BTW, I continue to prefer (in opposition to Mark) the requirement that > > > participants are Atoms. This isn't the right place to > revisit that issue, > > > which is certainly not purely editorial. > > > > > > bill cox > > > > > > > > > > > > William Z Pope wrote: > > > > > > > Gents, > > > > We are down to the wire. The issue raised by Bill and > changes proposed > > > > by Peter are minor but not purely editorial. If you can > agree on text > > > > I'm willing to put it to a vote in tommorrow's conference call. > > > > > > > > =bill > > > > > > > > -----Original Message----- > > > > From: Peter Furniss [mailto:peter.furniss@choreology.com] > > > > Sent: Tuesday, April 30, 2002 7:27 AM > > > > To: William Cox > > > > Cc: BT - spec > > > > Subject: [bt-spec] re issue 108 - not for atoms (was RE: > > > > [business-transaction] Email vote - Issues 87 and 108 - > voting endsTues > > > > May 30) > > > > > > > > switched cc to BT-spec, as it's detail > > > > > > > > The immediate preceding sentence and the first paragraph of > > > this block are > > > > > > > > <quote> > > > > .... For an Atom Coordinator, visibility of the Inferiors is > > > useful but > > > > less important, since no selection can be made among which will > > > be in the > > > > confirm-set - for an Atom, all Inferiors are ipso facto > members of the > > > > confirm-set. > > > > > > > > For this control of the Inferiors to be useful, the Terminator > > > application > > > > element will need to be able to associate particular parts of the > > > > application work with each Inferior. This can be achieved by > > > various means. > > > > Taking the case of an application element controlling a > > > Cohesion Composer: > > > > </quote> > > > > > > > > Is it worth changing the first sentence of the paragraph to start: > > > > > > > > For this control of the Inferiors of a Cohesion Composer to be > > > useful ... > > > > > > > > or can you suggest some other change ? > > > > > > > > Peter > > > > > > > > > -----Original Message----- > > > > > From: William Cox [mailto:william.cox@bea.com] > > > > > Sent: 30 April 2002 04:56 > > > > > To: zpope@pobox.com > > > > > Cc: OASIS BTP (Main List) > > > > > Subject: Re: [business-transaction] Email vote - Issues > 87 and 108 - > > > > > voting endsTues May 30 > > > > > > > > > > > > > > > I vote YES on issue 87, with the following note: This proposed > > > > > conformance > > > > > statement is OK for a committee draft, but is not ready for the > > > > > next stage. > > > > > Specifying "sort of" conformance has no useful place. > > > > > > > > > > I vote YES on issue 108, with the following note: Text should be > > > > > added to clarify > > > > > that (as in the problem statement) this isn't an issue with Atoms. > > > > > > > > > > bill cox > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > To subscribe or unsubscribe from this elist use the subscription > > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > ---------------------------------------------------------------- > > > > To subscribe or unsubscribe from this elist use the subscription > > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC