RE: [business-transaction] FW: diagrams

[Sanjay Dalal <sanjay@bea.com>]

Peter,

 

Thanks for the reply and comments. I have made changes as per your comments.  Please see inline for other comments. Let me know if you have any suggestion for more diagrams too.

 

Wish you and BTPers a happy, healthy and peaceful new year.

 

thanks,

sanjay

 

----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: Tuesday, December 18, 2001 10:10 AM
To: OASIS BTP (Main List)
Subject: RE: [business-transaction] FW: diagrams

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. 

 

thanks. I hope these are also useful for primer apart from the specifications.

 

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 

 

done 

 

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

 

done 

 

BTP Actor relationships:

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

 

done

 

 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) 

 

done, added a comment about single Decider at a time

 

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

 

Sazi tells me that this was not resolved in f2f, esp. Composer-Participant and Composer-Sub-composer relationships. I understand your thinking too. I have kept the relationships at abstract level i.e. one can implement such that the same entity can play the roles of Composer and Coordinator. It means, that entity can directly talk to the Participant. In the same way Sub-coordinator and Sub-composer can be played by another entity. That way Composer-Coordinator entity can talk directly to Sub-composer-Sub-Coordinator entity.

 

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

 

done

 

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

 

Again, keeping things at abstract level, I have maintained separation between Participant and Service. One can implement both as the same entity and thus sub-c* can directly talk to Service.

 

Simple case

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

 

done, the full lifecycle of an atom is showed only in this diagram. i removed factory from other diagrams.

 

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. 

 

This is a bit difficult to show without taking an implementation view. I have drawn it with an implementation view in mind, e.g. Communicator. Have a look and let me know if that is okay. Suggestions are welcomed.

 

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 ? 

 

Changed it to show default cancel. Added comments. CANCELLED can also be sent to Terminator from Decider in reply to REQUEST_CONFIRM if there is no hazard, isn't it? May be you forgot what you wrote :)...see CANCELLED message description. 

 

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.

 

Alright, that must be old. Corrected.

 

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

 

Okay, I will modify these once relevant issues are resolve.  

 

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

specdiagrams.ppt