Re: bt model - actors

[Mark Little <mcl@arjuna.com>]

> Naming A - Wednesday's discussion raised the point that though the
initiator
> would usually (and might always) trigger and possibly be involved in the
> termination, it was also imaginable to split this to another (application)
> component, so it might not always be right to say the initiator was the
> decider of the outcome. Given this proviso, initiator seems reasonable.

I agree. However, doesn't this also imply that the initiator is also the
"terminator"? Typically this may well be the case, but perhaps we are
missing another actor (terminator) which would allow an implementer to
distribute the business logic.

> Naming B - coordinator seems usable. Again there may be complications of a
> class/instance nature

Coordinator, or Cohesion Coordinator? Perhaps we don't need to be specific
to the type of coordinator, but given that transactions may be use as well
in an application, it could get confusing.

>
> C and D I'm less sure of.  I think "sub-coordinator" for D implies too
much
> about the internal workings  - the name refers to its role within the
> server-side (where it coordinates the application pieces involved in the
> business transaction ), whereas we probably ought to concentrate on its
role
> towards B.  "subordinate" perhaps ?

Subcoordinator implies an implementation that may only be relevant to a
specific model. Subordinate is OK, servant, subject?

>
> C is also a problem. I could live with participant (as in BEA, contra CH),
> in the sense that this bit of application participates in the cohesion,
> although it doesn't directly participate in the coordination protocol.

Again, isn't everything a participant? My worry with "participant" is that
it easily gets overloaded and overused, in much the same way we're already
overusing "transaction". However, service is also prone to
misinterpretation. As it is, participant seems the better of the two IMO.

> On the group / action / cohesion / business transaction thing, I think we
> again have some level of consensus on what the things are, but not what
> they're called.  There is a set of operations (X) that will all
(eventually)
> get the same decision, and there is a wider set of operations (Y) that
will
> not (necessarily) get the same decision but are at least dealt with as a
> reversible unit by A .

I'd prefer to see some flexibility here: why should the low-leve BTP be
concerned with reversibility at all? As we tried to show in the HP
submission, there are a wider range of protocols than just those that work
with compensations (no matter whether those compensations are forward or
backwards). What I'd like to see is something that reflects that flexibility
rather than ties us to a specific model. Reversibility could be seen as a
functional aspect of some business logic, just as consistency is. As long as
we're not assuming the BTP will somehow police the business transaction to
ensure that Y (an activity?) is reversible then maybe this isn't an issue.

> But I'm not quite clear now whether the "business
> transaction" in the original BEA proposal was considered atomic (in
> decision) - if participants can withdraw (or be evicted by the initiator
? -
> can't find this in the text, but I thought it was said at San Jose), then
> its not atomic (unless withdraw just meant read-only), and so would be
"Y".
>
> I'd like to (re-)suggest cohesion for "Y" - it's a new word in this area,
> with a sound of things that stick together a bit but can be pulled apart.

I think cohesion isn't a bad choice, since I'd be the first to admit that
terms like "atomic action" are over-used and can imply different things to
different people. The only other ideas I could come up with are: union and
contiguity

> For X, atomic group would be ok - emphasizing its key property. There need
> be no direct assumption as to how the operations in the atomic group are
> distributed.

Atomic unit? In distributed systems "group" may also imply a type of
communication infrastructure.

>
> "Business transaction", although good as a committee title, is, I still
> think, too ambiguous to be a wise use. It has much looser implications
> outside the transaction world (c.f. the use in EDI)

Business activity?

Mark.

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203