Re: Application versus protocol "finish work"

[Mark Little <mcl@arjuna.com>]

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

-----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 222 8066, FAX : +44 191 222 8232
EMAIL  : mark@arjuna.com