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
- From: Peter Furniss <peter.furniss@choreology.com>
- To: bt-spec@lists.oasis-open.org
- Date: Tue, 27 Nov 2001 16:21:54 +0000
BTP Issue 37 : Acceptable to application or
participant
Submitter: Mark Little, HP
Category:
editorial
Submitter's identification:
#6
Description:
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
------------------------------------------
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