Re: implicit prepare - sent on behalf of Savas

[Mark Little <mcl@arjuna.com>]

> No. There is an assumption that there is an interceptor (or intelligent
> communications/messaging). In the fullest case the interceptor could be on
host A,
> the initiator on host B and the coordinator is on host C. It makes no
difference
> what is local and what is distributed.
>
> > If they are *and* the interceptor knows about both (which it may
> > not) then this kind of optimisation is possible.
>
> So why do you want to prevent it?

I think you may have either missed an earlier email, or missed the relevant
sections. I'm not against this kind of optimisation if the I and C are
co-located if it's done right, i.e., I doesn't know the C protocol, only C
does. In this case, I sends C a "do a pre-prepare" message (either in a new
way we need to standardise or in a vendor specific means), which C
generates, and the service and pre-prepare message can be piggybacked on the
single service invocation by this intelligent interceptor. However, and this
is the important point, if I and C aren't co-located then we can't do this
and get the same benefits. If we do this at the application level though, we
can accomplish the same thing (see another earlier email) with the same
messages, and retain the clear distinction between I and C.

> I'm always resistant to "let's not allow it" arguments which do not flow
from a
> functional requirement. They assume that we know the future and can guess
how and
> when this stuff will be deployed. I am particularly resistant when the
"not allow"
> argument knocks out functionality implemented and proposed by companies
with
> relevant products (such as the BEA e-collaborate technology).

1 use case doesn't make a convincing argument. However, as I said above and
in numerous other emails today and last night, I'm not against it if it's
handled right.

> Well maybe so. But consider the problem of internet security. Despite the
> tunnel-everywhere approach of SOAP, installations are liable to tie down
> communications between two entities across the firewall to a single
connection that
> is authenticated or restricted in some way. If the separate coordinator
(only one
> possible topology) is inside the firewall then the kind of multiplexing
we're
> discussing here is not only likely but vital. I remember trying to deploy
DCE with
> a separate DCE security service across a firewall, and running into
exactly this
> problem. They (the net admins) just wouldn't allow it.
>
> So again, why not allow the facility that will permit this type of
"one-wire"
> topology?

First of all we're not considering security in BTP at all, so using this as
an argument for this particular requirement is not in scope. If we take that
route then all sorts of other "security" related requirements will come out
of the woodwork. Although I strongly believe that inorder to use BTP in a
wide-area environment will require security to be taken into account (and
some future version of BTP must address this), at this stage (and agreed at
the last face-to-face) we don't have the time.

Also, this kind of single-port tunnelling requires more information in the
packet than simply PREPARE. The piggybacked message is intended for a
different recipient, so the firewall (or some other intelligence) needs to
look at this and demultiplex the messages.

If we take the application specific route, your concerns are met as well.

> Let me turn the performance argument around. There are three cases you
might allow.
>
> Our general, permissive scheme says "boxcar anything you like". This means
that
> *RESP* + ENROLL + VOTE can be sent in one message across the WAN between
company A
> and company B. If company B has the coordinator in house, it requires LAN
messages
> to send ENROLL and VOTE from its interceptor to its coordinator. Total
cost: 2 WAN,
> 2 LAN
>
> Next step down: allow ENROLL to be boxcarred, but don't allow PREPARE/VOTE
to be
> piggybacked. Cost, 4 WAN + 1 LAN
>
> Now take the "I know best" approach, only allow CONTEXT to be piggybacked.
Cost: 5
> WAN + 1 LAN.
>
> It is totally dependent on the deployed topology as to the real costs of
WAN and
> LAN. But WAN messages are not generally the cheapest.

I'm not against optimisations that make sense and can be accomplished
in-model. However, to do this right IMO requires co-location, and a "send
you are allowed to prepare early" message to the coordinator from the
initiator, such that when the service invocation and the "you are allowed to
prepare early" message get into the message stack they can (by the magic of
interceptors/filters) be combined into a single message. What I am against
is the initiator taking on some of the coordinator's message generation
capabilities.

> And neither is it here. The only requirement on the BTP implementer is
that they
> are prepared to receive and understand boxcarred messages. They are not
even
> required to create and send them (that's their choice).

So what is wrong with doing this either at the application level (where it
is always guaranteed to work without any extra messages and without
co-location requirements), or in the extended context information? If you
take the latter route and come back to OASIS after a year or two with a good
case that this is actually the best way of doing things in the (then) more
mature web services world, you'd have a much better argument for modifying
the protocol.

> This is the delegation issue. The coordinator is not responsible for
deciding
> *when" to send PREPARE, it is responsible for sending it. It has always
been so, it
> will always be so. The coordinator is not capable of spontaneous
combustion.

I didn't say it was. What I said was that when a PREPARE message is
generated it should only be generated by the coordinator. No one else.

> I think all of that is achievable if you view the interceptor as a
reliable
> intermediary (like a post office).

So now we're introducing a new actor that is *required* in order to do this.
I would really like to see your argument against an application-level
approach that does not require interceptor technology at all.

> > There obviously needs to be a persistent record of the atoms that have
been
> > prepared, and some record of what the final "outcome" on those atoms is
to
> > be before that outcome is attempted (e.g., confirm A, C and D, but undo
B).
> > This outcome therefore needs to be associated with each atom, unlike in
a
> > transaction system where it on all participants.
>
> Quite so.

The reason I mentioned this is also so that Peter can put it into the
document.

> No, again, there is no such assumption. You are assuming that messaging is
> unintelligent, not BTP aware. The fundamental assumption you have is "no
> boxcarring" and my fundamental assumption is that you can.

No, my assumption is that boxcarring can occur if the timing is right and
the entities involved co-operate. However, in this particular case it is not
so.

> > Let's stear clear of meta-physics! It's "wrong" (incorrect) from a model
and
> > implementation stand-point.
>
> That's kind of the point at issue.

I disagree. You are asking for a change in the model to accomplish something
that can already be done with what we have (and in just as efficient a
manner).

Mark.

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203