bt-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [bt-spec] BTP Issue 79 : Normalising the message set
- From: Peter Furniss <peter.furniss@choreology.com>
- To: BT - spec <bt-spec@lists.oasis-open.org>
- Date: Sat, 12 Jan 2002 18:46:32 +0000
We've
spent some time going into this.
On the
particular question of REQUEST_STATUS, we propose that the best solution is d)
of my set below - REQUEST_STATUS is a message that can be sent to any
transaction tree node, using any of its addresses (as decider, inferior,
superior). It is basically a management message, and not part of the
"mainstream" superior:inferior or terminator:decider relations, although they
could use it. Since it may come from "outside", it is appropriate that
nodes can reject the request_status (either because it is from someone
inappropriate, or from anyone), so a FAULT(StatusRefused) is needed. (the only
change in function apart from that fault is that an address-as-superior can be
used as the target - but since an address-as-superior is really only
distinguished by being found in a CONTEXT, and we don't know how the Status
Requestor got hold of the address, it's not even much a change
really)
Having
allowed anyone to ask a node about its own status, it seems reasonable to ask
what it thinks of its relations with its inferiors, if it has any. So what was
REQUEST_STATUSES (now named more clearly as REQUEST_INFERIOR_STATUSES) can
also be sent to anyone, returning a vector of how the infeiror states. This has
to be replied to by a Decider to its Terminator, but otherwise can be rejected
just like REQUEST_STATUS if the node doesn't want to tell. (an implementation
could always return FAULT(StatusRefused) to anyone other than the Terminator (or
everyone, if it doesn't implement the standard control
interface).
Aside
from that, we had a think about the names for the messages on the control
relationship (which were just a quick suggestion in Liberty Corner).
Although REQUEST_CONFIRM was ok itself, extending the others to REQUEST_* isn't
really - REQUEST_CANCEL/whole isn't a request, its an instruction, and
REQUEST_PREPARE really means "prepare your inferiors, but not yourself". The
following seem to fit better :
used
to deciders of both atoms and cohesions:
CONFIRM_TRANSACTION
CANCEL_TRANSACTION
TRANSACTION_CONFIRMED
TRANSACTION_CANCELLED
and,
used only to deciders of cohesions :(composers)
PREPARE_INFERIORS
CANCEL_INFERIORS
The
changes are summarised in the "proposed solution" to issue 79 now on the issues
list and are fully applied to draft 0.9.0.4.
This
solution is suggested for voting, so comment if you don't like
it.
Peter
-----Original Message-----
From:
Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: 17 December
2001 12:00
To: BT - spec
Subject: RE: [bt-spec] BTP Issue 79
: Normalising the message set
Tony has pointed out to me that CONFIRM_ONE_PHASE
should be in the outcome column of course. It's really the outcome
relation equivalent of REQUEST_CONFIRM.
He also questioned what to do with
REQUEST_STATUS and STATUS. These are not strictly part of the outcome or of
the control relationship - anything can send REQUEST_STATUS, not just the
immediate superior or the terminator. The question is where do they send it
(posit an actor that plays superior, inferior, decider roles, but with
different addresses (odd perhaps, but possible at the moment) - to which
address(es) can you send REQUEST_STATUS or CHECK_STATUS
?.
Options would seem to
be:
a) there are two message
pairs, one used on address-as-inferior, one on
address-as-decider
b) there is one message
pair, used on either
c) we should not allow
different addresses (and identifiers). (this would be an answer to a different
question of course)
no doubt d) and e) can be invented - oh
yes:
d) one message pair, used on any relationship,
including the address-as-superior
I incline to b).
Peter
-----Original Message-----
From: Peter Furniss
[mailto:peter.furniss@choreology.com]
Sent: 15 December 2001
01:57
To: bt-spec@lists.oasis-open.org
Subject: RE:
[bt-spec] BTP Issue 79 : Normalising the message set
This issue was discussed at the Liberty Corner ftf this
morning.
The group concluded that it was a good idea, but that the messages
should be given distinct names for the different uses on different
relationships, rather than the qualifier.message style originally suggested.
A set of name correspondences was drafted during the meeting (but not
thrashed out in detail), as attached. This has been posted to the issues
list as "outline solution".
(needs completing with a decision on the number of
xml sub-schemas)
Peter
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC