Re: Some observations

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

Pal,

> Implicit prepare:
>
> In BEA's WebLogic Collaborate there is no "prepared" message, this
> information is implied the application messages exchanged. In BTP we can
> take a similar approach for the optimized case: a participant is always
> assumed to have voted OK, unless it sent a message to the coordinator
> otherwise.

The emerging consensus would enable any participant to spontaneously vote (no need
for explicit prepare to be received).

The assumption of VOTE/Ready is predicated on a) one participant/service, b) one
forward operation invocation per participant and c) automatic infection on receipt
of an app message. If these hold true then the application response can be deemed
to be a VOTE/Ready. If any of these premises goes away (and none of them holds by
default) then you can't assume a VOTE delivery. (Btw, if you add premise d) that
participant address = service address then you can also get rid of the ENROL.)

Now, in the one-shot case, iff you have a protocol-level marker on the request that
says "This is a one-shot, single participant with automatic infection" then you can
achieve this optimization. Unfortunately you have had to _add_ something to the
request to _subtract_ something from the response.

If all four premises held then you would get the network optimization without
boxcarring, if that is the drift of your comment.

Alastair
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