RE: implicit prepare - sent on behalf of Savas

[Peter Furniss <peter.furniss@choreology.com>]

In relation to Savas's message - as I see it, then some interleaved
comments:

I think we've got several interweaving subissues here.

1) the presence of messages or sub-messages in the same packet on the wire
doesn't necessarily mean they come from the same logical "actor" in the
sender or will be delivered to a single actor at the recipient.

With any kind of filter/interceptor setup (compare OTS implicit
propagation), it would seem quite reasonable at least for upcoming Enrolls
and Votes to get stripped off an application response and delivered to the
Coordinator.  By the same token, there is no inherent reason why messages
from the coordinator could not be sent down with an application request -
the issue would only be whether the coordinator can know it's appropriate to
send the message.

2) prepare has heavily overloaded semantics in most transaction protocols.
Provided the assumptions involved stay the same, this doesn't matter, but
when we start sawing up things that have previously been united (as with the
open-top coordinators), the different aspects of prepare need to be split
out.

The transit of a prepare message can mean:
	a) there will be no more application data sent (down) to you/your servive
	b) there will be no more application data sent to any service
	c) there can be no more application data received from your service
(without causing a rollback)	d) there can be no more application data
received from any service (without causing a rollback)	e) you are allowed to
send heuristics
	f) you are allowed to send a vote
	g) you should attempt to get to a prepared (ready) state
	h) please will you send a vote
	i) propagate this prepare to any subordinates

With a closed-top top-level coordinator, it is impossible to split a, b, c
and d, and in fact the whole lot are bundled together. In our new world,
that is no longer true.

In particular, it would seem reasonable for an initiator to indicate that
the current request is the last application message that will ever be sent
to this service (a) - this is something that the initiator (and only the
initiator application) can know of itself.  But if the service receives such
an indication, and has sent what it thus knows to be the last application
reply, why should it not vote ?  It will never receive anything that will
make it more able to get into a ready state.

3) It is true that only the coordinator knows the true topology of the atom
(i.e. what participants are enrolled), and it therefore has the
responsibility for ensuring the atom is unanimous. However this only means
that it must ensure it does get a vote from all participants, not that it
can't accept a vote from a participant well before the initiator has told
the coordinator to get votes from everyone.


Let us allow the initiator to send a marker to a service meaning (a) as in
2) above, at any point where the initiator knows this to be true, and from
that allow the service (after making what data changes it determines are
appropriate) send a definitive vote with the reply. The vote is stripped off
(by some means - effectively part of the initiator/communication boundary)
and delivered to the coordinator.

Eventually the initiator/terminator will ask the coordinator what the
atom-wide vote is (this will often be intermediated by a cohesion entity,
but not always). At this point the coordinator should send a prepare (with
at least sense (h)) to any registered participants that haven't sent a vote.
It has then got votes from everyone, and can apply the usual (as for an
interposed atomic coordinator) rules to work out what its vote is. If more
than one atom is to be confirmed as part of a cohesion, it is at this point
essential that the combined votes are passed to a (persistent-over-failure)
composer; if only one atom is to be confirmed, it will in fact work to have
the volatile initiator/terminator make the decision. (it is only at decision
time that the top-most entity must be persistent).


One complication on this would be a case with two services, both with
participants, but with the first also acting as a context "router".

some ascii art: (J is meant to be a right-angle turn !)

I  --->   S/P(a)  ---->  S/P (b)
   <-------J              |
   |                      |
C <J                      |
  <-----------------------J

 Posit that (a) sends its enroll AND its vote back directly, but (b) sends
an enroll directly to the coordinator. (it must make sure it has had an ack
to the enroll before it replies on the application message, but that's
regular checking rules). If the allowed-to-vote marker was propagated to
(b), it may also vote (on the direct path to C); if not it will just sit
there, unaware that it has received the full story (imaginably, it hasn't if
there are other similar branches in the atom).  If it doesn't vote, the
coordinator will send it a prepare when asked to by the initiator, and get
the vote then.

Some implications of this are that it has to be allowable for a participant
to receive "prepare" in various forms more than once - certainly that it
should be prepared to repeat its vote.

The rule for the Coordinator is that, when asked to prepare its atom, it
sends prepare (sense h) to all registrees that haven't voted (to its
knowledge).

I believe that there should be a BTP-defined marker that the initiator can
put on the application request to say that a vote is permissible. Somewhat
to my own surprise, I now think this should be just a permission (sense f),
not a request - it is up to the service+participant to decide when they can
vote. [this actually isn't as sharp a distinction as you might think -
without something incredibly complicated in timeouts, the participant is
going to vote when it is ready and not before]



Savas sent (via Mark):
>
> 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

The initiator doesn't know exactly where, or how numerous (0..n) the
participant(s) is that is registered as the result of propagating the
context to a service. The initiator can (and usually does) know what
messages it is sending to that service, and when they form a complete set on
which the service, and any underlying participants, can determine their
vote.

> 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.

Without getting some indication from above, the participant doesn't
generally know whether it can vote - if the application messages + btp
messages don't include any of senses a-d, the service+participant must be
able to handle another message  - "hang on, I haven't finished yet".

> 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.

why is the latter (especially as just an indication) "wrong" ? This isn't a
moral issue :-)

> 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

we need to be able to do sequential multiple one-shots in  a single atom -
posit a transfer where there is a one-shot to get a value from service A and
then to deliver the value (or a derivation of it) to service B. That
requires that A is prepared before B has been invoked.

> 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 think what I've suggested above possibly meets your fears - the
initiator/terminator doesn't directly deal with participants, but can mark
webservice invocations such that the participants that the webservice causes
to be involved receive signals that allow them to send votes to the
coordinator.

> I hope all the above make sense.

v. helpful.  ditto.

> 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?

I've had no trouble.

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX