RE: [business-transaction] FW: diagrams

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

Sanjay,

 

Sorry I didn't comment on your diagrams earlier - I think they will be really helpful, and some at least will get into the intended model section.

 

few comments (treating 0.9 as "correct" - some of these things relate to unvoted issues)

 

"Supeiors", having Composer and Coordinator as derived from Decider might be good

 

"Infeirors" - Enrollers aren't really Inferiors - we've said (from way back) that the ENROL could be sent by the application (Service), or by the new Infeiror, or by something else that is neither, but friends with both (like an interceptor).

 

BTP Actor relationships:

  Initiator's have 1:n relations to Composers too.

 A Coordinator does not have a Superior:Infeiror relation to a Composer. There is only one Decider in a tree. (possibly they can evolve, but at anyone time , there is at most one Decider)

Composer and Coordinator have direct S:I relation to sub-coordinator, to sub-composer and to participant

Sub-composers and sub-coordinators can also be superior to each other and to themselves (and to Participants)

(last two are because any superior can be superior to any infeiror, and the superior can't tell the difference)

 

Participant is historically a bit tangled - there have sort of been two interpretations : a Participant is a leaf in the transaction tree, an Inferior that is no-one's Superior; and a Participant is an Inferior created by (or enrolled on behalf of) an applcation service, which Inferior may or may not be a superior (sub-c*), unknown of course to its own superior.  0.9.0.3 only uses Participant in the first sense, but means a Service has possible relationships with the sub-c's too.

 

Simple case

 - for full generality, there needs to be an Enroller. It is very boring :-)

 

optimized case - we can do even better than that, but it needs an extra role (which is actually the old communicator, which was dropped in 0.9 because specifying its existence restricted implementation options - the equivalent capability is now demanded of the implementation as a whole, not of a particular role). The service, participant sides sends back a response + CONTEXT_REPLY&ENROL& PREPARED group. Client side splits off the ENROL, sends it to Coordinator, gets back an ENROLLED, then sends app response up to client (initiator i guess) ENROLLED never goes down to Partiicpant.

 

participant timeout - not sure what PREPARED(CONFIRM/60/CANCEL) is.  But CANCELLED would come from the Participant to the Coordinator, before the REQUEST_CONFIRM.  Participant timeouts are threats, not promises (usually). Or is this the default cancel ?

 

cancel-contradiction - there isn't a CANCELLED/auto, just a CANCELLED, and if that gets there before the CONFIRM is sent, the next message is CONTRADICTION.  CONFIRMED/auto is needed to make sure some of the failure cases work out right.

 

Message IO ones are fine I think - except the f-t-f proposed resolution of issue 79 changes several of the Decider, Terminator ones

 

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX