More on requirements for transaction demarcation in choreography

Dear Colleagues,
 
If you have further comments of support or opposition, questions and so
forth then please mail me directly or via this list.
 
The main point made during the WS-Choreography Teleconference  7 Oct 03
was that there is no single, unique use case for transactions.  On the
contrary transactions are a generally useful, ubiquitous facility that
can be applied to any use case, but particularly those that involve
economic interactions including economic commitments.
 
Note that we are taking a 3 step approach here (at least 3, might turn
out to be more).  Firstly we are agreeing the requirements.  If and when
these are agreed then there will be consideration of how to meet these
in the language - the result will depend on the nature of the language
we come up with, but I would hope for a relatively 'light touch' as this
should be easy to understand and use.  The third step (that might turn
out to be several steps in fact) is to map or 'interpret' the
transaction demarcation in the choreography language to underlying
infrastructure (and protocol).
 
A 'Business Transaction' can be defined as a consistent change in the
state of a business relationship between two or more parties.  A
business relationship is any distributed state held by the parties which
is subject to contractual constraints agreed by those parties. 
 
This definition highlights that a part of designing a business process /
choreography is deciding what activities to group as a transaction (if
any).  It is therefore essential that the facility to demark
transactions is included at the choreography level.
 
A slightly more technical, and therefore maybe slightly less
appropriate, definition of 'transaction' is:
A complete unit of work as defined by an application.  A transaction
starts when a part of the distributed transaction first initiates some
work that is to be a part of a new transaction.  The Transaction Tree
may grow and shrink over time and (logical) space.  A transaction
completes when all the participants in a transaction have completed
(that is have replied to their 'Confirm' or 'Cancel' instruction).
 
Note that an atomic transaction is a particular case of this more
general concept: an atomic transaction is a transaction, but not all
transactions need be atomic!
 
The benefits that using transaction demarcation bring are:
Ability to coordinate the outcome of application specific work across
two, or more, parties in a generic, non application specific manner, and
the fact that each party in a two party relationship has assurance, to a
high level of probability, that its partner has the same view of the
outcome as it does - sometimes know as mutually assured common
knowledge.
 
My original submission on requirements for transaction demarcation is at
http://lists.w3.org/Archives/Public/www-archive/2003Sep/0057.html and
the revised submission at
http://lists.w3.org/Archives/Public/www-archive/2003Oct/0007.html

Best Regards,

Tony                           


 <http://www.choreology.com/> 

Tony Fletcher

Technical Advisor 
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK


Phone:  

+44 (0) 870 7390076


Mobile: 

+44 (0) 7801 948219


Fax:    

+44 (0) 870 7390077


Web:

 <http://www.choreology.com/> www.choreology.com


Cohesions(tm)


Business transaction management software for application coordination



Work: tony.fletcher@choreology.com 


Home: amfletcher@iee.org