来自微软的DeVadoss对WCF给SOA带来的影响进行相关说明
很多我们对Windows Communication Foundation的预计已经展现出来，那么它又带给哪些我们没有预计到的东西呢?
John DeVadoss: WCF是构建安全可靠的事务性服务的统一框架。它是一种构建分布式面向服务系统的非常丰富的技术基础，它统一了消息风格和RPC[Remote Procedure Call]风格，并且通过二进制和基于开放标准的通信达到了平台最优化。对于我来说，最要害的事情是让更多人了解它，但我认为让开发人员激动的是编成模型的优雅和简单。在很多文章中，面向服务已经获得了这种极高的评价。我想，WCF能做的就是对绝大多数开发人员甚至架构师来说让这种想法成为现实。
请进一步解释一下这种想法。在过去很多公司为很多大型项目投入了不少资金，难道集成不是显而易见的目标吗?
DeVadoss: 假如你听听开发人员和架构师谈论SOA甚至更加深奥的东西，你就知道对我们来说，它还只是一种很好的想法而以。它不过是关于松耦合、合约以及消息的远景想法。而WCF会以相当简单的方式让它对我们大多数的受众成为现实。
假如你停下来想想松耦合的基础，我想使你困惑的一定是人们使用的不同方法。有的厂商希望SOA成为一种产品或者平台。而有的厂商希望在更大的服务领域让SOA成为一次到位的无所不能的企业SOA,要花费24到36个月才能完成。而假如你再想到SOA的基本原则就是帮助你实现互操作性、集成性和灵活性，那么它确实与很多人有关。这个想法更像是不同厂商、服务提供商都在预期的事情。甚至一些架构师组织都把它添加到已让有些人感到复杂的性质中。
面向服务的基础形式是与人有关的某种东西，因为它能很好的映射成我们想要得业务。于是，IT就作为服务提供者，在那之上是客户的行为，这样使服务获得优势。
我是一个Java用户，WCF的出现应该令我注重些什么呢?
DeVadoss: 有两件事情值得注重。第一，编成模型所带来的优雅和简单。第二，是我们对服务的配置方面所作的工作。从IT治理者或者开发人员以及构架师的角度来看，在决定用什么协议、什么标准、什么机制来通信正是问题的所在。我们的目标非常不明确。我们正在重新定义通信的消息风格以及RPC风格。
为什么说WCF是Vista的组成部分?它与操作系统到底有什么联系?
DeVadoss: 我们对WCF确实有底层的支持，那么让我们来把它弄明白。说到它与某个版本耦合在一起，我们选择了.NET框架。我们希望.NET框架的基础能够用到WCF。这是一个要害想法。但是，WCF并没有与Vista硬耦合到一起。假如你是一个使用Windows 2003的开发人员，你依然可以使用WCF的灵活性等强大功能。
那么假如我使用Linux或者Solaris，会有一些限制吗?
DeVadoss: 不会有。我想，在这个布满分布式的互联系统的世界里，更重要的事情就是互操作性，只有集成才能共享通用的基础设施或者通用的协议，例如WS-*。而每台机器是否相同就不是那么重要了。更重要的是我们能够在基础设计级别互联和通信，能够都理解顾客或者帐单的含义。
在过去的几年中Redmond关于面向服务架构的想法发生过改变吗?你认为在2006年它又是什么样子?
DeVadoss: 我认为在2006年会发生两件事情。首先，面向服务将变成架构系统的普遍风格。另外，还在成长的服务提交这种传统服务提供方式只是SOA的一个方面，服务消费才是真正正确的途径。我跟很多架构师和企业客户谈到IT界构建并将实现它的远景。它们的服务提交、供给、治理和构建都需要非常复杂的基础设施，但当你与客户交谈时，他们并不知道这样做的好处。我认为服务客户将变得更加可行，而且会通过我们对Vista的投资和Office工具的投资反映出来。只有客户得到好处，你才可能用于服务提交的最强大的基础设施，但没有业务价值的话一切都是白搭。
微软在构建SOA方面还没拥有的最重要的部分是什么?
DeVadoss: 在过去几年中，在微软我们做过最多的东西是模型驱动的设计和模型驱动的开发。我希望我们可以加速使用模型来驱动设计，驱动通信。但我们只是最近才使用我们特定领域的语言工具，而且还有更多特定领域语言方面的工作等着我们去做。然而，由于我们要处理的基础设施，工具以及平台合适，现在的工作比较现实。我们越早让架构师和开发人员使用模型，我们就能根据构建系统的类型更好的实施。
模型驱动的架构能帮上什么忙吗?
DeVadoss: MDA是一种招牌。MDA也是平台独立性方面的普遍熟悉，而且它几乎专注于让你在构建出模型后就能由它产生代码。这两件事情都是我们要面临的难点。平台提供了某些优势，而对于我们来说，真正利用平台优势而不是停留在学术上的平台独立性上很有必要。另外，我们也不相信只有一种语言能够描述模型，例如UML 2.0。
以BPEL和XAML为例，差异明显的领域有着不同的需求，不同的约束，因此我们相信特定领域的语言比起用一种语言来约束自己更加有道理，UML也只是需要的一种语言而已。这就是为什么我相信我们在[ACPI Source Language]方面的投资肯定能够回报我们付出的时间。
