[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: abstract message set and another state table revision
Peter, I read about messages. Overall, this is a good document. 1. General comment: Type is missing as column header in descriptions of several messages. 2. CONTEXT - Is it really a message? I thought it is not. CONTEXT travels with a BTP message or an Application message but it is not a message in itself. 3. The same argument applies to SUPERIOR_STATE and INFERIOR_STATE. Is there any reason why STATE(or STATUS?)_REQUEST/RESPONSE is not used? STATE_REQUEST and STATE_RESPONSE can carry xxx_STATE information. 4. A lot of the states of Inferior described in 4.4.20 seems also to be the states of Superior (4.4.16) e.g. confirming, canceling, preparing, etc. Are they not? IMHO they are. I can see Coordinator (a superior) having some of these states too. BTW, Is the verdict out regarding what should a Coordinator be considered in general, a superior or an inferior :)? I know these roles are played by Coordinator in different scenarios (based on what kind of BT is used, cohesion or atomic). So, it is hard to describe it as a superior globally. I see a contradiction in the following statements in Alastair's document regarding this. Here are these statement... A Cohesion or Cohesive Business Transaction is an example of a persistent Terminator. Any number of Atom Coordinators can be enrolled as its Inferiors. Superior: For example, both a Coordinator and a Composer are Superiors. 5. 4.4.13 CANCELLED NOTE - A CANCELLED message arriving before a CANCELLED message is sent, .... Is this correct? See you on Wednesday... regards, sanjay ----- Original Message ----- From: "Peter Furniss" <peter.furniss@choreology.com> To: "BTP - mainlist" <business-transaction@lists.oasis-open.org> Sent: Friday, July 20, 2001 12:31 PM Subject: abstract message set and another state table revision > As it says in the subject > > > State table changes since yesterday: > > Some alignments with new names in abstract msg set. > > Dropped SUP_STATE/preparing, since the normal rule is to send the last > message if you can, and PREPARE is good enough. > > Added send and receive of *_STATE/inaccessible to make sure that worked > > > > Peter > > ------------------------------------------ > Peter Furniss > Technical Director, Choreology Ltd > email: peter.furniss@choreology.com > phone: +44 20 7670 1679 > direct: +44 20 7670 1783 > mobile: 07951 536168 > 13 Austin Friars, London EC2N 2JX >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC