[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)
Just to clarify, the text should not suggest that the atom coordinator cannot VIEW the participant list; obviously the atom coordinator cannot PICK and CHOOSE participants. bill cox William Cox wrote: > 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>
Attachment:
william.cox.vcf
Description: Card for William Cox
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC