RE: [bt-spec] BTP Issue 79 : Normalising the message set

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

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