Re: Heuristics in BTP atoms

[Sazi Temel <sazi.temel@bea.com>]

Alastair, 
I meant to reply your e-mail a few weeks ago, unfortunately was not able
to do so.. here it goes.

I think there are two different but some how related issues here: 1) the
issue of qualifying PREPARE that is raised by Pal and 2) the proposal of
including a new message (a final state) into protocol that is proposed by
me (at the conf call last week and partially via prior 
e-mails).

I think my proposal boil-downs to send a final message to a participant
of an atomic transaction that is already confirmed but unaware of the
fact that the transaction is not reached a final outcome because some
other participant cancelled (whether it is because of a PREPARED time-out
or other reasons). In such situation, it is clear that the participant
that is already confirmed will experience much more severe consequences
than the one canceled. In fact, there is no penalty for canceling, plus
the canceling participant receives a CONTRADICTION message from the
superior which will most probably be ignored. On the other hand the
confirmed participant will continue to take the necessary business
actions to complete its promise (of sending goods! without a
transportation arranged!) when it confirmed. Now, my question is: why
does the superior bother to send a CONTRADICTION message to the Cancelled
participant? There is not much to do since we do not expect the canceling
participant will re-consider its decision, Coordinator should, in fact,
sent a CONTRADICTION to the confirmed participant so that it can take any
necessary corrective action (what ever it might be, the protocol does not
mandate any action to be taken it just informs the participant that the
'deal is off.') I don't think this is a business level agreement at all.
A 'good' Atom coordinator is trying to reach a common outcome for its
participants - no more than the BPT protocol mandates. Also, in case of
VT, a Coordinator cannot inform the VT on this 'MIXED' situation (it
cannot send MIXED to VT per protocol rules) so even if it is considered
as a business level agreement Coordinator cannot help to upper layer to
make its decision at least for the VT case. I think the simplest approach
would be to Coordinator send the 'final message' to the participant not
to the terminator.

I agree with you and others who argued that BTP is a protocol for
coordination of loosely coupled distributed services etc., but disagree
with the argument that a Web Services participant cannot/won't keep the
logs (which is necessary to do anything about a 'past' transaction) for
long time after it confirmed. We know that BTP already requires keeping
the logs around for a while for the participant that is cancelled -
participant which is cancelled will keep the log until it hears from the
superior (in fact every participant that make an autonomous decision
whether it is CANCEL or CONFIRM required to keep logs until they hear
from the Coordinator, per BTP rule. Also, Cohesion requires that the logs
to be around for long time (as long as the Cohesion is around) so the
keeping the logs around for long time is not an issue.

Although my proposal is not in anyway based on the issue of qualifying
PREPARE, I think prepare time-out will create situations in which the
final-outcome message may be used to help recovering of the participants
and reach a common outcome so I have used it as an example...

Lets look at the sequence diagrams for the current and proposed message
flow for both REQUEST_CONFIRM and CONFIRM

Sequence of messages for REQUEST_CONFIRM:

Coordinator

    

<----------[REQUEST_CONFIRM]----------
Volatile_Terminator

        

        

----------[PREPARE]---------->
Participant_1 (Order Goods)

        

        

----------[PREPARE]---------->
Participant_2 (Shipment)

        

        

<----------[PREPARED]----------
Participant_1

        

        

<----------[PREPARED]----------
Participant_1

        

        

----------[CONFIRM]---------->
Participant_1

        

        

----------[CONFIRM]---------->
Participant_2

        

        

<----------[CONFIRMED]----------
Participant_1 (Goods are ready to be sent)

        

        

<----------[CANCELLED]----------
Participant_2 (No transportation is available!) 
**MIXED**

        

        

----------[CONTRADICTION]---------->
Participant_2 (you did not keep your promise!)

        

        

----------[CANCELLED]---------->
Volatile_Terminator (Transaction is not completed!, really?) 

I think there are two ways that Coordinator can help to bring both
participants to a common outcome: 1) the coordinator sends CONTRADICTION
message to the Participant_1, not the Participant_2 which will ignore the
message anyway or 2) the Coordinator sends a NOT_COMPLETED message to the
Participant_1 as well as sending CONTRADICTION message to Participant_2
(or sends CONTRADICTION to both Participants) so that both Participants
will try to reach to the same outcome which is cancelling/undoing, what
ever appropriate for the their part of the operations in this
transaction.


Sequence of messages for CONFIRM:
Coordinator

    

<--------[CONFIRM]-----------
Persistent_Terminator

        

        

----------[CONFIRM]---------->
Participant_1

        

        

----------[CONFIRM]---------->
Participant_2

        

        

<----------[CONFIRMED]----------
Participant_1 (Goods are ready to be sent)

        

        

<----------[CANCELLED]----------
Participant_2 (No transportation is available!) 
**MIXED**

        

        

----------[CONTRADICTION]---------->
Participant_2 (you did not keep your promise!)

        

        

----------[MIXED]---------->
Persistent_Terminator (Transaction is in MIXED state)

In this case the Coordinator is able to tell the terminator that the
transaction is failed, but without telling which Participant is 'bad'',
terminator cannot do much even if it has a business level agreement with
the service...

Regards,
--Sazi

At 06:20 PM 9/10/01 +0100, Alastair Green wrote:

Peter, Pal, Sazi:

The issue of qualifiying PREPARE was decided at Mt Laurel. It got covered in the muck of ages, and I dug it out and reminded the list that this proposal made by Mark Little of HP existed, and had been decided, during the discussion on VCT-Composer relations.

This compensation versus cancel issue is pretty fundamental. I think we are all agreed that compensation (approximate inversion, partial inversion, levying a penalty, ... that is, a completely business-defined view of what it means to counter the effect of application operations) is a critical necessity in web services, loosely-coupled services etc.

Three short points then follow, in my mind:

a) the exact inverse operation (undo of state changes) is one member of the set of possible compensatory actions for an operation. It is a special case.

b) a two-phase commit CANCEL message can trigger a compensation

c) so can a workflow.

Case b) illustrates the integration of compensations within a coordination protocol. Case c) illustrates the fact that free-form flow control can trigger anything, including compensations, in a way, and under conditions, that are completely specific to a business process (i.e. an application). While this type of compensation may be useful and natural in some cases, it is not part of a protocol at all. Cases b) and c) considered together illustrate that compensation is neither equal, nor not equal, to 2PC.

Which gets back to the need for the protocol in the first place. I think the best way to look at this is to consider the error-handling required to assure completion in an common direction among different operations in different parties. Try writing the collaborative protocol by hand that includes such failure recovery processing, and the need for a general-purpose coordination protocol will fairly rapidly become apparent (I think you will end up recapitulating the history of transactionality).

BTP removes business-irrelevant clutter from the forward progress view that business-process designers want to take, and it offers mutual guarantees that are actually more necessary in an inter-organizational environment than inside the firewall. It shoves a lot of nasty, tricky, error-prone coding behind the arras. It comes out of the hands of application designers, and puts it where it belongs, in the realm of system software.

The onus is in fact on the BP and CP designers to show how they are going to ensure that interlocking business processes synchronize and intermesh correctly and reliably without having to replicate the well-understood features of multi-round coordination protocols.

Alastair
 
 

Peter Furniss wrote:

 Pal,I'm a little confused by your message, since the participant timeout has been in since very early on and the perfect equivalence between compensation and classic rollback is pretty much the foundation of btp. There is a timeout on PREPARED (formerly READY), which has more or less exactly the meaning you give - "I promise to be PREPAREd for the next 5 seconds" . The timeout is carried in a standard qualifier (decided at Mt Laurel, I think) but is very much part of the semantic. There was discussion of having a corresponding one on PREPARE, which would mean "please be PREPARED for at least T seconds, if you cannot make such a promise, then I'd rather have a CANCELLED now". I believe we decided to include that as another qualifier, but I'd have to check the mail archive to be sure.But more fundamental, what it means to be PREPARED is only that the Participant will be able to confirm (make the changes permanent and beyond scope of reversal within the understanding of this biz transaction) or cancel (make the changes undone, reversed). But both confirm and cancel refer to the *shared* understanding of the application semantics, not anything that may be done in either end. If, as is very likely as you say, the whole is done by committing the work during the active phase and then, within the participant, compensating if it is cancelled, there are still potential time-constraints - more likely to be hours or days perhaps. But during that time an implementation (the underlying business system that offers the web service + participant) has to keep the cancellation available - it will perhaps not actually start anything irrevocable. In such a case, the confirm operation merely means the cancellation can be forgotten. During that period, though there may not be any database locks, there is still uncertainty as to whether the operations are going to apply - and the webservice might insist on imposing limits on how long it will remain in a state of (business) uncertainty.Of course, conversely, if the implementation chooses to fulfil its PREPARED promises using XA (perhaps because contention possibilities are very low), it is no concern of the BTP protocol, or of the client / coordinator that it is doing so. The promise relates only to the shared understanding - more exactly the contracts between the parties - not to the mechanisms used within the end-systems. In fact, in some cases, exactly what "cancellation" means might not be a perfect reversal even within the shared understanding - for example if cancellation incurs an administrative charge. But that's not really any different from getting a telecoms bill for the connection over which you ran the now-cancelled transaction. The key thing is that would be understood in the contract (ultimately legal contract, perhaps just stated in standard terms and conditions) - "you may order a bouquet of flowers, with the order controlled by BTP. If the order is cancelled less than 24 hours before delivery, there will be a $5 charge. We will automatically (autonomously) confirm the order 3 hours before delivery and charge the full amount, if no cancellation is received". What happens at the flower shop is no concern of the buyer.BTW, as is mentioned in our draft paper on BTP that Alastair sent round, compensation has some shades of meaning that have confused some of our previous discussion. BTP enables the delegation of cancellation (CANCEL is sent to the flowershops participant, and that's all the buyer worries about). There is also cancellation by hand - phone up the flowershop and get them to cancel the order, identifying it by who bought it, who its to and what it is - that's what BTP packages and delegates for you. But quite different are various actions performed at either end (and quite independently) to counter the side-effects - the flowershop may reduce the price of flowers bought in specially; the buyer may get chocolates instead (or get drunk on his own). Those are out of scope of BTP. They would quite likely (in real examples) be controlled by the business process of the party in question.Peter

-----Original Message-----
From: Pal Takacsi-Nagy [mailto:pal.takacsi@bea.com]
Sent: 04 September 2001 18:29
To: Peter Furniss; Sazi Temel; Sazi Temel; business-transaction@lists.oasis-open.org
Subject: RE: Heuristics in BTP atoms
 
I apologize, if this was raised before... Why do we need an extra timeout on the PREPARE?Why is the timeout for the atom not sufficient? I am not sure that this "I promise to be PREPAREd for the next 5 seconds" is realistic in the world of web services...I assume that most of the web services participating in a BTP transaction will use compensation to back out committed changes, therefore this extra timeout will be irrelevant.Pal

---

---

Sazi Temel
Principal Consultant,
eCommerce Services, bea Systems, inc. [www.bea.com]

---