java - 将 CORBA 应用程序迁移到现代 Java 技术(Rest/SOAP/EJB)

Question

我需要将遗留 CORBA 系统迁移到任何最新的 Java 技术。我面临的主要问题是在建议的系统中提供长期交易(db)。当前，客户端(Swing App)保留 CORBA 服务对象并在实际提交/回滚所有 txn 之前执行多个 db txn。服务层始终保持连接对象的状态以完成交易。

我想在我的新系统 (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) --> 更具 future 感，但需要进行大量更改 - 我如何将 IDL 转换为 WSDL，并将调用委托(delegate)给实现层

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 ，并生成您自己的 stub 和领带，尽管不推荐这样做，但这是有充分理由的。这多年来一直不是一种流行的做法，可能需要定期重新生成 stub 和联系，并且可能需要了解应用服务器的低级功能。即使在这里，您也会需要 XA 事务。如果可能，您不想自己处理事务管理。

最终，我相信每个人都会同意，选择权在您，尽管有上述观点，但没有“正确”或“错误”的方法。如果是我(现在不是)，我会问我自己和我的客户两个重要的问题:

1. 这是契约(Contract)还是临时聘用，如果是，期限是什么？当他们需要额外的更新时，我会优先选择同一系统的另一个契约(Contract)吗？ (换句话说，我将从中得到多少钱与我花费多少时间？如果这是长期的，那么我会选择 4 或 3，否则 3 或 2 会更好.)

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

(好的，所以这不仅仅是两个问题 :D)