[tm-rg] Transaction categories

[Haugen Robert]

I promised during the last tm-rg conference call to write something
about transaction categories in relation to the Grid Resource Management
Use Cases (section 8 in the current Transaction_Use_cases.doc).

I'll start by recapping some work Choreology has already done on
cataloguing transaction patterns:

**We found 4 broad patterns of business transaction behaviour:
http://www.choreology.com/usecases/index.htm

1. Propagation of data:
For example, the reliable propagation of reference or static data from a
key application or master file to other applications.

2. Aggregation of data:
For example, the reliable aggregation of inventory information from
subsidiary systems, including those of third parties.

3. Tracking of processes:
For example, ensuring that business processes and workflows are
completed in an ordered or contingent way.

4. Provisional-final agreement negotiation (was
Quote-order-negotiation):
For example, when financial trading businesses need to obtain multiple
quotes for the purchase/sale of a financial instrument and/or
simultaneously execute trades across multiple financial instruments.
Reservations or allocations for grid resource deployment fit this
pattern, which is why I renamed it slightly from Choreology's Web site.
I think Escrow Promises also fit this pattern.

**We also found 3 main patterns of business transaction *participant*
behaviour:
http://www.choreology.com/standards/standards_btm_spectrum.htm

1. Provisional-Final: do the application work but mark it as
provisional. If told to confirm, mark the provisional work as final. If
told to cancel, delete the provisional work or mark it cancelled.

ACID is just a version of Provisional-Final where the Provisional
effects are invisible. But Provisional effects in a business transaction
may be made visible to advantage, as in the quote-to-order cycle or
probabilistic inventory management. And the ACID Isolation requirement
does imply locking, which is not suitable for long-running transactions
or those involving autonomous participants.

2.Validate-Do: validate that the application work could be done, and do
it if told to confirm. If told to cancel, no application work has been
done anyway.

3.Do-Compensate: immediately do the application work as if it is final,
and later undo if told to cancel. If told to confirm, the application
work has already been done. 


**Application:

Transaction_Use_cases section "8.3.1 Agreement or contract negotiation"
fits business transaction pattern 4, Provisional-final agreement
negotiation, and Participant pattern 1, Provisional-Final.

"8.4.2 Resource allocation, deployment and scheduling" also fits
transaction pattern 4 and participant pattern 1.

"8.4.3 Resource billing and payment" may fit transaction pattern 4 and
participant pattern 3, Do-Compensate.

I am sure that Grid use cases will also provide examples of Propagation,
Aggregation and Process Tracking patterns, but I only went through the
Resource Management use cases, awaiting feedback on this approach and
these categories.


Choreology Anti virus scan completed