interposition

(i) a participant takes part in the termination protocol of a cohesion, i.e., receives the do/undo calls. When it receives these calls it applies them appropriately to the work it has done on behalf of that cohesion.

(ii) a coordinator issues the termination protocol messages to the registered participants. It must save (make durable) sufficient information to ensure that the protocol can be completed in the event of a failure [do we assume a presumed abort-like protocol? I think we do] of either itself or a participant(s).

Now, from the point of view of a coordinator, all it deals with are participants. Likewise, all a participant sees is the coordinator. In addition (and importantly), the work a coordinator does is distinct from the work a participant does.

When a service receives a context from an initiator (or indirectly from some other entity) that context essentially identifies a coordinator (URL). The service may enlist itself (or some other distinct entity) as a participant in the cohesion using this addressing information.

(1) it only does work in a "contained" manner which does not involve any (BTP) calls outside of the service.
(2) in addition to using and manipulating resources locally, in order to fulfill the request (for example) it requires to call out of itself to other BTP-aware services.
(3) it is a "router" BTP-aware resource, requires to call out of itself to other BTP-aware services

As soon as a BTP-aware service (A) calls out to other BTP-aware services (B), it is required to propagate a context to them in order that they too can take part in the cohesion. The simplest solution to this is that whatever context A received it propagates "as is" to B; therefore, whichever coordinator A enlists a participant with (AP), B will also enlist its participant with (BP).

However, for a number of reasons it may be necessary or desirable for AP to interpose itself between the coordinator it deals with (C0) and for it to handle BPs' enlistment and its termination protocol itself (or to use some appropriate entitity). In this case AP on behalf of A becomes a sub-coordinator for B, and the context that A sends to B will contain AP as the coordinator. Importantly, the fact that the coordinator in the context has changed is transparent to B.

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.

Therefore, it is impossible for a normal participant to simply be a subcoordinator because the roles are distinctly different. A subcoordinator may be a participant though. As such, it is not possible for a participant alone (and spontaneously) to do subcoordination for other services; it is a decision of the service/participant implementer to embue the cohesion coordination logic on a participant and turn it into a subcoordinator.

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

It is my belief that using interposition should be up to an individual web service. The fact that a "normal" participant cannot simply decide to do sub-coordination and must be implemented accordingly, means that the implementer made a conscious choice when doing so; they probably didn't do it because it simply seemed like a good idea at the time. I would assume that when coming to that decision the implementer weighed up the choices, examine the web service and how it was intended to be 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.

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

It has been suggested that a coordinator may insist that a flat registration structure be used, i.e., no interposition, and any participant that cannot abide by this must (for example) throw an exception. However, as stated above this cannot really be enforced (even within a trusted domain) and is contrary to the way applications which use web services work.

In my opinion, the strongest argument for only allowing a "hint" is the fact that the implementer went to the effort of using interposition when constructing the web service. This shows pre-thought about the semantics of what it means to be involved in a BTP transaction and what information can be exported to the outside world. Attempting to force some override implies a "I know better than you" approach from the coordinator, and that simply isn't going to be the case, especially in a loosely coupled environment.

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.

business-transaction message