亂想：由JTA蔓延到EJB

最近一個項目服務端原來是用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操做，另外調用也必須是冪等性。