如果大家关注SOA的事务一致性的处理，那么不妨看看我们是怎么解决的 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

SOA的理念日渐深入人心，银行业务系统也必将转向SOA，这意味着今后绝大多数应用都要成为服务的集成者——这就带来一个非常关键的问题：如何解决集成服务应用普遍存在的一致性问题？当前金融行业正在运用的集成服务应用平台和框架都只能通过一种自动撤消机制（即所谓冲正，效果类似数据库的回滚）来解决这个问题，但在许多业务场景中，自动撤消机制并不适用。

完善的服务层应用平台应该不仅仅提供“自动撤消处理”机制，还提供“手动继续尝试处理或撤消处理”机制来解决这个问题。后者和下载文件时我们常用的“断点续传”的效果非常相似，能够帮助业务人员在第一时间内用极为简单的操作修正一致性问题，同时，由于是在业务人员的监控下采取修正动作，马上可以看到修正结果，因此，不会有“自动撤消处理”可能产生的资金风险，能够有效地提升业务办理效率和服务质量，并降低操作风险和系统的数据差错率。需要特别指出的是，这并不需要开发人员做出特别的、额外的设计。


意思是：所有的服务接口，不但应该提供一个统一的冲正接口（当然，这个冲正也可以在服务系统内部触发，而不是依靠调用这个接口），还应该提供继续尝试处理和撤销处理接口，前者可以完成先前没有完成的工作，后者可以抹除先前已经部分完成的工作。当然，服务接口的应答中还应该包含一个参数，表明当前这次服务调用是否出了一致性问题，如果出了一致性问题，服务的消费者（例如，前台系统）就可以调用继续尝试处理和撤销处理接口来解决问题
完善的服务系统，除了提供一般的服务接口，还要提供一些一致性处理接口，这些处理接口仅包括一个统一的冲正接口是不够的，还应该包括统一的继续尝试处理接口和（部分）撤销处理接口
还是要人工处理，并没有从根本上消除不一致的问题啊。而且，即使有人工处理，每日的对账还是必不可少的。因为人工也可能有疏漏。
错了，这个人工处理是不同于现在的人工处理的，它是 傻瓜 式的，只需点击“继续尝试处理”或者“撤销”这两个按钮之一，直到全部成功或全部撤销
当然，有了这些接口不等于对账就不要做了。但要知道，有了这些接口，不上的帐将大大减少，并且这些错账的处理也可以用这些接口支持，从而大大减少错账处理的人工工作量
当你在一个SOA架构中，要集成多个WebService时，你怎么能够奢望数据都在一个数据库中？不在一个数据库中，你就不能依赖数据库事务机制来保证一致性。并且，实际运行起来需要用户用这种“傻瓜”方式处理一致性问题的相对来说，比例还是很少的，通常不到1%，谈不上“烦死”。相反，现在的许多系统，如果对账后错账较多，处理错账的人经常“烦死”