web service中的事务控制

web service中的事务控制

转载：http://www.griddss.cn/show.aspx?id=127&cid=7
因为这个问题讨论起来内容比较多一些，所以另开一个话题。

如果你只是要解决两个系统之间的事务同步问题，可以采用判断服务是否成功的办法来解决，即：

* A系统开始自己的事务，处理自己的数据，然后。。。
* 在提交之前调用B系统的服务。
* B系统开始自己的事务B，在事务中处理数据，再提交事务。
* B系统把自己事务的提交成功与否的信息做为返回值回馈A系统。
* A系统根据B的事务成功情况决定自己的事务是否提交或是回滚。

但是，在继续深入讨论这个问题之前，先反问一个引伸的问题：当分布式系统之间，要进行事务控制的子系统不是两个，而是N个时，如果进行事务控制？

分布式事务一直都是很难解决的问题。在面向DCOM的分布式应用中，有一种分布带事务支持策略，大体的思路是采用两段式事务提交的办法，第一次提交是预提交，预提交之后是可以回滚的。第二次提交是永久性的提交，提交之后就不可以回滚。并且，如果预提交成功，第二次提交也必然成功，系统必须可以保证这一点。

这样，当每个系统都支持这种两段式提交之后，就可以采用这样的事务管理：一个控制角色向每个分布系统提出执行要求，并要求完成第一次事务提交。当每个系统的第一次提交都成功时，则要求所有系统完成最后的永久提交，可知这次的永久提交是肯定可以完成的，因此不须要再担心这次提交是否成功。
如果第一次提交中，有某些应用出现失败，则要求所有的应用都回滚事务。
一些数据库软件本身就支持事务嵌套，如sqlserver等，不幸的是，我们的主力数据库informix不支持。
为了简化这种分布式事务管理，有一些中间件产品可以采用，用得比较广泛的是MS DTS.

你可能已经看出来了，这样的事务控制策略虽然可以在分布式环境下满足事务的ACID要求，但是它对各个分布组件是有要求的，在基于COM, remoting，JRMI一类技术的分布式应用程序中，这个没有问题。但是在采用web service的场景中，这是有问题的。

问题1. web service是一种以松耦合为指导思想的集成方式，一般情况下，主张采用无状态方法。
webservice主张两次调用之间没有上下文关系，即一次调用与其他之前和之后的调用都没有关系，一次提交即完成一次完整的处理。但是分布式事务却要求各方要在两次对话之间保持对话状态，以便于知道本次永久性提交时，要对之前“哪一个”已经被预提交成功的事务执行最后的提交。
当遇到这个问题时，我们必须要再多问自己一个问题：我们已经选择了正确的集成技术吗？如果多个系统之间有如此紧密的事务耦合关系时，我很怀疑它们其实就是同一个应用系统。同一个应用系统中，应该有相同的平台，相同的进程空间，相同的数据模型以及数据源。这种情况下，采用web service是一种错误的选择，web service应该用于不同平台、不同应用、不同的数据模型的系统集成。即便是的确需要在同一个应用系统中由于某些原因而实现模块间的分布式构造，也应该采用同一技术平台内的远过程访问技术，它们能通常比web service能提供更好的耦合性支持。

好吧，假设你经过思考之后，对上述问题的回答是“是”：我们确实必须要在异构的、多平台的、本来应该是低耦合系统之间实现分布式事务控制。那么，webservice还有用处吗？
谢天谢地，web service虽然主张交互之间采无状态方式，但是它并不是禁止采用有状态的交互。WEB SERVICE还是一种web技术，而web技术中的状态保存可能是最早被解决的问题之一了。在所有的web开发技术平台中，都有session机制，无论这些Session是通过IP，cookies, hidden input来实现，还是url sessionid来实现的，反正都有办法实现，请参阅所用平台的session支持机制就可以了。退一万步，你也可以通过在服务器中维护一个应用程序级的事务池来实现，未最后提交的事务对象都放在里面，每一个事务对象都给定一个唯一个的标志ID来识别，形成一个字典对象池。如果启动事务成功，则把此事务的ID返回给调用者执有，做第二段提交时，把事务的ID做为参数提交就是了。（随便提一下，用这种方法时，千万不能把对象的指针、句柄、引用什么的平台相关的值交给客户方，倒不是害怕安全问题，而是这些值在分布系统中是没有意义的，上次返回的指针没准早被垃圾收集机挪到其他地方去了）

无论如何，webservice在通信层上是一种无连接的协议，每两次调用之间，tcp连接是断开的，因此，一但采用session机制来管理上下文，你就必须为这些session的生命期负责。试想，如果一个事务上下文已经开启，而此时客户方系统却突然当机了，这时会出什么事情？在同一个应用程序域中，客户方的当机会让连接中断，服务器立即就会中断并回退事务，但是在webservice里，状态管理机无法立即感觉到此事务的调用方已经失去控制，只能在一定的时间之后，才发现：“噫？这个事务已经N长时间没有人访问了！快快回退！”在ASP.net里，默认的状态超时时长大概是20分钟，JSP也差不多，阻塞了20分钟的事务对数据源是什么影响可想而止！因此，必须考虑合适的状态时长与事务隔离级别，以减小对数据源的性能影响。

问题2. web service的“反模式”方法论使得无法在系统之间统一出共同的抽象接口。
web service是一种“反模式”的系统架构思想，即不是一般的由先建模并抽象接口开始，再由各个分布系统实现接口的系统构造方式，而是反过来：系统可能早已经完成，现在的问题是两个系统间的信息交互作用，因此交互的接口规格是根据需要，把系统数据模型去范式化后挑挑捡捡而定的。
因此，webservice中不支持接口抽象，即：你无法定义一个各个系统都必须实现的抽象事务接口，然后由各个系统实现这个接口的多态，最后在承担事务控制器的应用中调用统一事务接口以调度分布事务。虽然这样的接口模型在很多面向对象的开发平台中的远过程调用技术中所支持，但是如同之前说过的，web service是一种用于集成的松耦合的反模式方法论，而不是为紧耦合系统中的分布式对象而设计的。
所以，虽然有点讨人烦，但是我又一次忍不住想问我已经问过的那个问题：我们真得用对了技术吗？如果多个系统之间需要如此级别的接口耦合性，我真得越来越怀疑它们其实就是同一个应用系统了。
假设你的回答还是“是，他们真得不是同一个系统，他们是异构平台的，异构数据的！”好吧，那么继续。让我们采用web service来完成集成，但是你必须忘记你的OOP思想，老老实实地编码，用枯燥的、重复的代码把所有的系统的事务都控制在一起，别想用对象抽象的概念来省一点事。
真的吗？
如果把事务控制器独立出来如何？假设我们建立一个专用于分布式服务控制的应用，而用WEB SERVICE的方式公布接口, 允许其他应用程序通过向这个事务控制器注册自己的两段式事务开启、提交和回退的web service接口。然后，当有客户想启动分布事务时，就可以向这个事务控制器发起分布式事务请求，选择事务各方，启动一个分布式，最后向事务控制器，而非是各个事务方直接发起提交请求，这样事务控制的多态就可以在事务控制服务器中实现，虽然实现可能还是通过查表等方式实现，而非平台级的抽象方法，但是对于事务客户来讲，这样一个服务器就是多态的实现部分。
如果真得比MS更快更好地实现这样一个web service做接口，面向异构系统的分布式事务控制器，NASDAQ也许会有你的一席之地吧！

问题3. 异构平台不一定都支持两段事务提交模式。
web service面向的是完全异构平台的集成，那么显然不能指望每个平台都能支持两段时提交事务模式。但是，标准就是标准，协议就是协议，标准就是用来让大家遵守的，如果一个平台本来不支持两段式事务，那么为了能支持分布式事务，它就必须改造以实现两段式事务提交。
怎么改造是各个应用系统内部的事情，为了本文讨论的全整性，也在这里稍微涉及一下。
首选的方式是通过数据缓存的方式来实现。很多OO系统中，都采用了所谓的N层架构，即把业务对象与关系表模型分离开来，业务对象位于系统内存或是缓存中，由运行时的对象容器管理，容器根据一定的策略，把缓存中业务对象向数据库这样的久永介质中保存，或是从数据库中加载所需要的业务对象，在保存和加载过程中，将完成对象到表数据的转换，或是相反。

一般的N层结构的中间件产品中，都会提供两个级别的事务，即面向缓存中对象的事务控制和面向持久化过程的事务，可以考虑简单地将此两个事务级别对应的分布事务中的两段事务提交。但是，这种方式必须冒一定的风险，如对象容器级的事务成功，而数据库事务提交时出现失败，此时将会导致的数据不一致的风险，尽管这个几率并不很大。

在使用数据容器的情况下，也可以用保存对象的历史状态来实现事务的手工回退。因为在业务对象层与持久化层相分离之后，持久化层在数据更新时并没有复杂的逻辑，只是一些被罗列的、业务意义无关的数据更新序列。如果可以保持对象的状态历史，那么就可以在需要的时候将对象的状态恢复到旧的旧版上。实际上，在一些出色的中间件平台中，这个机制已经实现得非常完善了。（可以参阅Graphtalk平台的对象持久化管理，简直是天才！）

另一种笨办法是通过数据逻辑来实现两段事务提交，例如在要求第一次提交时，即真正提交，在第二次提交时固定什么也不做，而返回正常。如果要求回退，那么就通过数据逻辑或是业务逻辑来更新数据为旧状态。这种实现方式绝对是很令人头痛的。

不过，幸亏我们不是在为一个通用的数据库设计两段事务机制。要知道，面向服务的事务处理并不是如同数据库级别的事务那样，在事务的期间数据的操作有无穷的可能性。通常我们一个服务就是一个功能，其数据操作过程中，数据的变化方式是可预知的，因此恢复数据的状态也是一个个具体而固定的过程，只要我们针对每一个服务操作设计数据恢复机能就是了。

最后，如果这些都不可能实现的话——大于50%的可能性，因为时间、成本、技术等原因，这些都实现不了，那么只能靠两个字了：妥协。