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

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

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


Subject: RE: [business-transaction] FW: diagrams



At 11:47 PM 12/30/01 -0800, Sanjay Dalal wrote:
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
 

Although, I understand what you mean by "derived", I do not think using an implementation approach (e.g object oriented design, uml etc.) is appropriate, perhaps we should clarify what we mean is not exactly what the UML diagram indicates - just a suggestion.

"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
 

Although I am not concerned on this, I am not sure what you mean by an enroller is not an inferior.. by definition, when an 'entity' enrolls in to a transaction it is definitely not a superior... so it should be an inferior... Is there any 'entity' that enrolls to transaction and it is superior?
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

What is the relationship between Composer and Coordinator?
 
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.
 

We have discussed the relationship between composer and participant at the f2f meeting. I have pointed out that Composer having a direct relationship to a participant is new in the current spec, and somehow invalidates the role of coordinator. Peter and I have given some examples of our understanding on this issue...

Although, I don't belive we have a final decision on the issue, it was an interesting discussion, we may be much closer to a final decision then it seems...

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


Sazi Temel
'                               
bea Systems Inc.        e-mail: sazi.temel@bea.com      
140 Allen Road          phone: (1) 908 580 3123
Liberty Corner, NJ 07938        web:
http://www.bea.com






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


Powered by eList eXpress LLC