implicit prepare - sent on behalf of Savas

[Mark Little <mcl@arjuna.com>]

Retransmission... (I sent this earlier today to the main BTP mailing
list before Mark's message but it hasn't appeared yet. So, I am sending
it again to the models list).

Dear all,

Those attending last F2F will remember my objection in the proposal of
allowing the Initiator to include a 'prepare' into the message to a Web
Service. My argument was then, and still is :-), that the
Initiator/Terminator should not be allowed to instruct a prepare on a
Participant. This is the responsibility of the Coordinator. The
Initiator/Terminator is not aware of the Participants that register, as
a result to a call on a Web Service, with the Coordinator. If upon the
registration of a Participant with the Coordinator, the Participant
decides to vote, that's fine (the Participant has knowledge on whether
it is possible to vote or not). I don't think that anyone objects on
this.

I appreciate that there are cases where the Initiator/Terminator
(application logic) needs to get a decision from a Participant before
deciding on the result of the cohesion ("confirm" or "cancel"). I do not
think instructing a Participant to vote and then receiving the vote is
the solution. Even if it is an indication that it could vote rather than
an instruction, I believe it is wrong. Participants should only send the
vote to the Coordinator and not to the Initiator/Terminator and they
should only receive a request for a vote from the Coordinator.

The solution would be to allow the Initiator/Terminator to issue a
request for a prepare on the Atom. Since the call to the Web Service
carries the context identifying the Atom, the Participants registered,
as a result of that call, are associated with that atom. A prepare on
the atom will result on a request for a vote. This is an interaction
between the Initiator/Terminator and the Coordinator. It has nothing to
do with the Participants. The application logic does not anything about
the Participants. I appreciate that this does not help in reducing the
number of messages but it makes the interactions between actors clear.
The Initiator/Terminator only needs to know about atoms and only
interacts with the Coordinator and Web Services.

I hope all the above make sense.

Regards,

Savas

-------------------------------------------

Note from Mark: apparently Savas has tried to send this several times to the
list and no error has occurred at his end, but nothing has turned up. Do
anyone know if there are any problems with the mailing list?