Re: Open-top coordinators and protocol

[Mark Little <mcl@arjuna.com>]

<deleted things I'm assuming Savas may respond to.>

> See my message sent yesterday evening  - the service doesn't know which
> participants are involved, but it does know the sequence and completeness
of
> the application messages.

I think we're arguing vehemently for the same thing (on the whole) with just
some "fine-tuning" issues. I agree that it is down to the application to
know it's finished with the service, but I also think (as pointed out in an
earlier email) that the service may well have knowledge that allows it to
early-prepare despite what the application may think. However, taking just
the application-side stimulus for a moment, the stimulus to early-prepare
should not be a coordinator message that the initiator somehow knows about.
At the most it should be at the application level, and left up to the
service to interpret.

> The piggy-backed "prepare" (or implicit prepare)
> refer to the completeness of the messages, and thus, by implication, the
> appropriatness of a vote from anything receiving those messages.
>
> There is then a separate question as to whether the indication that the
> messages are complete should be in a BTP-defined construct or left to the
> application. This is hard to give a firm answer on, but I inclinde to a
> BTP-defined construct. This makes it easy to BTP-ise an application
exchange
> that does not itself have the concept of packaging its requests into
groups,
> without requiring additions to the application messages in an ad-hoc
manner.
> (arguably an application X + BTP isn't quite the same protocol as X alone
> and doing so does add messages (the btp allow-vote) to the application
> messages, but the advantage is that you can do exactly the same thing for
> Y+BTP, Z+BTP etc).   A midway position is to have a BTP-defined
> "allow-prepare" but also permit voting at any point (used with different
> applications) - this is truly implicit prepare, but if a
service+participant
> believes it can vote, who are we to say it doesn't understand the
> application protocol.

I have no problem with letting a participant prepare-early if it wants, even
asynchronously. The issue is: how does an application communicate to a
service that it *can* prepare early as the result of performing some work. I
believe that this should be done at the application level.

Mark.

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203