bt model - actors

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

Following a message from Pal, I've been looking at some of the "actor"
concepts that have been kicking around, comparing in particular the original
BEA submission [BEA] and Alastair's diagram we used in the discussion on
Wednesday [CH]. (I've copied them into the attached document).

Avoiding worrying about what else they show, both have 4 players, which seem
to correspond - which I think derives from the basic two dimensions that
split things - application versus system and here versus there. So we have
(labelled arbitrarily for this discussion)

A - an application piece at the originating, client-side system  (initiator
in both)

B - a system (btp-implementing) piece supporting A ( main coordinator in
BEA, coordinator in CH)

C - an application piece at the server/service side ( participant in BEA,
service in CH)

D - a system piece supporting C (sub-coordinator in BEA, participant in CH)


However, some of this alignment gets a bit unglued if we challenge them with
what happens when there are multiple operations between the same two
parties - that is there are two quite separate invocations, in the same
cohesion on the same service or on two services that happen to be colocated.
In BEA, this would be another participant C that is enlisted with the same
subcoordinator D ; in CH (not obvious from this diagram), this would be
regarded be a different (invocation of) service C creating another
participant D. However, this distinction is driven by different assumptions
about the underlying protocol passing between the system pieces - the
actor's names and properties have been affected by the protocol and
interfaces they use.

It's probably best to forget about that aspect for now, (but just be aware
that if, e.g. two registration messages pass between the same two boxes,
there are two registrants).

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.

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

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 ?

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.

---

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

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.

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


Peter

------------------------------------------------
Peter Furniss
Choreology Ltd

email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
13 Austin Friars, London EC2N 2JX









------------------------------------------------
Peter Furniss
Choreology Ltd

email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
13 Austin Friars, London EC2N 2JX

twodiagrams.doc