Two-phase commit between different technologies (COM+, Java)

Let me first describe a bit the current architecture:

Application A is a java application running in JBOSS and has its own database (mssql).

Application B is a COM+ application running in a Windows machine that also it is supported by its own database (mssql).

For certain business requirements, application A has to call application B. For this purpose, a COM proxy is installed at the same machine with Application A (i.e. JBOSS machine). A JNI interface allows us to make the call from Application A-->B.

This is what we have today and it works perfectly. Now, a new business requirement emerged, and it is necessary to implement a two-phase commit functionality as follow:

A new application C is going to be created (possibly a .net application) that is going to be supported by its own database. Application C is going to rest on a third server (not in our site).

Application C calls Application A in a transaction. Application A should perform some actions after taking consideration the embedded business logic. Actions include writings to the application A database and a call to Application B. Application B performs additional actions (to application B database). Application C updates its database based on feedback received. Now, if all actions are successful the changes are committed to the databases, else the actions are rollback.

T开发者_StackOverflowhe question is simple (the answer is more complicated I think). Is this feasible, considering the different technologies supporting each Application? I perfectly understand that if all applications were written in .Net or as COM+ applications, this is feasible. Replacing the java components with another technology is not a viable option at this point. Any ideas?

We checked JNBridge but I do not think it can provide what we want. It would be fine if Application C was not an issue.

Any ideas/solutions are welcome. What are the best options in your opinion?

Could your platforms support a WS-AtomicTransaction Web Service interface? Java/.NET interop with this standard is possible with some vendors products. This could give true 2PC.

However no mnatter how you do 2PC there will be performance and complexity costs. Look very carefully at the coupling implications of this architecture: especially at problem resolution when failures occur during the 2PC resolution phase. Locks cannot be safely removed until in-doubt transactions resolve - in some failure scenarios this can be quite an extended period.

Very often you can re-architect a problem so that you don't actually need 2PC - there's an awful lot of business out there done without 2PC.