Re: interposition requirements

[Mark Little <mcl@arjuna.com>]

> A services is a service, not a participant (participant, per f2f meeting
> definition are the entity that has the sub-coordinator role) as far as the
> protocol concerned. Again, if the service also implements the participant
> interface that makes them the same entity (but for the coordinator they
are
> different)

No. If we want to distinguish between a participant and a service then fine,
but a participant is *not* a sub-coordinator by default. It may take on that
role (which isn't trivial), but it's not part of the participant role by
default. BTW, if something talks SOAP and understands XML then why isn't it
a Web Service?

> I assume you mean coordinator A, and participants (the sub coordinators) B
> and C. A will only talk to B if B registered with A.

Again no. You're confusing the participant and service role yourself here. A
and B and *services*, and need to be BTP aware to receive the context and
the termination messages. So my original question stands: if B isn't BTP
aware then why did A talk to it in the first place? If somehow it isn't BTP
aware then it can't understand the context and can't flow it on anyway.


> I think it also means that there is an interface between a Service and its
> participant coordinator and the service will communicate its state to its
> participant.

That's implementation dependant. Certainly the participant needs access to
the "transactional" state that was updated by the service, but it doesn't
need to talk to the service to do this.

> With the roles defined as above, a service will not register with the
> (main) coordinator, it will let its participant coordinater know that it
is
> in a transaction so that the participant will register with the
> coordinator. A service does not know how to coordinate it knows how to be
> coordinated.

Again I'd say that is implementation dependant. Something has the 2PC
interface (and lets call it the participant for the sake of argument), and
something has the business-logic interface (and lets call that the service).
The two don't need to talk to each other directly for coordination.

> Can this attribute be in the context ?

It could be.


> I am not sure what you mean by participant and the sub-coordinator when
you
> say "with sub-coordinator and multiple participants", to me they are the
> same. I do not think we have a fifth actor (in addition to above actors)
> that is called sub-coordinator, when ever the trem sub-coordinator used ,
> it  means a participant ( a participant coordinator, a local coordinator
etc.)

No. Subcoordination is an implementation decision for the participant, but
being a participant does not imply subcoordination functionality.


> I suggest to use the sub-coordinator (a coordinator different than the
main
> coordinator which is participating in a BT) in stead of participant. Looks
> like its role is participating into transaction as an a sub-coordinator.
> The term participant may be used as an alias both for a service and a
> sub-coordinator as it fits into a particular context.

See above for why I disagree.

>
> >I don't think so: as far as a coordinator is concerned, a sub-coordinator
> >looks *exactly* like a participant.
>
> Yes, because they are the same...

No they are not.

>
> >As far as a participant is concerned, it can't tell the different between
> >a sub-coordinator and a root coordinator.
>
> This participant looks like a service...

"service"?

Mark.

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