来自微软的DeVadoss在本次访谈中指出SOA并不仅仅只是一种IT技术。

　　在所有Web服务标准中，我听说最让人沮丧的是WS-Policy的难产。它会影响2006年的标准体吗?它的领导者微软和IBM能够让它出台吗?

John DeVadoss: 我希望在标准组织中看到它，但是有很多变数所以很难预期。因此，我还是希望它能有好运。我的看法是策略是委员会还没有达成一致看法的抽象层。我想这会花费我们一段时间。如果你看看协议栈的低一些的层，它只花了不长时间就达成了一致。策略转移到了更高的层次。所以，不匆忙完成什么或许是对的，这样可以不必在以后返工。我希望我们一起很好的完成这项工作。

　　Web服务是否大体上提高了创建SOA的开放基础设施的难度?

　　DeVadoss: 对此我没有什么特别要说的，但如果我是一名架构师，我会相信简单性和一致性，以及能够使用你需要的东西。一些关注是在乎其广泛的范畴。但不要关注你需要的是什么以及什么会给你价值，也不要指望你会使用所有的特性和所有这些说明书。

　　你觉得在明年微软会有任何开源的机会吗?

　　DeVadoss: 广义的开源包含很多领域。有开发模型、有哲学思想、有侦听模式，还有商业模型。首先，我认为开源是围绕社区思想的一种开发模型。如果你看看我们VS.NET 2003的工作，你会看到我们已经从社区中学习深度合作的好处。甚至社区技术的概念与我们社区外的一些概念相同，于是我们也给他们一些反馈，我们正在好好利用这些做法。

　　我也会负责一个Shared Source Initiative项目，用以显示我们对开源社区的兴趣以及回应。

　　你对Service Component Architecture的看法是什么?

　　DeVadoss: 我把SCA看作是对J2EE重量级性质的一种回应和一种容器模型。我也把它看作类似Spring的一种轻量级模型。当然，如果你回来看看我们的容器模型，会发现该容器模型的轻量级性质是我们很久之前所做的事情。我认为从概念级的观点来看，SCA不仅是从J2EE和复杂性中走出的一个社区，它还会更加融入我们对世界的看法。

　　基于XML的部署的关键是降低复杂性吗?

　　DeVadoss: 我信奉松藕合。我也相信简单性。我认为XML给予我们的是连接和通信的能力，而这是面向服务的关键。尽管服务是抽象的东西，我们依然谈论它，但我想我们都赞同面向服务的成功主要要应该归功于XML和SOAP这类东西，所以我当然会赞同这样的观点。

　　你认为，有特殊的工具来驱动更多的用户使用松藕合的结构吗?

　　DeVadoss: 我认为关键是应用模型。此外，不要使用UML这样的单语言模型，而是使用特定领域的模型，包括开发人员的模型、明确业务需求的架构师的模型、用于映射和设计操作基础设施的架构师的模型。我相信，这会成为我们真正实现从业务需求映射到操作的必由之路。还会发生其它的事情，但在我看来，那些都没有它有趣和重要。

　　关于SOA对很多用户的用途，我们谈到了点子上吗?

　　DeVadoss: 我想是的。确实有在面向服务上取得出色成功的客户。但是，成功的都是那些重视商业价值的客户。我看到的在面向服务中遇到困难的客户是那些把IT放在首位或者把架构放在首位的。我在微软领导架构团队，但我第一个告诉你架构不是终极目标。客户不想要SOA，他们要的是商业价值。对于面向服务创造商业价值，它必须发掘新的商业机会才行。更灵活，这才是价值。当客户告诉我他们有SOA的成熟度模型时，我觉得很难办，因为目标不是你的架构有多么复杂多么成熟多么优雅，而是你创造了什么商业价值。

　　你认为在2006年中会发生的很多人现在还没预计到的事情是什么?

　　DeVadoss: 一件事是面向服务的概念会深入人心。我想这是我们要承认的事情。我希望人们从SOA是终极目标的想法中走出来，但对我而言，更重要的事情是服务消费的观点要提升到更高的档次。我想这就是2006年会发生的事情。

　　对你来说，SOA中XML硬件的重要性是什么?

　　DeVadoss: 我相信有XML硬件的一席之地。如果你记得90年代末的.com岁月，在那些Web推动者中就有着这种热情，那时人们都在谈论如何应用硬件，其本质就是对事务的处理。我认为它不是高层次的事情。我觉得软件才是更高层次的事。

　　采用者需要避免的SOA缺陷是什么?

　　DeVadoss: 人们思考SOA，思考服务。有意义的服务应该拥有数据。而对数据在互联系统中的影响，人们还缺乏了解。我希望他们对服务背后的数据多多思考。其次，我想说的是分解的服务对成功非常关键。在我曾经和一个ISV交谈时，他们已经有集成的系统并把它重新设计成面向服务的。他们有19个服务，而在中间层，他们把所有的请求混合在一起或者用于每个业务交易的服务中，结果中间层处理所有的编组和数据混合。实际上，他们的系统非常缺乏可管理性、可用性。我希望架构师和开发人员好好思考服务分解。一个服务并不是一个业务对象。也不是一个业务组件。一个服务是一个拥有数据的更大的抽象概念。