我们都知道,微软定义服务四大原则,其中很重要的一个是说服务自治原则:
服务是实体,它们独立地配置、更新和管理。开发者不应该对于服务边界之间的空间做出假设,因为这些空间会比服务边界本身变得还快。比如,服务边界应该是静态的,将减小版本的更新给用户带来的影响。服务的边界一般都是稳定的,而关于策略、地理位置或网络技术等服务配置选项则会经常地变化。
http://www.microsoft.com/china/MSDN/library/architecture/SOADesign.mspx
那么服务自治是否意味着服务不互相依赖?WCF中出现的新功能(包括WS-AtomicTransaction (WS-AT) protocol以及OLE Transactions protocol两种方式)使得我们可以将多个服务做为一个交易(AtomicTransaction),也就是将交易的边界扩充到服务之间而不是像以前的web service那样集中在服务内部,这样做是否违反了服务自治原则?
首先,从概念上讲,其实服务自治并不表示开发的服务都是自治的,这个有点像语言游戏.
服务自治的真实含义是服务可以被独立的开发和维护,由于通过contract和message去和服务打交道,所以,没有二进制依赖,服务可以开发在不同的平台,不同的语言.
而自治的服务(is a service whose ability to function is not controlled or inhibited by other services.)是我们追求的目标,也就是服务之间更松的耦合关系,一个服务出现了问题另外一个服务不会受到影响.要实现这样的目标,同步调用基本上不可能,必须是异步的,而且这种AtomicTransaction基本上也是不可能的了.
所以,从这个概念上讲,多个service之间的自动交易并不违反服务自治原则,但是很难作一个自治的服务.
但是,如果我们把概念再延伸一下,这个其实也可以理解为一个服务边界的问题,并不是说一个WCF的Service就是你定义的一个服务,我们的服务是从业务抽象来的具有一定业务功能的服务,而WCF的Service只不过提供了一种用来分布式调用的技术手段,如果我们将几个WCF的Service看作是一个服务内部的几个组成部分,那么这个时候你用AtomicTransaction的时候可能就更加放心了.
在
Ron Jacobs
的
ARCast
中,微软的
Juval Lowy
的一段对话也可以给我们另外一些启示。
这里提到,首先,也许很多东西我们无法用AtomicTransaction来实现,而只能通过自己定义的交易补偿的方法来实现交易控制,这种一般是长交易,如果这种场景也使用AtomicTransaction,可能会将你的数据锁住很长的时间,显然不可取。但是,如果你的交易很短,你能够支持AtomicTransaction,那么就大胆的使用,但是有一个前提,就是你信任对方,如果对方要求你的服务嵌套在他的交易中,那么你一定要信任对方,你可能知道对方是谁,而且你知道可以保证你的锁的是将会很短,对方不会要求你的交易启动了,但是由于其他问题,不发给你commit的请求等等。这个思路和前面的交易边界原理上很像,互相信任的几个服务,也许在服务的边界上就是一个服务呢?