将 CORBA 应用程序迁移到现代 Java 技术（Rest/SOAP/EJB）

Question

我需要将旧版 CORBA 系统迁移到任何最新的 Java 技术。我面临的主要问题是在提议的系统中提供长寿命事务（db）。目前，客户端（Swing App）保留 CORBA 服务对象并在实际提交/回滚所有 txn 之前执行多个 db txn。服务层保持连接对象的状态通过out来完成事务。

我想在我的新系统 (REST/WS) 中重现这种机制，以便 Swing 客户端/Web(future) 都可以正常工作。

例如：

try {
    service1.updateXXData(); // --> insert in to table XX
    service2.updateUUData()  //--> insert in to table UU
    service1.updateZZData(); // --> insert in to table ZZ
    service2.updateAAData(); // --> insert in to table AA

    service1.commit(); //  con.commmit();
    service2.commit(); // con.commmit();

}
exception(){
    service1.rollback(); // con.rollback();
    service2.rollback(); // con.rollback();
}

现在我想将 CORBA 迁移到任何现代技术，但我仍然在寻找解决方案。 （担心的是客户不想对服务层或数据库层进行任何更改），他们只是想删除 CORBA。

可供我选择的几个选项是

1. 将 CORBA 迁移到 RMI --> 使当前系统所需的更改最小化，但事务管理、连接池、保持状态需要我自己做。

2. 将 CORBA 迁移到有状态 EJB --> 比较 RMI 需要更多更改，但更好，因为我可以使用容器管理的连接池，以更好的方式维护状态。

3. 将 CORBA 迁移到有状态 Web 服务 (SOAP) --> 更具未来感，但需要进行大量更改 - 如何将 IDL 转换为 WSDL，并将调用委托给实现层

4. 将 CORBA 迁移到 REST --> 如果可能的话，这是最理想的 - 但是迁移所需的时间量很大，代码更改需要从 UI 层到服务层。

非常感谢您

Answer 1

我选择选项的顺序（从最好到最差）是 4、3、2 和 1，但是如果人为可能的话，我会避免使用有状态的 bean 或服务。

我将详细介绍您必须执行的操作的实现细节。

对于这些解决方案中的任何一个，您都必须使用XA-compliant data sources and transactions，以便保证符合 ACID，preferably from an application server so you don't have to generate the transaction yourself。这应该是对您现有应用程序的改进，因为它几乎肯定不能保证这一点，但请注意，根据我的经验，人们投入了大量的黑客来彻底改造 JTA，因此请注意这一点。

对于 4，您需要使用 container-managed transactions with XA。您可以通过injecting a @PersistenceContext backed by a JTA connection 执行此操作。是的，这需要花费大量的时间、测试和精力，但它有两个好处：首先，迁移到 Web 会容易得多，而且听起来时间快到了。其次，与纯 CORBA 和 RMI 相比，那些在你之后的人更有可能精通更新的 Web 服务技术。

对于 3，您还需要使用 container-managed transactions with XA。 SOAP 不会是我的首选，因为它使用非常冗长的消息并且 REST 更受欢迎，但它可以做到。但是，如果它是有状态的，则必须使用bean-managed transactions instead，然后使用hang on to resources across web service calls。这很危险，因为它可能会导致整个系统死锁。

对于 2，您可以采用两种方式，一种是使用 container-managed transactions with XA，另一种是使用 stateless session facade for a stateful EJB。您可以use a client JAR for your EJB 并将其与 Swing 应用程序打包。最好使用无状态外观，因为它将减少应用程序服务器上的负载。请记住，您也可以生成web services from stateless EJB beans，基本上将其变成#3。

对于 1... 好吧，祝你好运。可以use RMI to interface with EJB's，并生成您自己的存根和领带，尽管不推荐这样做，这是有充分理由的。多年来，这一直不是一种流行的做法，可能需要定期重新生成存根和关联，并且可能需要了解应用服务器的低级功能。即使在这里，您也需要 XA 事务。如果可能，您不想自己处理事务管理。

最终，我相信每个人都会同意，您可以选择做什么，并且没有“正确”或“错误”的方式，尽管有上述观点。如果是我（不是），我会问我自己和我的客户两个重要问题：

1. 这是合同还是临时订婚，如果是，条款是什么？以后当他们需要其他更新时，我是否会优先选择同一系统的另一份合同？ （换句话说，我要从中得到多少钱与我要花多少时间？如果是长期的话，那么我会选择 4 或 3，否则 3 或 2 会更好.)

2. 为什么要摆脱 CORBA？ “因为老了”是一个诚实的回答，但摆脱“老辣”的动力是什么？他们是否计划在未来扩大该系统的使用范围？是否有一些许可证即将到期，他们只想保持亮灯？是不是因为他们不想把这个丢给一些可能不知道如何处理这种低级东西的年轻程序员？您希望系统在两年、五年或更长时间内做什么？

（好的，这不仅仅是两个问题：D）