Re: Some observations

[Mark Little <mcl@arjuna.com>]

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

This is slightly different to what we have been discussing (and to which I
believe we had reached a conclusion). A participant is allowed to send an
"out-of-band" VOTE message at any time to the coordinator. When would you
assume the participant is "assumed to have voted OK"? Are you suggesting
that every ENLIST is implicitly also a VOTE?

> Coordinator factory:
>
> I don't quite understand why we need this. To my mind the selection of the
> coordinator can be a private matter to the initiator. All other
participants
> of the BT will learn about the coordinator via the bt context passed to
> them.

At the Mt Laurel face-to-face it was agreed that we need to define the
protocol between initiator and coordinator so that third-party coordinators
can be used, e.g., BEA may provide a coordinator web service that is
generally available to other BTP application developers. As soon as we go
down this route we then need to consider two alternatives: are coordinators
individually addressable (i.e., an individual web service for each
coordinator), or are individual coordinators hidden behind a single web
service interface (the coordinator factory/manager)? Although we believe the
latter is more in line with the coarse-grained component-based approaches of
web services, it's not a clear-cut decision. Therefore, an approach that
supports both would satisfy HP and others, and it would appear that the
protocol will already support this.

Mark.

-----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 206 4538, FAX : +44 207 670 1964
EMAIL  : mark@arjuna.com