乱想：由JTA蔓延到EJB

为什么80%的码农都做不了架构师？>>>   

最近一个项目服务端原来是用EJB + SSH 转到Play 1.x上，而且原框架是分布式部署，整个程序理论上可有N个节点，实际上最多有五个节点的调用。项目包括Delphi客户端，Java服务端，与Java数据中心。EJB就是运用在服务端与数据中心。在框架迁移的时候不免设计到远程调用的修改以及事务问题。 

这里不讨论具体的实现，而是关于JTA与EJB的概念。说实在的，从踏上Java这条道，以前还没有遇到过EJB，可能这与所从事的行业都是互联网公司有关吧。对EJB知之甚少。不过感觉很神秘，很笨重的，很古老的样子。 

这次迁移框架才不得不看看EJB相关的东西，不过一看就头痛。断断续续的看了一些东西，在改事务的时候，看到了JTA，其中产生了一个疑问，事务回滚时setRollBackOnly()与rollback()的应用场景的区别。可惜一直没有找到答案，只好回去看源码，在网上找JTA文章，不断刷搜索引擎，终于发现两篇好文章

JTA 深度历险 - 原理与实现 http://www.ibm.com/developerworks/cn/java/j-lo-jta/

EJB到底是什么，真的那么神秘吗？？http://blog.csdn.net/jojo52013145/article/details/5783677

前者解析了JTA的原理，后者揭开了EJB神秘的面纱。EJB用大白话来说，就是“把你编写的软件中那些需要执行制定的任务的类，不放到客户端软件上了，而是给他打成包放到一个服务器上了”。回看现在修改的项目，正是符合这个概念！不就是将delphi中部分代码放到Java端了么…… 

EJB使用的技术是RMI(Remote Method Invocation)，基于Java对象的序列化与RPC(Remote Procedure Call)。从EJB的部署来看，每个机器上放几个类，的确是分布式集群，但是网络开销是免不了，我感觉还不如做负载均衡的好…… 

不过EJB的分布式事务倒是挺省事，开一个UserTranaction，每个节点之间就不用单独考虑事务了。这也正式JTA的威力。 

在迁移项目的过程中，对应JTA，对于远程调用，只好用事务补偿的方法，对新增数据做Undo操作，对修改数据做Redo操作，另外调用也必须是幂等性。

转载于:https://my.oschina.net/markho/blog/498264