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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-models message

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


Subject: agenda and goals


Can people send me a list of items they'd like to see discussed at the Tuesday face-to-face (or face-to-telephone), and I'll put together an agenda and distribute that on Monday. I need to have the items no later that 12pm on Monday (sooner would be better).
 
It seems that we are settling on a (backward/forward) compensation transaction model for BTP. So with that in mind I propose the following as our goals:
 
(i) come up with a model of exactly what we mean by structured transactions with compensations (this will mean defining terms and the entities that make up a business transaction). I'd like to stear clear from implementation details as much as possible to give people the flexibility to implement this model in whatever way suits them (and their application domains). However, we need interoperability between these domains, so we'll need to agree on exactly what can be up to the implementation, and what cannot.
 
(ii) describe use cases that can benefit from this model. This may involve showing how you can implement certain applications now using traditional transactions but with restrictions (e.g., resources remaining unusable in the event of coordinator failure until recovery occurs), and then contrast with the BTP approach.
 
Comments and suggestions please, and we can discuss these at the next meeting and hopefully finalise our goals.
 
I think it is also very important that in some part of the document we state explicitly where BTP will be applicable and where it will not. In addition, since compensations of any kind (i.e., forward or backward) can never be guaranteed to occur we also need to state this explicitly. Whatever these business transactions are that will eventually be constructed from a BTP implementation, they're not transactional in the strict ACID sense, and we shouldn't be remiss in our duty to users by overlooking that fact.
 
Mark.
 
----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203
 
 


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


Powered by eList eXpress LLC