如何在web系统中实现跨系统调用与事务补偿

实际也有很多系统可靠性没那么高，也一样用。如果做不到，只要涉及交易金额不大，也没什么，甲方也不会找什么麻烦。尽力而为吧。
这种可靠性需要在最开始设计系统的时候就要考虑周到。

银行的系统类似，一般会有一个每天半夜对账的机制，来保证钱不会错！

确切的说银行项目是没有使用到事务的。。

可以参考一下分布式事务处理机制，事务补偿机制来源于分布式事务的说法。
你需要一个事务协调器（就是发起重试，保证最终一致性），也就是一个第三方系统来做这件事。

当然，你说你不想做复杂，那就可以尝试弄一个基于分布式系统协调器的原型简化版。
总的流程就是：业务预检，两边系统分别起事务，不提交。A系统提交，B系统提交。
如果A系统提交失败，则协调器通知B系统回滚。如果A提交成功，则通知B提交。如果B提交失败，则用协调器一至重试B（业务参数前面已检查已满足），保证最终的数据一致性。

其实你提交的时候本来就是一种待处理的过程
通过查询或者是其他确认来达到两边系统的一直
也就是一个对账过程，来解决双方不一致的情况。

不知道楼主有没有接触过支付宝付款 可以参考一下他的模式啊

这个应该是属于典型的分布式系统解决方案吧

我觉得可以使用jms机制 用来传递多个系统之间的消息会话

用JTA来保证系统的安全以及消息的正确和错误的回滚等

建议楼主参考一下TCP连接的三次握手的原理，或许会有些灵感。

不使用事务，那使用什么来保证安全性和可靠性呢？

确切地说，应该是不用分布式事务（如XA事务)，尤其是局域网络之外的分布式事务。

分布式事务相对本地事务来说，虽然都是事务，有相同的或类似的结果预期，但实现方式及其效率、稳定性、可靠性差别巨大。具体细节分别可以写成两本厚厚的书了，抱歉我本人也没看全。

但是这种差别的存在应该被知道，分布式事务是基于网络交互的，网络的相对不稳定性和相对低效，分布式事务一样也避免不了。可以简单的理解分布式事务使用了一系列的交互机制/规则来保证数据状态的一致性，但这些规则细节对应用是透明的、不可控的，同时在此过程中产生的同步等待及资源竞争也是相对巨大的、不可控的，实际应用上是不能接受的。
针对具体的应用需求，我们完全可以设计完整的业务逻辑规则来保证可靠性和一致性。
数据库事务要求的OCID,和实际业务需求要求的可靠性、一致性以及所谓的资金安全是不一样的，OCID事务要求高得多，而且在数据状态完全一致之前对应用是透明的，在交易系统里可以不用这样严格。比如对资金安全来说，资金冻结在前，之后才允许交易，最后再同步交易状态（还有各阶段异常的补偿措施），这些阶段是分开的，在不同位置单独完成的，只要保证顺序，是不需要在一个数据库事务里完成的，也不需要都用实时、同步的方式完成。这种机制对系统的要求及其效率表现要比OCID事务机制高很多。当然，对应用系统的设计和开发的要求也要高一些。

实际应用还有一些其他约束也是分布式事务无法满足的，比如双方是独立的系统，甚至不是一个金融实体，要把双方的数据库纳入到一个分布式事务里是不可能的。很多介绍分布式事务的文章里会讲到资金转账的案例，即从A账户转账到另外一个系统的B账户，实际当中是否使用分布式事务来实现此功能，我对此表示相当的怀疑。

还有一个不能使用分布式事务的重要的因素，上面多次提到了透明和不可控。一旦发生异常，金融系统在业务规则上有它一套完整的补偿措施和干预手段，而且会涉及人工干预和不同金融实体的交涉。这些问题靠分布式事务是根本做不到的。

实际生活中，我们在跨行或异地存款、转账时，作为个人在完成转账后，经常还要过一段时间才能到账(当然也有很多提供实时到账服务的，不过这同样跟分布式事务无关)，这已经是我们普遍接受的习惯性的事情，而且我们也不需要在到账之前一直在银行等待。

本质上来说，数据库的事务交易和金融交易完全不是一回事儿，是不同层面、不同领域的概念，只不过从技术实现角度上它们存在着一些必要的、习惯性的联系，所以容易在某些地方容易被混淆。我曾经在对一篇关于“Base 一种Acid的替代方案”的评论当中提到过，并非原作者的本意，但实际传播和读者理解过程中存在着把金融交易（商业交易）和数据库事务交易混淆的问题（尤其是所谓‘最终一致性'的概念)，可惜并没有人认同，大概是做金融业务的人关心技术实现的不多，同时做技术研发实现的人关心金融业务的也同样不多吧。