RE: abstract message set and another state table revision

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

Doubt if anyone will see this before we meet - I didn't see it till now.


> I read about messages. Overall, this is a good document.

thanks !

> 1. General comment: Type is missing as column header in descriptions of
> several messages.

Alastair is merging the abstract message bit with the main document and
catching many of these editorials.

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

I think it's been considered a message for some time. It's obviously a bit
different to most of the others - it doesn't cause a state change - but it
is just like the other messages in that it has fields defined by BTP. Other
BTP messages travel with Application messages (especially ENROL).

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

Receipt of INFERIOR_STATE or SUPERIOR_STATE will sometimes cause a state
change because they are updating the receiver on what is going on. Their
querying nature is to some degree secondary to that (the only reason why the
state table distinguishes them (with *_STATE/***/y : *_STATE/*** ) is to
avoid getting endless repeats of the querying form.  STATUS_REQUEST is
purely informational and never causes a state change.

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

The Superior and Inferior states are strictly those of the endpoint of the
two-party Sup:Inf relationship. So, yes, if both sides are aligned on what
the last message was, they will be in the same state at that level (usually
shown by having the same letter, different case, in their state table
states)

Since a Coordinator is Superior to (in general) several Inferiors, it will
have several Superior states. If it also has a Superior itself
(sub-coordinator or Coordinator within a cohesion), then it will have an
Inferior state.  The different states will not always be the same (though
there are some constraints on which combinations are possible - which are
defined via the decision event explanations (which possibly could be made
more formal).

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

I don't think there is a contradiction - Superior and Inferior are roles in
a two-party relation. Superior is always implicitly "superior to x",
inferior is "inferior of y".

> 5.
> 4.4.13 CANCELLED
> NOTE - A CANCELLED message arriving before a CANCELLED message is
> sent, ....
>
> Is this correct?

No, it should say CANCELLED .. arriving before CANCEL is sent. Thanks.

See you later

Peter