OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


BTP Issue 37 : Acceptable to application or participant

Submitter: Mark Little, HP
Category: editorial
Submitter's identification: #6
Page 13, last paragraph: "In addition, a cancellation may not return data to their original state, but only to a state accepted by the application as appropriate to a cancelled operation." It would be more correct to say “acceptable to the participant”, because there is no negotiation inherent in BTP to do what is implied currently.

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.
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. 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).


Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC