RE: terminology

[Sazi Temel <sazi.temel@bea.com>]

Included corrected (sequence and system) diagrams.

--Sazi

At 09:40 PM 4/18/01 -0700, Sazi Temel wrote:
>>>> 
> At 03:33 PM 4/18/01 +0100, Peter Furniss wrote: 
> >>>>
> > Sazi,
> > > 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! 
> > >   
> > >
> > >
> > > Useful (and colourful :-) diagram. Couple of points (using your terminology)
> > >
> > >
> > > The intent of "group" (assuming this is the atomic unit, or whatever) as I had seen it was that it was a unit of decision (i.e. that it there is a single yes/no decision made that is to be applied to elements that have ever been part of the unit.)  Within the "business transaction", it may happen (dependent on results, time etc.) that one or other of the groups is cancelled or withdraws, while the other completes - but within each, all operations go the same way.
> > >
> > >
> > > The consequence of this is that the server sites don't need to know of the existence of the "business transaction" as a whole (for this purpose) - they only need to know which "group" the operation is part of. In your example this would require SM3 to register with both groups,since it may get different answers (e.g. if S1 says NO, GM1 will be cancelled, but the BT could complete with GM2 alone (if the application/BTM decided that was appropriate)
> > >   
> <<<<
> Correct, SM3 should also register with GM2. (Corrected the diagram according to!)
> >>>>
> > > The situation would be different if you had another operation (S2 ) in G1 that also accessed service S2 (currently unused, and I assume in some fairly close relationship to service S1).
> <<<<
> Yes, the services in the same circle are somehow related services. They may be related for local requirements or other reasons. And each related group of services have one SM as seen in the figure. Amongst other SMs may monitor the health (detect inconsistent requests etc., note that this may require that S implemented in a way that SM can monitor -dip in- the S) of the group it is responsible, it should also handle registering with multiple GMs.
> >>>>
> > >  In this case the fact that it will be subject to the same atomic decision means that it can be allowed to combine with S1, and share its data (i.e. the second to arrive can rightly use the tentatively final results of the first, subject to the essentially *local* requirement that the two operations don't bury their updates.) SM1 would still only register with GM1 once, and would apply the GM1 decision to both. 
> <<<<
> Correct.
> >>>>
> > > If S2 were part of G2 however, the second one could not know whether first will commit. (If, instead of S1, you send a second operation to S3, from G2, then the fact that S3 and S3' are in the same group means the two operations can be treated as parts of the same (ACID) transaction - e.g. using xa_start(TMJOIN) to the resource manager))
> > >   
> <<<<
> I am not sure if I understood this...
> >>>>
> > > (the possibility of data sharing is a bit different if SM1, S1, S2 are using a lock-free, local compensation approach to "undo". 
> <<<<
> [Just to remind .. SM is not a service, only S is service] If S1 and S2 are sharing data, it is more delicate situation... thats why I think, one of the task of the SM should be monitoring the services to detect any type of violations (some thing like a DB will detect problems in a similar situation) There may be need for an interface between SM and S..
> >>>>
> > > In that case, the second operation is in exactly the same position as a completely unrelated operation. Since the implementor has assumed that the compensating undo, and any possible operation from anywhere are sufficiently robust that they won't mess each other up, it is presumably safe to let the second operation use the first ones results.
> <<<<
> Yes.
> >>>>
> > > --Sazi
> > >
> > > 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...
> > > >>>> 
> > >   
> > > I'm with those who think it very unwise to use "transaction" (whatever the qualification) as the name for a precise thing in this. Some listeners will think we mean ACID, some will think we mean colloboration, some will think we mean operation.  (Cohesion - think of the glue on post-it's :-)
> <<<<
> I think many of us are using Cohesion as de facto term... 
> >>>>
> > > (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...? 
> > > >>>>
> > >   
> > > I'd be happy with atomic unit (though it's possibly tautologous). "unit of work" is LU6.2-speak for 2pc/ACID transaction.
> <<<<
> ...
> >>>>
> > > 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 
> <<<<
>
> --Sazi
<<<<

Protocol_seq.pdf

Protocol_sys.pdf