[tm-rg] action items from 30th of March conf call

[Haugen Robert]

* Breakdown of grid resource use cases: 

I don't have the latest use case document yet, but figure the grid
resource section will not have changed much, so here's what I suggest in
outline form. (I'll change the latest document when I get it.)

Break down as in section 9.4 of the document, where each subsection,
e.g. 9.4.n, is a separate use case.  Each of these use cases are
instances of Category 4. Agreement negotiation and execution.

<use case doc excerpt>
9.4	Specific Transactional Requirements
9.4.1	Contract or agreement negotiation

R21	A negotiation transaction may require long, back-and-forth
conversations between parties before preparation and commitment.
R22	These conversations may require application messages to be
logged along with transaction signals for recovery. 
R23	One party may conduct negotiations with several other parties
simultaneously, confirming some and cancelling others.

9.4.2	Resource allocation, deployment and scheduling

Before Grid resources are deployed for a job, they will probably be
pre-allocated or reserved.  Reservation may go hand-in-hand with
scheduling:  that is, if a resource does not have available time slots
within the job scheduling parameters, it may not be allocated.  A
reservation is a provisional promise, subject to eventual use or
cancellation (or timed self-cancellation).
R24	Ability to support reservation is a provisional promise, subject
to eventual use or cancellation (or timed self-cancellation).

Grid resource scheduling is probably similar to "Escrow Promises" [9]
Example 2.2.  An Escrow System for scheduling runs on production
machines. 

Even more than negotiations, a Grid client is likely to reserve
resources from many parties at the same time, confirming some and
cancelling others.
R25	Ability to reserve resources from many parties at the same time,
confirming some and cancelling others.

9.4.3	Resource billing and payment

According to GESA-WG, resource billing and payment transactions require
payments for failure to meet QOS guarantees, called Refunds by GESA and
Penalties by GRAAP.  These may be compensations as in Sagas, or separate
compensatory transactions after-the-fact.  (Note: GESA uses the word
"Compensation" its economic sense, as payment for services rendered.)
R26	Ability to provide alternative resources, such as a payment to
compensate for familiar to provide a specified service or level of
service.
</use case doc excerpt>


* More details of Distributed ATP use case:

Not ready yet.  Next week.


* Expanded explanation of Reliable Messaging vs Business Transactions:

I think this relates to the discussion between me and Dieter during the
conference call.  If I missed something important, Dieter, please let me
know.  After further discussion, I'll try to re-write the statement in
the document.

The current use case document says:
"Category 1. Information dissemination:
For example, the reliable propagation of reference or static data from a
key application or master file to other applications."

Mark Little commented:
"It may be too late to point this out, but this doesn't have to have
anything to do with transactions. Reliable communication protocols (many
of which have existed since the 1980's) can also accomplish this."

Of course, it's not too late at all.  The use case example is too terse
and loose, inviting comments like Mark's.  I think there's a continuum
of qualities of service in play here, from best-effort propagation to
reliable message delivery to reliable processing to known outcome, with
some other qualities plugged in along the way. What QOS you need will
depend on the application, for example, if the application requires
guarantees that each of a known list of recipients has correctly updated
its reference data, you may need known outcomes, that is, a business
transaction.  

<Quote from Alastair Green>
Reliable communication protocols can only ensure delivery by one RM
endpoint to another RM endpoint. RM endpoints are "applications" with a
single purpose: to achieve reliable delivery to each other. But the real
applications that produce and consume are not RM endpoints, they are
applications that consume and produce messages, but also compute and
persist. The problem of how to ensure that consumption/production is
automatically and reliably tied to computation and persistence is a
transactional one. RM + 2PC, correctly used, gives guaranteed delivery
and processing. However, it is already becoming an application
programming discipline, combining, correctly, two different
technologies. Furthermore, the processing is subject to business rule
failure (i.e. it may be true that work occurred, but was it the right
work? And what about situations where the resources being manipulated
are not distributed-transaction capable (non-XA, 1-phase or zero-phase).


Taking off from the point about non-technical failure: What about the
next step up: knowing the outcome? Now we need to send messages back to
coordinating apps like propagators, saying, we did do it, with this
result. Those messages must be correlated as part of a larger structure.

What about cross-recipient dependencies? I must not publish to the world
unless the regulatory news service has received the information? Now I
need two- or multi-phase exchanges at the level of the whole
publication.

What about environments where RM is not available? 

RM is a possible building block. It is not a finished solution.
</Quote from Alastair Green>