Re: abstract message set and another state table revision

[Sanjay Dalal <sanjay@bea.com>]

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
>