RE: interposition requirements

[Mark Potts <mark.potts@talkingblocks.com>]

Mark / Bill

 

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

 

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.

 

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

 

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

 

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 think we are all in agreement or at least close.....unless I missed something.

 

 

-----Original Message-----
From: Bill Pope [mailto:bpope@bowstreet.com]
Sent: Monday, April 30, 2001 10:23 AM
To: 'Mark Little'; bt models
Subject: RE: interposition requirements

 

I agree with you and so won't try to defend the position.  Just wanted to set the stage for the discussion.  I don't remember

who was advocating this at the meeting, anyone?

 

Regards,

=bill

-----Original Message-----
From: Mark Little [mailto:mcl@arjuna.com]
Sent: Monday, April 30, 2001 12:57 PM
To: Bill Pope; bt models
Subject: Re: interposition requirements

 

Mark,

One thing I forgot to include in my original reply.  There are two places that BTP might be used.  To coordinate calls among disparate, external web services and to coordinate calls to XML based services within an organizational boundry.   The registration of sub-participants with the root coordinator was being proposed as an optimization for the latter.

If all Web Services are within the same domain (e.g., on the same LAN), then there's no performance advantage, but I don't think there's much of a performance disadvantage either in this world of modern, multi-threaded operating systems. In addition, if multiple services happen to be co-located on the same node as a subordinate coordinator then intra-node communication is typically short-cut by the OS so that it doesn't go anywhere near the network. (BTW, I'm assuming that a single organizational boundary is connected only be a fast LAN, otherwise the communication performance argument comes back in.)

 

However, in the arena of a single organizational boundary I'd still say that the separation of concerns, and isolation of business logic is important: why should the root coordinator know about sub-participants? That's implementation specific. Even within an organizational boundary, one department may not trust all of the Web Services from another, and may not want root coordination information to be propagated around the organization.

 

I would prefer us to keep things simple and have interposition as the default, and if an application wants to register a service directly with the root, then it can do it at the application level.

 

Cheers,

 

Mark.

 

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