RE: [business-transaction] BTP Issue maint-13 - proposed resolution

Following the discussion at the conf call on May 24th, Bill Pope sent me some proposed text, and asked me to supply some justifying text. I seem to have written rather a lot - consider it as a large pile of rocks that will prevent the issue, after application of the proposed change, from rising from its grave.

---

In version 1.0.9.1 (and previous) of the specification the CONFIRM_ONE_PHASE message may have a "report-hazard" parameter. This is incorrect. The CONFIRM_ONE_PHASE message should not have a "report-hazard" parameter.

Proposal is to remove the "report-hazard" parameter from the CONFIRM_ONE_PHASE message. Actual edits to be made by the editor.

Non-normative note to editor:

This is referenced in the specification sections 7.7.11 and 10.2.16. This

is referenced in the btp core xsd (2002-05-21 version) on line 345.

Justification:

The "report-hazard" parameter is used in the control protocol messages CONFIRM_TRANSACTION and CANCEL_TRANSACTION to indicate whether the top-node (coordinator/composer) is to reply with its own decision as soon as that decision is made, or wait until it has received responses from the inferiors on whether the decision has been applied. In the former case, any hazards that become known to the coordinator will (in a well-designed system) be reported and dealt with by some other means, but don't affect the program flow of the client application.

A roughly similar consideration applies to the superior:inferior outcome relationships - an inferior can choose to handle a hazard itself, or report it "up tree". Which it does depends on what the overarching relationship is - if the inferior actually belongs to a different company, it would be very likely that it would contain any hazard reports and claim it correctly applied the superiors decision (while at the same time raising urgent alarms within its own domain to make the company doesn't get caught out). At the other extreme, if the inferior and superior are under common administration, there may be no point in passing the hazard reports up-tree, since they will all report to the same management system. But in between these extremes there are cases where the report should go up tree - possibly to the terminating application, possibly just to a higher coordinator/sub-coordinator.

However, this choice of whether to report a hazard to a superior is made by the inferior and not determined by any parameters on the down-tree messages of the outcome protocol. Since BTP does not have a standardised application:inferior interface, it is left unstated whether the choice is controlled by configuration or api parameters. Since CONFIRM_ONE_PHASE is an outcome protocol message, it should follow the pattern for the rest of its protocol, and not have a report-hazard parameter.

There are two possible counter-arguments:

a) CONFIRM_ONE_PHASE is used in the outcome protocol, but its semantic is very similar to CONFIRM_TRANSACTION - it is a request to the recipient to attempt confirmation, with no guarantee that a reply will be received, but assurance that the decision will be consistent among the inferiors (details of "consistent" may depend on cohesion, sub-cohesion determinations). This is true (and since the messages were only split quite late in the BTP development, that's probably why the parameter is there). However, the similarity of semantic doesn't really affect the difference in the relationship between control and outcome relationships - a terminator is not in the same relationship to the coordinator as a superior is to an inferior, even if it has arisen that there is only one inferior. A different protocol could be devised that concentrated on the semantic of the messages rather than the relationships (it would probably be harder to explain and easier to implement), but it wouldn't be BTP 1.1

b) suppresing hazard reporting allows a superior to reach completion on the business transaction faster - if an inferior persists its knowledge of the decision (once received) it can immediately reply without waiting to see if the decision is successfully applied. Accordingly, a superior that isn't interested in the hazards can announce this (on CONTEXT or PREPARE) and speed things up. However, it seems unlikely that this sort of configuration information will be usefuly transmitted via the protocol - the lack of interest from the superior can only be because it knows the inferior will be able to cope - in which case the inferiors configuration is probably relevant. Nevertheless, there might be cases where it does make sense for a superior to indicate that it does or does not wish to receive hazard reports, for use where the inferiors capabilities were statically known but superiors requirements varied. This could be coped with be a qualifier (capable of travelling on CONTEXT, PREPARE and CONFIRM_ONE_PHASE) - but is not proposed to add such a qualifier for BTP 1.1.

---

Peter

business-transaction message