Re: One protocol, one context ...

[Mark Little <mcl@arjuna.com>]

> So, on pragmatic grounds (desire to see this standard get done, and get
> traction) I think we should not try to incorporate the Activity Service
> approach into this standard (your CL/CD model). Use of the AS may be a
> good implementation choice, and it can aid thinking about the problem,
> but I don't believe it should obtrude into the fundamental design.

As I said last night I can understand your point of view, and certainly in
the limited environment in which we're working for BTP it is possibly
overkill initially, since coordination points appear to only occur once,
with the same set of logic. As we discussed yesterday, it's a nice-to-have,
but not a necessity for now.

One thing I would like to see (but probably won't get!) is the prevention of
combining two-phase enabled and one-phase enabled participants in the same
cohesion. This causes no end of headaches in the transaction world where
even if you have well behaved two-phase resources that always guarantee to
abide by the coordinator's decision, as soon as you add more than one
single-phase resource you've just lost those guarantees. This was a point we
raised in the submission, where a different cohesion logic would have to
apply only for single-phase resources, and combinations like the one I just
described wouldn't be allowed (this would be seen as a control violation).
It may well be that this has to be dealt with in a pragmatic "human" manner,
e.g., if company A doesn't really implement two-phase participants and just
wraps one-phase, people will eventually begin to notice that it's their
participants that cause the cohesion to fail.

I've some follow-up to yesterday's bt-teleconference to send, but I'll do
that later.

Cheers,

Mark.

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