Re: interposition

[arkin <arkin@intalio.com>]

> Mark Little wrote:
> The work that AP must do when it receives the termination message from
> C0 now depends upon which category it falls into. If it is 2, then it
> must prepare its own local work before forwarding the prepare to all
> locally registered participants (e.g., B). It must record sufficient
> recovery information for its own work as a participant *and*
> additional recovery information for its role as a coordinator. If it
> is case 3 then it need only do the latter.

I believe this should actually happen in reverse order. The
sub-coordinator must assume that any of its participants (in local
proximity, but likely in a separate server) are susceptible to failure,
and as such as them to prepare all work before it performs any
preparation on its side, returning a vote to the coordinator.

Technically speaking, if the sub-coordinator fails, it will not be able
to prepare itself or its participants and the transaction will timeuot
and rollback by the coordinator. If a participant of the sub-coordinator
fails, the sub-coordinator will still attempt to prepare before giving
up. Hence, it should ask all its participants to prepare first, and once
all votes have been tallied perform work on its side. It must, however,
record such a tally in durable storage.


> So the question then becomes when and why does subcoordination
> (interposition) occur?
> 
> (a) performance: if a number of participants reside on the same node,
> or are located physically close to one another (e.g., reside in the
> same LAN domain) then it can be more performant for a remote
> coordinator to send a single message to a sub-coordinator that is
> co-located with those participants and for that sub-coordinator to
> disseminate the message locally, rather than for it to send each
> participant the same message.

Considering the amount of messages that might be involved, a local
coordinator will be more efficient and result in shorter transaction
completion time, thereby quicker to reach a resolution and release any
resources held by that transaction.


> (b) security & trust: a coordinator may not trust indirect
> participants, and neither may indirect participants trust a remote
> coordinator. This makes direct registration impossible. Concentrating
> security and trust at coordinators can make it easier to reason about
> such issues in a large scale, loosely coupled environment.
> (c) connectivity: some participants may not have direct connectivity
> with a specific coordinator, requiring a level of indirection.
> (d) separation of concerns: many domains and web services may simply
> not want to export (possibly sensitive) information about their
> implementations to the outside world.

This is a valid argument. Consider a typical Web service that is
implemented as a simple EJB bean using one database connection. Since
the database connection uses X/Open XA and is not even exposed to the
BTP coordinator, we can fairly say that the EJB bean (through use of a
TM) acts as a sub-coordinator.

Complicate the scenario a bit, and we've decided for internal reasons
that do not affect the user or the service to decouple said EJB bean
into three different beans. We now have a more complex commit process
involved (assuming three database connections, maybe two EJB
synchronizations). Again, we do not involve the user of the service or
BTP in that decision, and do not expose the internal structure of the
transaction tree to them.

More complicated scenario, we have no decided to replace one bean with a
Web service. In effect, we have substituted one internal operation (not
directly exposed to the service user) and instead of using IIOP/RMI, it
now uses SOAP. I don't believe that at this point we should be forced to
expose that particular operation to the outside world, just because we
decided to change the protocol involved.

Whether IIOP, X/Open XA or SOAP/BTP is used, should be at the discretion
of the Web service developer and the BTP protocol should not force the
Web service developer to expose the internal workings of a Web service,
just because a particular communication protocol has been used.


> What are the requirements for not doing interposition?
> 
> (i) coordinator global knowledge: a coordinator (or more likely the
> business logic which created it) may want to know the identities of
> all participants (e.g., for audit trail purposes).

Again, from the perspective of the user this is transparent. The Web
service defines it's expected inputs and outputs, but not how it goes
about doing its work. Indeed the initiator may not be aware of all
participants indirectly used in the transaction (but will be aware of
all participants directly used), and not be able to record them in the
audit trail.

The audit trail should only reflect the direct participants of the
transaction, and will never be able to reflect all indirect
participants, specifically where other protocols (or direct API calls)
are being used.


> Therefore, having another external entity force (by default)
> interposition to be disabled is not the right choice. In addition, it
> can never be enforced or fully policed: since a sub-coordinator is a
> participant as far as it's coordinator is concerned, a sub-coordinator
> could lie and say it had disabled itself when in fact it had not. To
> prove otherwise would require going outside the protocol (e.g., an
> administrator examining logs after the fact) and may still be
> impossible if sufficient audit trails are not kept.

I agree.


> If there is a need to not have interposition then:
> 
> (a) it could be an attribute of a web service (e.g.,
> UsesInterposition), and coordinators that want global knowledge simply
> do not use these types of participants.
> (b) there could be a DoNotInterpose part of the context, that services
> may use to determine whether or not to do interposition (though
> participants are free to ignore this, i.e., it is only a hint).
> Obviously the view of a parent coordinator may not reflect those of
> its children, such that if a root coordinator wants interposition, a
> sub-coordinator may not, and hence may override the context.

I would also suggest:

(c) The coordinator may communicate all known participants in the
context, such that any participant will not sub-coordinate against these
participants. The coordinator is then able to tell which participants
are already enlisted and coordinated in the global transaction, or
preclude certain participants from being coordinated by any
sub-coordinator. Such participants must always be coordinated (if used)
by the coordinator.


> Rather than introduce many flags (c.f. EJB) that have no proven
> requirements at this stage, and which may therefore restrict us in
> future, let's try to keep things simple initially. Unless there are
> well proven use cases for doing something in a given way (e.g.,
> MustNotInterpose) and someone cares to outline them, I'd like to see
> us consider only the "hint" option at this stage. If later users come
> back and say that they require this, this and this, then we can add
> them to a future version of BTP. At the end of the day it's the
> business and security cases that will impose requirements on us from
> above.

I agree.

arkin

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

-- 
----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
CTO,  Intalio Inc.                                     www.intalio.com
The Business Process Management Company                 (650) 345 2777