[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: implicit prepare - sent on behalf of Savas
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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC