人们将面向服务架构误认是与Web服务是相同的概念。而且这种误解非常普遍，深深了影响了设计师，开发商，咨询师以及供应商的工作。由于 ZapThink 每天要解决许多问题，并且仓促的调查不足以清楚的解释人们对于二者之间关系的困惑。因此对SOA的定义是不充分的：“SOA是组织IT资源以便更好满足不断变化业务需求的方法。”“对于软件功能和数据来讲，Web服务是建立在标准之上受限接口。”但是，毕竟这些有关SOA片面的定义，对SOA的不了解，一直困扰这人们。那么，为什么我们会一直对此困惑不解呢？我们怎样才能够解决这个问题呢？首先，让我们看一看这两个相互联系但又相互分离的两个概念，以帮助我们理解二者的不同之处。

　　首先将SOA和Web服务结合在一起

　　有一个迹象能够表明SOA和Web服务是两个不同事物，即早在Web服务产生很久以前，SOA就已经存在了。同公用对象请求代理[调度]程序体系结构和微软的分布部件对象模(DCOM)一样，从90年代开始，分布式计算方法就是能够以订立合同的方式抽取软件功能的结构方法，这种订立合同的方式为我们提供了一定量的松耦合，并且同那些利用紧耦合接口的方法相比，更具灵活性——换句话说，它们是以服务为导向的。CORBA和DCOM都在市场上取得了一定的成功，DCOM是单一供应商的架构，CORBA表面上却是供应商中立的，但是由于事实证明多个供应商在实施CORBA互不相容，因此在实践中CORBA不可能有特定的供应商。

　　但是事情的进展并没有引起人们更多的兴趣，直到90年代末，几个供应商才意识到以下重要两点：首先，只有SOA的实施独立时，SOA才能提供灵活性。其次，较为新颖的可扩展性标识语言(XML)可以制定一个理想的协议，尽管其最初目标是成为文档标识语言。供应商这些独到的见解帮助他们最终将工作重心放在了核心规范上。该核心规范为Web服务提供了依据：Web服务描述语言(WSDL)，统一描述、发现和集成(UDDI)以及简单对象访问协议(SOAP），如同访问对象不再是其存在原因一样，它们现在不再是简单的缩略词。

　　人们早期对于这三个标准启用的“寻找—绑定—发布”三角形的研究关注业务到业务(B2B)应用，人们最初对于全球“绿页”目录的独到见解准许自动发现和通过网络绑定到业务Web服务。问题是，没有人想用这样的方式完成业务。如同从黄页目录里寻找水暖工一样，谁愿意自动化流程并在在系统之间添加任意互操作呢？结果人们早期对于SOA的业务到业务(B2B）观点完全瓦解了，其只不过是dot.com繁荣发展接近尾声时，"Web 1.0"B2B eMarketplace败笔的一部分。

　　Web服务占据了中心位置

　　Dot.com的结束以及后来IT行业的逐渐下滑给许多标准设置了障碍。2002-2003年度标志着Web服务的黄金时代。供应商意识到在困难时期唯一有希望产生业务的就是节约成本这个提议，对于Web服务来说就是要：降低集成成本。从专有接口向基于标准的接口转移，这样就会节省许多资金！但是，现今的标准远远不能满足Web服务快速发展的需求，至少对于那些寻找新商机的供应商来说，这些业务实例足够坚固了，因此Web服务市场也就诞生了。

　　根据我们早期对于Web服务技术和趋势，XML&Web服务安全，服务定向管理以及Web服务测试的调查，ZapThink公司自然要借助Web服务的威力。然而早在2002年2月XML和Web服务相关的书籍出版以前，我们在谈论架构之时就建议供应商要涉及SOA，因为市场还没有能力应对以SOA代表的如此复杂和业务为中心的议题。相反人们的目光集中到了Web服务架构这个基于标准的集成化方法上。

　　然而，我们意识到我们在服务定向集成报告中写到的2002年的基本事实和今天的事实一样具有可预测性：单靠Web服务就可以降低集成成本，只有使用SOA，机构才能降低业务交易的长期成本。换句话说，Web服务为你参加舞会买单，但是你还得学会跳舞。