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

[Peter Furniss <peter.furniss@choreology.com>]

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