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

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

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

Attachment: william.cox.vcf
Description: Card for William Cox