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

Sat*_*eri 6 java ejb corba rmi ws-transaction

我需要将传统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();
}
Run Code Online (Sandbox Code Playgroud)

现在我想将CORBA迁移到任何现代技术,但我仍然逍遥法外,为此寻找解决方案.(关注的是客户端不希望对服务层或数据库层进行任何更改),他们只是想删除CORBA.

我可以选择几种

  1. 将CORBA迁移到RMI - >以便当前系统所需的更改最小化,但事务管理,连接池,保留状态需要自行完成.

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

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

  4. 将CORBA迁移到REST - >如果可能,最需要 - 但迁移所需的时间很长,从UI层到服务层需要进行代码更改.

非常感谢你提前

Bra*_*rad 5

从最佳到最差,我选择选项的顺序将是4,3,2和1,但是如果有可能的话,我会避免使用有状态的bean或服务.

我将详细介绍您需要做的详细信息.

对于任何这些解决方案,您必须使用符合XA的数据源和事务,以便保证ACID合规性,最好是从应用程序服务器,因此您不必自己生成事务.这应该是对现有应用程序的改进,因为它几乎肯定不能保证,但是请注意,根据我的经验,人们将大量的黑客攻击基本上重新发明JTA,所以要小心.

对于4,您将要使用XA的容器管理事务.您可以通过注入@PersistenceContextJTA连接支持来执行此操作.是的,这花费了大量的时间,测试和努力,但它有两个奖励:首先,移动到网络将更容易,听起来时间即将来临.其次,那些追随你的人比裸露的CORBA和RMI更有可能精通新的Web服务技术.

对于3,您还希望将容器管理的事务与XA一起使用.SOAP不是我的首选,因为它使用非常详细的消息而REST更受欢迎,但它可以完成.但是,如果它是有状态的,则必须使用bean管理的事务,然后在Web服务调用之间挂起资源.这很危险,因为它可能会使整个系统陷入僵局.

对于2,您可以采用两种方式,通过使用无状态会话Facade为有状态EJB使用容器管理的事务与XA.您可以将EJB的客户端JAR用于 Swing应用程序并将其打包.最好使用无状态外观,因为它会减少应用程序服务器上的负载.请记住,您也可以从无状态EJB bean生成Web服务,实际上将其转换为#3.

1 ...好吧,祝你好运.可以使用RMI与EJB进行交互,并生成自己的存根和绑定,但不推荐这样做,并且有很好的理由.这多年来一直不是一种流行的做法,可能需要定期重新生成存根和联系,并且可能需要了解应用服务器的低级功能.即使在这里,您也需要XA交易.如果可能,您不希望自己处理事务管理.

最终,正如我相信每个人都会同意的那样,尽管有上述观点,但选择权归你所做,并且没有"正确"或"错误"的方式.如果是我(事实并非如此),我会问自己和客户的两个重要问题:

  1. 这是合同还是临时参与,如果是的话,这个术语是什么?当他们想要进行额外更新时,我是否会先获得同一系统的另一份合同?(换句话说,我要花多少钱才能摆脱这个?我花了多少时间?如果这是一个长期的话,那么我会选择4或3,否则3或2会更好.)

  2. 为什么要摆脱CORBA?"因为它已经老了"是一个诚实的答案,但是什么是摆脱"旧的热度?"的推动力?他们是否计划在未来扩大该系统的使用范围?是否有一些许可即将到期,他们只是想保持灯亮?是不是因为他们不想把这个转发给一些年轻的程序员,他们可能不知道如何处理像这样的低级别的东西?您希望系统在两年,五年或更长时间内完成什么?

(好的,这不仅仅是两个问题:D)