Re: Agenda suggestion [was Phone call tomorrow (4 October)]

[Mark Little <mcl@arjuna.com>]

 

Add a parameter to CONFIRMED called "report hazard [or whatever we called it on REQUEST_CONFIRM]" which can be T/F.

If the Superior is prepared to take this hint (it need not do so), it will attempt to send a new message FINAL_OUTCOME with a contained HAZARD (if there was one), or with no contents (if the final outcome equalled the decided/intended outcome).

I am against adding any additional phase at the BTP level, even if it is optional. The more optional parts to the specification we have, the more divergence there will be between implementations. I want to see a protocol that can truly be implemented by companies X,  Y and Z, and participant implementations can run on any of these BTP systems. Optional specification components mean this is not always possible. Just look at the OTS, for example.

 

If this is a message that *has* to be sent, then there's a performance penalty on the coordinator. If it's a "best effort" delivery, then why bother? In the coordinator fails and doesn't send the final_outcome message the participant is going to have to deal with this in it's own manner anyway.

 

Rather than rush something into the protocol that isn't fully thought out or required, I would prefer to see this discussed as a possible enhancement to a future BTP specification. Let's see if there is a use for it first, rather than bloat the protocol unnecessarily. Let's Keep It Simple. As I said in an earlier email, I'd rather see how workflow languages for Web Services could be layered onto BTP first. These guys are going to have issues with BTP, no doubt, and we shouldn't be trying to define workflow semantics at the BTP level!

 

It is up to the Superior how this value is arrived at. Should the information reflect the state of the entire tree, or only the immediate Superior's branch? Should the Superior be allowed to ignore "unimportant" failures? That is a matter for the implementation/application configuration, and need not be dealt with in the spec.

If we go this route it will require more thought, especially if it's an optional part of the specification. Portability and interoperability will be affected significantly if we don't tie these issues down. As such IMO this is too significant a modification for us to consider adding to the specification at this late stage. I am already worried that we may not be able to bring BTP in on time, and this is another discussion that could well run and run.

 

I do not believe that at the low-level we can provide enough support to an individual participant to determine what to do, since it did not do (may not have done) the work in the first place - the service did. Individual participants are, IMO, equivalent to OTS Resources, or xa_switch_t "wrappers": they do not have application specific knowledge, only how to drive transaction completion through to some datasource. If we are now saying that a third phase message meaning "heuristic happened" is delivered, what is the participant to do? It doesn't know what affect this has on the service it represents, unless we more closely tie participants to services. It could simply log this fact to someone, and let them deal with it out-of-band. Or it could ignore it.

 

However, wouldn't it be much better to have some structured workflow application layered on the BTP interactions take care of this? That's what these guys have been doing quite successfully for years. They have the rich languages and frameworks that let programmers structure individual object/service interactions into flows, such that if one flow cannot complete successfully, some other *application specific* flow (e.g., a compensation) is automatically (and potentially transactionally) fired off.

 

Mark.

 

P.S. I'm probably not going to be able to attend today's teleconference, so I'd appreciate postponing any vote on this. If not, then HP definitely vote NO to any extensions.

 

----------------------------------------------
Dr. Mark Little
Transactions Architect, HP Arjuna Labs
Email: mark@arjuna.com | mark_little@hp.com
Phone: +44 191 2064538
Fax  : +44 191 2064203