不同技术之间的两阶段提交（COM+、Java）
首先让我描述一下当前的架构：
应用程序A是一个运行在JBOSS中的java应用程序，并且有自己的数据库（mssql）。
应用程序 B 是一个在 Windows 计算机上运行的 COM+ 应用程序，它也由自己的数据库 (mssql) 支持。
对于某些业务需求，应用程序A必须调用应用程序B。为此，在与应用程序A相同的机器（即JBOSS机器）上安装了COM代理。 JNI 接口允许我们从应用程序 A→B 进行调用。
这就是我们今天所拥有的，而且效果非常好。现在，出现了一个新的业务需求，需要实现如下两阶段提交功能：
将创建一个新的应用程序C（可能是.net应用程序），该应用程序将由自己的数据库支持。应用程序 C 将驻留在第三台服务器上（不在我们的站点中）。
应用程序 C 在事务中调用应用程序 A。应用程序 A 应在考虑嵌入式业务逻辑后执行一些操作。操作包括对应用程序 A 数据库的写入和对应用程序 B 的调用。应用程序 B 执行其他操作（对应用程序 B 数据库）。应用程序 C 根据收到的反馈更新其数据库。现在，如果所有操作均成功，则更改将提交到数据库，否则操作将回滚。
问题很简单（我认为答案更复杂）。考虑到支持每个应用程序的不同技术，这是否可行？我完全理解，如果所有应用程序都用 .Net 或 COM+ 应用程序编写，这是可行的。目前，用另一种技术替换 java 组件并不是一个可行的选择。有什么想法吗？
我们检查了 JNBridge，但我认为它不能提供我们想要的东西。如果应用程序 C 没有问题就好了。
欢迎任何想法/解决方案。您认为最好的选择是什么？
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.
The 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的平台可以支持 WS-AtomicTransaction Web 服务接口吗？某些供应商的产品可以实现 Java/.NET 与该标准的互操作。这可以提供真正的 2PC。
然而，无论您如何使用 2PC，都会产生性能和复杂性成本。仔细观察此架构的耦合含义：尤其是在 2PC 解决阶段发生故障时的问题解决。在不确定的事务解决之前，无法安全地删除锁 - 在某些故障情况下，这可能会花费相当长的时间。
很多时候，您可以重新设计一个问题，这样您实际上就不再需要 2PC——有大量的业务不需要 2PC 就可以完成。
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.