Re: interposition requirements

[Sazi Temel <sazi.temel@bea.com>]

As far as I remember, we were identified (at the f2f meeting) four actors:
         1) Initiator
         2) Coordinator
         3) Participant
         4) Service

with the following basic roles:
         1) Initiator is the actor which starts the transaction, makes 
business requests which in turn may include the other entities into the 
transaction.
         2) Coordinator is the transaction manager associated with the 
initiatiors.
         3) Service is an actor with a business interface that the 
initiator invokes/make-requests/consumes.
         4) Participant is an entity with a (sub)coordinator role 
associated with Service.

These antities may or may not be at the same location but an association as 
described above exists.

With these actors and roles in mind I have inlined rest of my thoughts below...

--Sazi

1 +0100, Mark Little wrote:
>
>I don't think anyone was advocating the mutlilayered approach ( of root 
>and sub-coordination ) within an enterprise / LAN ( Mark your comments 
>about performance are correct in this scenario ).
>
> From what I've heard at least Jim and Savas we're advocating 
> interposition across the board. In general, why should a root coordinator 
> know of any participants it didn't talk to directly? Why expose such 
> application implementation/configuration information to it? Certainly if 
> I was a web services builder I wouldn't want the whole world (or even my 
> own organisation) to know that I may federate the work between different 
> web services even though applications come through a single web service 
> initially. If I have no control over this, and the BTP protocol is simply 
> going to expose all of this implementation detail to the coordinator (and 
> remember, as far as I'm concerned as an untrusting guy, the coordinator 
> may very wll expose the registered participant information externally) 
> then I'm not going to use BTP at all. In general, registering directly 
> with the root coordinator should be the sole responsibility of the 
> application services: only they have the necessary semantic information 
> to know whether this makes sense in terms of security/trust, recovery, 
> and performance.
>The concerns being voiced regarding performance at the f2f were about an 
>A,B,C scenario where A,B and C reside in different domains and the 
>termination protocol had to follow the transaction propagation through the 
>services. The point I was making at the f2f was that the transaction 
>protocol and coordination should be separate from the invocation trace (as 
>it is the Choreology diagram Alistair put together )

Agreed on  that the transaction coordination flow should be separate from 
sercvice invocations flow (they may be the same in case the service and 
participant interfaces implemented in the same entity, but still as far as 
the coordinator concerned it is talkiung to participants/sub-coordinators 
not to the services)

>I think that if A, B and C decide to register different web services as 
>participants (A', B', and C') in protocol then they don't need to be told 
>of the termination at all.

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)

>  However, if A' talks to other web services at the backe
>nd it should coordinate them, and not the root coordinator.
>For Example Service A invokes Service B that subsequently invokes Service 
>C, the coordination of a transaction is separate and does not need to 
>follow the same flow  - i.e. A's coordinator can communicate with B and 
>C's sub-coordinators to terminate a transaction without relying on B to 
>coordinate C on its behalf.
>
>If B doesn't register with A, then C has no choice but to register with A. 
>However, this then raises the question: why did A talk to B in the first 
>place if it's not BTP aware?

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.

>By being BTP aware, I'm assuming that a service will participate within 
>the cohesion, i.e., some state changes will occur that need to be 
>coordinated to either "commit" or "roll back". BTP aware shouldn't simply 
>mean that a service can receive and propagate a context.

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.

>Therefore, I would say that any service that is BTP aware should, either 
>as the first thing it does when receiving a context for the first time or 
>just before it propagates the context on, register itself with the 
>coordinator referred to in the received context (which may not be the root 
>coordinator). It then needs to modify the context it's about to send to 
>refer to itself (or whatever sub-coordination web service it uses) such 
>that the services it talks to can register with that.
>

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.

>To accomodate the case where interposition isn't required, either because 
>it doesn't make sense in a specific domain, or because the implementation 
>of the service doesn't support sub-coordinator logic, we could look at 
>some kind of attribute (on a per service basis) which essentially says "do 
>interposition" or "don't do interposition".

Can this attribute be in the context ?
>To lay this out explicitly the discussion as I remember centred around a 
>chain where Web Services A (initiator with root coordinator) calls Web 
>Service B ( with sub-coordinator and multiple participants ) in a 
>different domain, that subsequently calls Web Service C ( with a 
>sub-coordinator and multiple participants of its own ).

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.)
>The question was  whether the subcordinator in C registers with the root 
>coordinator in A or if the sub-coordinator in B masks the relationship 
>required for coordination between A and C. In my mind you should allow B 
>to decide if it wants to mask C or not i.e. propagate its own 
>sub-coordinator to C or the root-coordinator from A that was propagated to it.

Yes.

>Agreed. See above.
>There are some issues to do with security in this model surrounding C 
>gaining access to A ( I think a concern that Bill you brought up) . This 
>is a valid concern but I think there are ways to address this in terms of; 
>if C tries to register with A's coordinator then if the request contains 
>transactional context recognisable by the root coordinator at A and can 
>accept a URI of the subordinator at C, are there concerns here?
>
>Security/trust is a huge whole in the BTP protocol, so you're making an 
>assumption that just because A recognises the URI means it trusts C. Given 
>this assumption, if C wants to register directly with A then it should be 
>allowed to. My point is, though, that this has to be the conscious 
>decision of C. By default, this shouldn't be the case though.
>I would make the case that A's root coordinator now sends the appropriate 
>termination message to C (the URI provided, through the BTP termination 
>protocol to C that has declared its ability to be BTP aware through its 
>registration) as they are enlisted - if C is bogus why does A care, and 
>how did C get a GUID identifier for the transaction initiated by A ( it 
>must have been through a trusted partner ).

I agree on this, hope that the security committee will come with some 
resolution...

>Actually, I think A does care if it suddenly starts coordinating the 
>termination of a participant who shouldn't (e.g., for legal reasons) be 
>allowed into the protocol. Being involved in the protocol gives you 
>knowledge about its outcome (snooping), and the capability to adversely 
>affect it; saying that A shouldn't be concerned about bogus participants 
>is not sufficient. However, as I said above, security is something that 
>isn't going to addressed sufficiently in BTP as far as I can see.
>I am not suggesting there are not other concerns surrounding this and I am 
>sure there is need for further discussion on Security and the implications 
>of the model, but I do agree that based on role definitions the use of 
>"interposition" as Mark laid out, this is an appropriate model to be 
>supported by BTP.
>

Yes.
>I think there was a lot of discussion at the meeting that blurred the 
>lines between the Service, Sub-Coordinator and Participant roles ( 
>especially between the Choreology guys Salas and myself ). I am now 
>wondering if we have to explicitly define the role of sub-coordinator 
>distinct from Participant ( when arguing last week for participant 
>enrollement I was arguing for multiple participant registrations to the 
>coordinator (root) based on the Participants that reside in different 
>trusted domains and act as sub-coordinators for all the sub-participants 
>associated to the service invocation, within their domain ).

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.

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

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

>All we need to say is that if you propagate the context then you become 
>responsible to coordinate for those subsequent recipients unless (and this 
>may require thought) some "attribute" set by the application says not to, 
>and in which case you send the context as you got it (but, as I said 
>before, this context may not actually refer to the root coordinator anyway).

Agreed.

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

--Sazi