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

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

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