Question

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

我想在我的新系统（REST / WS）中重现这种机制，以便Swing客户端/ Web（未来）可以和原来一样工作。

例如：

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。

我可以选择的几个选项

将CORBA迁移到RMI - ＆gt;所以当前系统所需的更改是最小的，但事务管理，连接池，保留状态需要自己做。
将CORBA迁移到有状态EJB - ＆gt;比较RMI需要更多更改，但更好，因为我可以使用容器管理连接池，以更好的方式维护状态。
将CORBA迁移到有状态Web服务（SOAP） - ＆gt;更具未来感，但需要进行大量更改 - 我如何将IDL转换为WSDL，并将调用委托给实现层
将CORBA迁移到REST - ＆gt;如果可能，最需要的是 - 但迁移所需的时间量很大，从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执行此操作。是的，这花费了大量的时间，测试和努力，但它有两个奖励：首先，移动到网络将更容易，听起来时间即将来临。其次，那些追随你的人比裸露的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交易。如果可能，您不想自己处理交易管理。

最终，因为我确信每个人都会同意，所以选择是你自己做什么，而且没有＆＃34;对＆＃34;或＆＃34;错误＆＃34;尽管有上述观点。如果是我（而且不是），我会问自己和我的客户的两个重要问题：

这是合同还是临时约定，如果是，那么这个术语是什么？当他们想要进行额外更新时，我是否会先获得同一系统的另一份合同？（换句话说，我要花多少钱才能摆脱这个？我花了多少时间？如果它是长期的，那么我会选择4或3，否则3或者2会更好。）
为什么要摆脱CORBA？＆＃34;因为它已经老了＆＃34;这是一个诚实的答案，但是摆脱“老热”的动力是什么？＆＃34;他们是否计划在未来扩大该系统的使用范围？是否有一些许可即将到期，他们只是想保持灯亮？是不是因为他们不想把这个转发给一些年轻的程序员，他们可能不知道如何处理像这样的低级别的东西？您希望系统在两年，五年或更长时间内完成什么工作？

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

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

1 个答案: