Re: Application versus protocol "finish work"

[Savas Parastatidis <Savas.Parastatidis@arjuna.com>]

This is on behalf of Mark.
-----


>I think we may be converging, but along rather tortuous routes.

I too don't think we're that far apart.

>
>First of all, can I lay out what I think your "application marker" 
>counter-proposal correctly is:
>
>Assume that *FINISH* is the app marker. Assume there is no box-carring.
Assume
>that there is an intermediary or interceptor for adding CONTEXT, called
INT(I)
>for the initiator side.
>
>I -- *REQ* + *FINISH* -- INT(I)
>INT(I) -- *REQ* + *FINISH* + CONTEXT -- S
>S -- ENROL -- C
>C -- ENROLLED -- S
>S -- PREPARE -- P [or some backdoor to say <prepare>]
>P -- VOTE -- C
>S -- *RESP* -- I
>I -- <prepare> -- C
>C -- <outcome> -- I
>
>Minimum of 5 network messages if we assume that I and C are on one node

>of
the
>network and S and P are on a second. (Obviously this assumption could 
>be relaxed).
>
>Now introduce boxcarring., which uses the INT(I) and also INT(S) for 
>the
service
>side.
>
>I -- *REQ* + *FINISH* -- INT(I)
>INT(I) -- *REQ* + *FINISH* + CONTEXT -- S
>S -- ENROLL -- INT(S)
>S -- PREPARE -- P [or some backdoor to say <prepare>]
>P -- VOTE -- INT(S)
>S -- *RESP* -- INT(S)
>INT(S) -- *RESP* + ENROLL + VOTE -- INT(I)
>INT(I) -- *RESP*  -- I
>INT(I) -- ENROLL + VOTE -- C
>I -- <prepare> -- C
>C -- <outcome> -- I
>
>Minimum of 2 network messages.
>
>Without boxcarring you go from 6 to 5 net messages; with boxcarring you

>go
from
>6 to 2 messages.
>
>[
>Further benefit would be obtained by boxcarring if there is more than 
>one participant involved, so long as you allow indefinite boxcarring.
>
>E.g INT(I) -- *RESP* + ENROLL(Pa) + VOTE(Pa) + ENROLL(Pb) + VOTE(Pb) --
INT(S)
>]

Just in case it hasn't been clear in earlier emails: I have no problem
with boxcarring if it can be carried out naturally. This kind of thing
does go on in other systems, where, for example, an interceptor may
multiplex messages to an object if it detects them being sent at the
same time. It's a valid optimisation.

>If we understand your proposal correctly, the application marker 
>*FINISH*
allows
>the service to use its application understanding to deliver "prepare"
either
>through an interoperable PREPARE message, or through a proprietary API,

>to
all
>the participants that it knows are finished work on behalf of the BT
referred to
>by the CONTEXT.

First of all what I'm assuming is that a participant is allowed to send
a vote as the result of an unsolicited message that may not look at all
like a real prepare message would from a coordinator. As I said in a
previous email, it may well be that no external messages are sent
whatsoever to a participant to cause it to send a vote. For example, a
logical timing message may be generated purely internally to the
participant, such that if it hasn't received an explicit prepare from a
coordinator after, say, 10 minutes, it decides to prepare (and reserve
the book regardless just so that the reservation is persistent). As I
said, in this case no PREPARE message is sent from anyone: the
participant simply decides to do it. What I'm really saying is that it's
up to the service and/or the participant to figure out how and when to
send a vote, most probably with hints from the users.

>
>Is this correct?
>
>If this is correct, two comments
>
>1) The initiator has sent an app message, without reference to the
coordinator,
>which causes "prepare" to be delivered to some set of participants, 
>defined
only
>by the service. This happens prior to any attempt to deliver prepare to
other
>"branches" of this BT, which would result from the initiator prodding 
>the coordinator.
>
>Given all you have said about who delivers prepare, are you happy with 
>this consequence?

I think I agree ;-) But just in case let me say what I think is
happening at the message level. The initiator sends a (for example)
BOOK_TAXI message to the web service, and in the XML document the
context (which references the
coordinator) is part of the payload. In addition, because the
initiator/business logic knows that this is the only time it's ever
going to talk to the servie, it sends a ONE_SHOT (or whatever the web
service designed specified) attribute with the operation. If we assume
that this is the first time the web service has been invoked in the
context of this BTP then at some point before it returns the result to
the business logic it creates the participant (creates is an overloaded
word, so don't assume that this means it brings into existance a new
service or instance of some kind - there may be a pool, for example),
telling it that this is a ONE_SHOT (how it does this may be
implementation dependant, but in this round of BTP we're not specifying
the S-to-P protocol). The participant may then use this information when
enlisting with the coordinator, and send back an ENROLL and a VOTE
message.

>We see no particular problem; we also agree that the application marker
gives
>more flexibility, because the service decides which participants are
involved in
>the mini-prepare, and there is no requirement for the spec to deal with

>service-participant relationships. This obviously gets rid of the extra
message
>"PERMISSION_TO_VOTE" or the like.

I think we're in agreement. One further thing that has come up as a
result of this discussion is does it make sense for the coordinator to
refuse to accept early votes? I can see situations where the coordinator
simply may not be able to deal with VOTE messages (or may not want to)
until a certain time. I haven't had a chance to consider this much
however, so would be interested in further input either way.

>
>2) The interceptor is required for implicit propagation of the CONTEXT.

>It
is
>much more efficient to reuse it for boxcarring than not to allow
boxcarring. Do
>you agree?

Agreed. If multiple messages are going to the same recipient at the same
time (either from the same sender or even from different senders in the
same address space) it always makes sense to try to send them together
(as long as we can ensure that they are received [or at least acted
upon] in the right order!)

>
>If you agree with 1) and 2), then what we want (the efficient one-shot)

>can
be
>achieved.


Great. By yesterday afternoon I thought we weren't actually that far
apart on implementation or desire. Just coming at it from different
angles.

Cheers,

Mark.