Re: interposition requirements

[Mark Little <mcl@arjuna.com>]

> I haven't made appreciable changes based on the ongoing interpostion
> argument - mostly I just merged the original document and Pal's summary,
> plus some tidy-ups.  There is some further work to be done though.  I
> mentioned the need for  something on the potential separation of concerns
> (interfaces ?) on the client side in the covering note - that would seem
to
> partly line-up with the concerns here.

Agreed.

> I believe a fundamental of the whole approach is that from the viewpoint
of
> the inter-party protocol (counting both the application messages augmented
> by the context, and the btp messages themselves) we do not know, cannot
> require and cannot forbid any particular structuring or even distribution
of
> the entities involved. We have identifiable roles/interfaces and (for the
> btp messages at least), addresses.  Anything else is behind the screens.

Correct. Being a sub-coordinator is a decision the participant makes. When
it enlists it may enlist itself as a subcoordinator, enlist a separate
subcoordinator service (and then presumably enlist itself with that), or
simply enlist directly with the coordinator it got in the context. However,
as far as any participant is concerned, it shouldn't be able to tell the
different between a root coordinator and an interposed coordinator: all it
gets is a context containing (for example) a URL. If that URL is rewritten
by an sub-coordinator to refer to itself rather than the coordinator the
sub-coordinator received then subsequent participants can't tell.

Mark.

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