正如我们所知的，Web Service的SOAP消息可以通过许多种基于Internet的网络传输协议来传送。大部分情况下，我们使用HTTP协议来传送SOAP消息，一个优势是，由于HTTP协议的无状态特性，那么，基于其的SOAP消息很容易的穿过防火墙；但同时也有一个副作用就是，无法保证Web Service客户端和服务端的一致性，即Web Service事务不可控制。
我并不十分了解诸如SDO（Service Data Object）\SCA（Service Component Architecture）之类的新新技术规范模型是如何解决这个问题的，这里我只想提出一种基于Spring框架的解决思路，及实现。没错，正是利用Spring这种我们“JavaEE生活”中最大众化的产品的事务管理机制，结合Apache最新的Web Service引擎Axis2，加以扩展实现的。
它可以在一定范围内解决Web服务客户端与服务端事务不可控制的问题，利用自定义策略补偿出现异常情况的事务，以下给出解决JDBC和Hibernate数据持久化的Web Service事务问题的方案。
基本原理就是扩展Spring的JDBC及Hibernate事务管理框架（实际上就是分别继承Spring的DataSourceTransactionManager和HibernateTransactionManager）。
Spring本身的管理方法是将本地事务控制在一个线程中，将事务资源（诸如Connection Holder之类）存储在ThreadLocal，即本地线程绑定的变量中，以方便的在多个事务或事务的嵌套中“挂起”、“恢复”事务，目标是完成“整体”的事务。
现在，我们可以对其加以改造：在Web Service服务端执行完毕后，不立即提交事务，而是将本应放入ThreadLocal中的Spring事务资源放入一个“事务资源池”中（这个事务至少应该是线程安全的），那么，这就相当于“挂起”在服务端的事务，然后，利用Axis2的异步Web Service客户端的特性，去完成客户端的事务先——执行异步客户端回调方法中的客户端事务，好，接下来将会有以下几种情况出现：
- 客户端事务提交成功——则客户端会自动通知服务端提交“事务资源池”中相应的事务，两方面事务成功提交。
- 客户端事务提交失败——无论是由于异常爆发或业务逻辑未通过，在这种情况下，客户端都应通知服务端“回滚”（rollback）事务，以保证两端一致性。
- 客户端与服务端失去联系——这种场景最常见的情况就是网络瞬断。那么，由于接收不到客户端的消息，服务端被“挂起”的事务就应该在指定的等待时间后，去触发执行特定的“事务超时”策略，根据配置的策略对失去联系的服务端事务进行“补偿”处理，这种处理表现为“回滚”（rollback）或“提交”（commit）。
以上只是这种Web Service事务管理机制的构想及原理，真正付诸实现的话，还是需要扩展、抽象一些Spring和Axis2的类型，同时还需要注意很多问题诸如线程安全、适用性等，另外，对于事务数据传送对象（Transaction DTO）等的规范也需要详细定义……
我已经在一个开源项目中对此事务管理框架有了实现，可以参考：
ClearWork@SourceForge
ClearWork对Axis2的扩展 - 基于自定义策略的Web Service事务控制
在这个项目Web Service模块中可以找到本文的实现代码。
发表于 @ 2007年11月04日 00:17:00|评论(loading...)|编辑