Re: interposition requirements

[Mark Little <mcl@arjuna.com>]

 

Mark (2)
I always assumed that different web services sites has different participants (sub-coordinator), at least one, but might have more. Looks like it is one of the condition to be a BTP aware site (application) thus I do not see a sub-coordinator propagation, may be I misunderstand what you mean by sub-coordinator propagation...

Not sure which Mark you mean, but I'll take a stab at it: first I don't see that the participant and the sub-coordinator have to be different; if a participating web service wants to propagate the context to other, back-end (for example) web services then as well as doing it's own work when it's told to "prepare" it sends this message to those back-end services, i.e., it acts like a sub-coordinator. However, in order to do this, when it propagates the context to these additional services it needs to re-write the context slightly so that the coordinator URL is no longer the one that it received, but itself. Obviously this means that the web service must support the coordinator interface and appropriate functionality; if it can't then it can't do interposition - it's as simple as that.

We (at the f2f meeting) almost agreed on that there are interfaces for the roles such as initiator, coordinator, participant (sub-coordinator) and the service then it is up to the application (and web service site) to implement these interfaces as a single entity or different entities..

I don't think a participant *has* to be a sub-coordinator. If it's a leaf node, and does no further invocations to other BTP-aware services, then it's not coordinating anything other than its own work. Even if it does propagate the context, it may be physically unable to act as a sub-coordinator anyway.

Looks like there are pros and cons for both approach (flat structure or tree like structure for coordination), may be it is better to let the initiator make known its wish whether it wants to flat or tree like structure and let the participants try to do their best to obey this wish (propagate this wish to other participants)..

I don't think this is a decision that the initiator can, or should, make. It depends upon too many factors that the initiator can't and shouldn't be aware of: implementation (does the web service support sub-coordinator operations), business logic (what's going on at the back-end), connectivity (can the root actually talk to all participants), ... I believe this is a decision that only the propagating web service should make (possibly with some configurable option based on the application.)

It is really not more than a wish to have a flat transaction hierarchy from the initiators point of view since any of the sub-coordinators can always hide the sub-transactions from the main coordinator easily without violating any protocol syntax (if we make a rule that it will always be a flat structure, participants will violate the rule but still working ok)

OK, as long as the requirement from the initiator is only a hint, and can be ignored by the participating web services, I don't have a problem with this.

I also noticed that we have been using participant and sub-coordinator interchangeable (which is ok since they are the same entity), can I suggest to use the sub-coordinator (and/or local coordinator) in the body of the protocol doc as an alias for participant?

I've tried to use participant (web service) and sub-coordinator separately, because one may not be the other.

 

Mark.

 

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