关于跨应用事务

在项目中对于事务控制有如下3种:
1.简单的单项目,单服务,单数据源事务控制,如图:



2.单项目,单服务,多数据源事务控制,如图:


这种方式如果我们使用了spring容器的话,那么jta的支持会很好的解决此类事务问题.

3.多项目,多服务,多数据源间的事务控制,如图:


这个需要支持分布式事务,如果采用的是ejb的话,能够得到很好的解决,大家统统在以个事务中. 但是如果是项目采用的是spring作为容器或者多服务组件是以webService的方式调用的话,一般采用的事务处理方式是这样的,让我们看个实例:

假设核心系统中提供了转账服务，而自动柜员机（毫无疑问相对核心系统来讲是一个外围应用）和个人网银（也是一个外围应用）都需要提供转账服务，开发人员当然可以在自动柜员机和个人网银这两个应用中分别根据核心系统中转账的逻辑重新实现一遍转账逻辑，但这样做实在是挫了，如果转账逻辑有变动，那么则需要变动核心系统、自动柜员机和个人网银3个应用，这当然不是我们想要的；那我们再进一步思考下，既然核心系统已经提供了转账服务，那自动柜员机系统和个人网银系统就直接调用转账服务就好了，对，这样的方案解决了之前维护复杂的问题，但其他问题接踵而来，可能自动柜员机在转账过程中，除了要调用核心系统的转账服务外，还需要完成自身的一些操作，比如记录ATM操作日志等，那如果调用转账服务成功，而记录ATM操作日志失败，那这种情况下该怎么处理？首先可用从ATM操作角度，必须告诉客户这次ATM转账操作失败了（因为ATM操作日志没有记录），但调用核心系统的转账服务已经成功，也就意味着资金已经从A账户流转到B账户了，一个选择就是做一个反操作（事务补偿），从B账户转账同样的金额给A账户，这个选择有两个有待思考的地方：如果反操作失败怎么办？就算反操作成功但有了两笔转账的操作记录，如果将操作记录暴露给客户查询，那客户肯定会投诉，至少不爽吧；另一个选择那就是将客户操作ATM机上的转账放入一个事务中（也就是将核心系统调用转账服务和ATM记录操作日志放入同一个事务中处理），这样如果全部成功则一起提交，有一个失败则全部回退，可以解决上面提到的所有的麻烦。
最后一个方案在相比下效果是最好的，如果核心系统提供的转账服务是EJB服务，那么可以按照最后一个方案来实现（具体可以参考J2EE分布式事务管理中的跨服务器事务管理）；如果核心系统提供的转账服务是web service服务（按照soap协议），在网上看到过有webservice的事务管理规范，可以让webservice之间的调用纳入全局事务的范畴，但目前不清楚was是否实现了对此的支持；如果是以一个servlet或网页的形式提供的转账服务，那么基本可以确定无法使用最后一个方案，根据实际情况再做选择，或许事务补偿的做法会是一个不错的选择。