学文网Garmer副总裁Nick Gall是首个使用WOA一词的，那么，对于WOA与SOA引起的争论，他是如何看待的呢?
Loraine Lawson：当时您是怎么理解面向Web的架构(web-OrientedArchltecture，WOA)这个词的?现在它的含义改变了吗?
Nick Gall：当时，我发现有些网站采用了不同的Web服务风格，它们实现Web服务的方式跟我们Gartner的客户――中大型企业所采取的方式截然不同。
SOA本来是关于Web服务实现方式的一个总的概念，但一般它被用于指代一种特定的Web服务风格。也就是基于SOAP和WSDL的WS-*风格。那时我也看到了不同的新的风格，不过当时没有统一的名称来称呼它。也许最接近的名称是REST。我本可以用REST来指代它。但根据我在这一领域的研究经验以及我在网上的所见所闻，我觉得REST引起了太多的争议，而且关于REST的实际含义也存在着诸多误解。
在我看来，WOA意味着一种更加以Web为中心的Web服务风格，它不复杂，也不受厂商驱使，它代表一种新出现的风格。这就是WOA一词原来的含义。
自2005年以来，Gartner一直在努力令这个词具有更精确的含义。WOA是一个不错的关于Web服务实现方式的模糊词汇。但它到底意味着什么呢?能否再确切一点，再具体一点?为进一步确切描绘WOA，我们采用过各种各样的描述方法。也许人们最喜爱的描述方法是下面这种简洁的等式：
WOA=SOA+REST+WWW
关于WOA或REST与SOA无法相容，这方面存在着许多讨论，Gartner的观点很明确：WOA是总的SOA风格里的一种子风格。而且，WOA也未必一定要满足REST的所有约束。
因此，对于那些希望符合WOA的Web服务而言，它们应力求遵守REST的所有约束，不过也不必100％符合REST风格。这就是我们为什么不称之为REST的原因。虽然REST原则和REST约束是应当力求达到的，但并不是必须那样才算是面向Web的架构。
什么是SOA的风格
Loraine Lawson：那么，还有SOA，它应该算一种架构吧?
Nick Gall：SOA是一种架构风格。有很多种不同的架构都可以算作SOA，就像马是群体动物一样。虽然马的种类多种多样，但只要它们符合一定的关键特征，它们就属于群体生活的马。
对于那些可以看作符合SOA风格的架构来说，它们必须是模块化的、可分布的、可描述的、可共享的、可重用的和松耦合的。
如果你的架构满足所有这五项特征，就可以称得上是面向服务的架构。如果它严重违反其中某条约束，那就不能称之为面向服务的架构，当然你仍可以那样称呼它。另外，很不幸地，现在企业里有很多采用Web服务、XML、SOAP及WSDL的SOA项目，但它们都是紧耦合的，它们根本没有实际进行共享，可它们仍被称为SOA项目。虽然那个项目在那些企业里被称作SOA，但实际上它不是的。
那是SOA的风格。任何子风格都是在现有架构基础之上增添一些约束。所以，除了那五条主要约束，WOA更进一步，它还要求遵守RES了约束，而且REST约束与SOA约束是完全相容的。其实，REST的每一条约束都是教你如何满足SOA的五大约束。
Loraine Lawson：正如您前面谈到的，我想X风格其实是不符合SOA?
Nick Gall：这正是事情变得有趣和教条化的地方。有些人认为，使用IDL、使用从CORBA到DCE和Java演化而来的较传统的分布式应用架构，可以在共享和松耦合方面做得更好。
我不那样认为。我认为你是对的――如果我们真要对X风格作出明确论断的话，我得说。X风格的要点将给共享和松耦合带来妨碍。现在，这只是我的个人观点，并不代表Gartner的立场。
Gartner内外均有一些相当受尊敬且富有深刻见解的分析师和专家，他们坚信传统的IDL分布式对象架构可以带来可共享性与松耦合性。我还没有看到有关事实证据，也没有见到非常有说服力的案例或原因分析，因此我是持怀疑态度的。
我所见到的每一个案例都是脆弱的、紧耦合的，他们做得不对，所以我仍在等待对方提出另一种满足五大SOA约束的、非WOA风格的SOA最佳案例。
在五大约束里，可分布的和可描述的是很容易做到的，任何人、甚至连不成熟的WS-*都能满足这两点；另外，一定程度的模块化也是不难实现的。这三点总是可行的。我们一直在寻找的，是一种能够带来高度的共享/重用及松耦合的X风格，也就是说，我可以修改接口而不影响当前使用。要是有人能向我展示通过大量WS-*、基于WSDL和SOAP版本的风格能够快速改变而不会影响现有接口，同时还可以实现高度共享的话，我肯定会奔走相告的。
WOA与SOA谁更值得关注
Loraine Lawson：当人们说，按照Cartner的定义，WOA比SOA更容易、更简单时，您不会否认吧?
Nick Gall：我不否认，这里存在重大混淆的地方主要是；SOA被实际当成一个代号或当成WS-*的缩写。
虽然这个问题还没得到解决，但真正的问题来了，正是这个问题造成了如此多的混淆：对于那些大部分WS-*实现所采用的事实标准风格，我们没有名称来称呼它。WS-*、SOAP、WSDL等相关技术所采用的风格。它没有统一的名称。你不能称之为WS-*，因为理论上WS-*可以按任何方式来用，严格地说，你可以按符合REST风格的方式来用WS-*标准。虽然我还没听说有人这么做，但理论上是可以的。
SOA是五大约束的概括性术语。目前，他有两种主要的子风格。一种是X风格，它是一种类似分布式对象和IDL的风格。SOA的另一种主要风格便是WOA风格。在所有实现SOA的途径之中，WOA已经展现出了高度的可共享性与松耦合性，另外，它们的确是两种相互竞争的风格。我们可以对WOA风格的SOA和X风格的SOA作一个优缺点对比。我们目前正在做这方面的研究。
Loraine Lawson：对CIO们来说，这里有何重点?他们如何判断是应该关注SOA还是WOA呢?我们讨论了这么多，好像SOA和WOA有点像同一个东西?或者说X风格。如何弄清这些争论呢?
Nick Gall：很简单。把注意力集中在两条关键准则上：共享和松耦合。
看着你的业务，然后说“我对这种实现服务的新做法感兴趣。”人人都一定程度上同意，用服务来称呼这种做法是个不错的主意。而服务的关键就在于具有正确的服务接口。
关于什么是最好的接口风格，存在着许多不同看法――这暂搁一边。留给技术人员去判断。如果我是CIO或CEO，我要搞清楚谁将负责新系统的架构?他们最好向我展示、说服我，并且拥有看似有理的方法来部署高度共享的服务。我将在一年后(或其他期限内)进行回顾，若未能看到很大程度的共享，那我认为项目是失败的。
另外，我还要确保从中获得敏捷性。敏捷性的意思是，我有一些业务流程和服务接口，信息在接口之间流动。我不断要增强并丰富数据模型，增添新的属性与能力。我不想IT部门告诉我。每一次改变接口我都得进行彻底更换，因为他们向我承诺过松耦合接口的，也就是说，我修改一个地方不会对其他地方有太大影响。
所以，如果作为CIO或CEO，不论IT部门交付的是一个项目还是一个方法，只要它能够让我迅速变更基于IT的应用与流程，而且让我拥有高度共享的服务，那么我就成功了。最佳的实现方式留给IT部门去考虑就行了。
因此，若CIO强烈关注于交付高度共享的、敏捷的、便于更改的、灵活的、可定制的服务，那么你就成功了。不要指望技术、ESB、注册中心或注册库――不要以为你买了正确的技术你就更接近共享和松耦合这两个目标了，如果CIO、CEO们只关注具体采用什么技术，那他们将一无所获。真正应该关注的是实现共享与敏捷性所需的架构以及弥补缺陷的不同方式。