[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 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