Re: [bt-spec] BTP Issue 37 : Acceptable to application or participant

[Mark Little <mcl@arjuna.com>]

 

The thought in the original phrasing was that the client-side (or its user) would also find such a cancellation-with-side-effects "acceptable" - if it didn't, it should not have been doing business with this service. How the client side actually knows this - whether by "standard terms and conditions", warning notice elsewhere on the website, automated (or not) trading partner agreement is not the immediate concern of btp. It is true we don't have negotiation for this in BTP, but then we don't have any defintion in BTP of what confirm means either - it is all in the application data.

 

True, but in BTP we've consciously placed most of the intelligence about consistency at the participant side. Of course if the user finds that this isn't acceptable then they won't use the service again, but at the end of the day it's always down to the participant. With an ACID transaction system, both the user and participant have an implicit contract about what will happen in the case of commit and roll back. Such a contract doesn't (and possible never could in a general way) exist in BTP.

With BTP's target of inter-organisational, loosely-coupled interactions, a participant is only required to perform confirm or cancel as determined by the inter-party contract.

My point is that this "inter-party contract" doesn't exist in BTP. We have no support for it, and we barely mention what it "should" be in a "best practices" p.o.v.

Comparted to "classic" transactions and databases, there are two "relaxations" - what the participant does internally to deliver on the contract is it's sole concern; and what cancel means is defined by the contract, not rigidly "everything goes back to its original state".

 

In fact, it can be argued that these aren't relaxations at all, but are there in the classic case anyway - or that the database contract is a particular case. The database contract is that the data, as accessed via the database, will be inaccesible to other database use during the transaction, and, if rolledback, will appear as they were before. But if you go looking in the files the database uses, you will probably see transient changes and can find changes caused by rolledback transactions. But these are deemed irrelevant (they aren't visible in the model).

But everyone using an ACID transaction system from the client down to the resource *knows* what to expect in all conditions. With the exception of heuristics, they can say *exactly* what the state of the system will be despite failures or concurrent access. That isn't possible with BTP. My point isn't that this is wrong, but that the original text implies that information about the state of the state (!) is available to the client somehow as a result of using BTP. It isn't, and the client has no way of controlling this, except by using his commercial might if it turns out that the participant did something he didn't like upon cancel. In addition, I think it's extremely important to point this out to participant implementors.

 

Mark.

 

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