achieving interposition with the web service transactions

[b_]

Hi all,

I've read the following:

Interposition is a way of creating a hierarchy of coordinators, each of which looks like a simple participant to coordinators higher up the coordination tree, yet acts just like a normal coordinator for participants lower down the tree. Coordinators become registered within this hierarchy if the client application sends a CreateCoordination Context message to an activation service along with a valid context. When the receiving activation service creates the new context (and associated coordinator/registration service), it uses the original context to determine the endpoint of its superior coordinator (a.k.a. registration service) and enrolls the new coordinator with it.

on a paper written by Mark Little & Jim Webber (can be found at http://webservices.sys-con.com/read/39751.htm ).


I've went to the documentation that ships with the xts demo, however there is no mention what so ever on this interposition 'approach' mentioned above. Could anyone please suggest some starting examples or point me to the relevant documentation?


Many thanks,
Bryan

[adinn]

I've went to the documentation that ships with the xts demo, however there is no mention what so ever on this interposition 'approach' mentioned above.

There is no mention of interposition in the xts demo documentation because it is not relevant. There is no need to use interposition in this sort of example.

The (basic) client creates a transaction, in the process obtaining a transaction context which identifies the local coordinator. By flowing this transaction context to the Theatre, Restaurant and Taxi services it enables them to negotiate with the coordinator and register/enlist resources in the same transaction. There is no room for any of the activities involved here to interpose themselves between the coordinator and any other activities since no service is invoking another service.

Now, if one of the services -- say the taxi service -- invoked another service -- say a special case for limousine hire -- it might be able to present itself as a coordinator for the limousine service. It would do this by propagating a transaction context which contains a URL for its own coordination service endpoint. In which case it would have to handle registration and enlistment requests from the limousine service. It would also have to propagate the prepare and commit messages it receives from its parent coordinator to the limousine service and compose its response to the parent coordinator based on the limousine service's response. It would also have to ensure that the relevant state was persisted during 2 phase commit and take part in recovery if required.

This would be a lot of implementation for not much gain. Of course, if the taxi (or whatever) service needed to invoke several dependent services with which it was colocated and if none of these services were colocated with the original coordinator then interposition might mean less long distance network traffic giving you a performance gain worth all that effort.

[odin69]

Now, if one of the services -- say the taxi service -- invoked another service -- say a special case for limousine hire -- it might be able to present itself as a coordinator for the limousine service. It would do this by propagating a transaction context which contains a URL for its own coordination service endpoint. In which case it would have to handle registration and enlistment requests from the limousine service. It would also have to propagate the prepare and commit messages it receives from its parent coordinator to the limousine service and compose its response to the parent coordinator based on the limousine service's response. It would also have to ensure that the relevant state was persisted during 2 phase commit and take part in recovery if required.

Hey adinn,
from what I understand what you say is, that the taxi service acts as a coordinator to the limousine service and as an inferior coordinator to the coordination service of the basicClient. In this case does the taxis service has to implement the functionality of a coordinator or does the taxi service enlists his own coordinator as a participant to the superior coordinator so that the statements prepare and commit/rollback are passed directly to the inferior coordinator of the taxi service and this way to the limousine service? It seems to doesn't make sense to implement the functionality of the coordinator twice regarding the fact that the functionality of a coordinaotr already is implemented. So basicaly is there a way to enlist the coordinator of the taxi service as an inferior to the superior coordinator?

thx

[jhalliday]

> So basically is there a way to enlist the coordinator of the taxi service as an inferior to the superior coordinator?

Not right now. The JTA has a subtransaction coordinator implementation but XTS does not. It will do eventually though - we need it to implement the reverse side of the transaction bridge.

[b_]

Thanks for your replies. What i basically wanted to know was if there is a way to enlist the coordinator of the taxi service as an inferior to the superior coordinator.

I have just extended a framework (that allows you to define local transactions; referred to as long lived transactions) to implement the Participant interface. The idea behind it is to have an 'inner' long lived transaction running within a broader scope of the distributed transaction, with the aim of providing more efficiency and overall flexibility.

Next i wanted to benchmark the performance for my framework with the interposition functionality mentioned in the above paper. But it seems that this cannot be done after all.

[odin69]

"jhalliday" wrote:
Not right now. The JTA has a subtransaction coordinator implementation but XTS does not. It will do eventually though - we need it to implement the reverse side of the transaction bridge.

Is there an estimated date when the sub-coordinator will be implemented in XTS? And do you mean by reverse side of the transaction bridging the case JTA -> WS-TX whereas the WS-Coordinator is in the role of a sub-coordinator?

thx

[jhalliday]

Right now we are focused on stabilizing and testing existing functionality ahead of the EAP 5.0 release. Once that's taken care of we will get back to new features. Completing the bridge is pretty high on that list, so probably late Q2 or Q3 would be my guess. The current bridge is WS-AT driving XA, which was easy since the JTA already had a subtransaction coordinator. Making it work in the other direction needs a subtransaction coordinator in XTS plus some thought on the problem of ensuring transactions behave correctly when you create loops eg. XA->WS-AT->XA. Looks like we have a busy summer ahead :-)