Application versus protocol "finish work"

[Alastair Green <alastair.green@choreology.com>]

Mark, Savas:

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

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)
]

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.

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?

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.

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?

If you agree with 1) and 2), then what we want (the efficient one-shot) can be
achieved.

Alastair & Peter




begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard