OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: terminology

Included a sketch that shows possible actors and their communication in a business transaction that I was trying to explain on todays conf call.

I think we have the addressing (explicit/implicit or both?, and how the service detects that it is in a transaction and how it communicates with its local service manager) and the actors names and their roles shown in the figure. The names that I have used in the figure are just because I need to name them!


At 01:24 PM 4/10/01 +0100, Mark Little wrote:
Last night we discussed some terminology again, and (amongst the 3 of us who were there) seemed to reach some agreement. I said I'd email the results of the discussion:

(i) there definitely seems to be a need for a terminator actor as well as an initiator. In many cases the initiator and terminator may well be colocated, but that need not be the case (e.g., I begin a BT, but pass control of it to someone else to determine whether it should commit or rollback in my absence).

(ii) the idea of a conductor instead of coordinator was discussed. The conductor term isn't used in this domain as far as we can see, and may help to remove some confusion, especially if people use an ACID transaction system in collaboration with the BTP.

(iii) rather than distinguish between a participant who is a subordinate conductor, we should probably just say that that's an implementation choice for the participant, i.e., as far as the conductor is concerned it sends a prepare message, and what the recipient participant does to come up with the return value is up to it.

I am not sure if the conductor is a good term for this...
(iv) cohesion sounded OK to those involved, though I think Keith was going to see if he could come up with something else.

what about using the term business transaction? I think it is widely accepted that business gradations are not 2PC/ACID transactions...
(v) atomic group is overloaded terminology too, tending to imply group communication using, say, atomic multicast or virtual synchrony. Atomic unit?
atomic steps, unit of work...?

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC