Re: [bt-spec] re issue 108 - not for atoms (long email)

[William Cox <william.cox@bea.com>]

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