人们将面向服务架构误认是与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服务为你参加舞会买单，但是你还得学会跳舞。
Web服务黄金时代的结束
鉴于人们对SOA的讨论越来越激烈，Web服务也进入了快速发展时期。单纯能够为WSDL， UDDI，和SOAP提供支持不足以确保互操作性，更无法令任意系统到系统互操作标准化。这种局限性导致：人们努力建立Web服务互操作性组织(WS-I），该组织提高了标准的互操作性收益，以及建立其它用WS-*标注的标准(它应该读作“WS星，”，这里的星是旧Unix术语，表示“一切和所有”）人们的这些努力需要花费许多时间，并且由于不同的标准体包含了大部分供应商，整个工作就变得更为复杂了，并且交付给那些试图降低集成成本机构的互操作性少之又少，结果Web服务无法发挥其应有的潜力，目前还处于SOA的边缘地带。
事实上，当IT产品供应商看到SOA这口井中的金矿时，Web服务这轮马车的轮子就要掉了，这些供应商开始快速使用Web服务接口，并称其为服务定向方法，事实上，应用或者数据的Web服务接口，甚至是置于专有通信中间件之上的Web服务配置器都不能使用SOA建造。
同时，在SOA工具和最佳实践以及服务定向流程报告中，Zapthink将SOA以业务流程为中心的远景设计为企业架构。早在2004年，我们就开始建议供应商要关注在通信中对SOA关注要多于对Web服务的关注。我们为企业规划的远景蓝图远比直接采用Web服务更具挑战性，因为SOA要重新思考业务如何通过多种方式利用IT资源。Web服务仍旧只是其中的一部分。现在我们知道Web服务对于SOA来说并不是必不可少的，也不是必需品。
Zapthink采取的措施
因此在2007年，Web服务和SOA分了家。在SOA环境下，我们所说的服务和特定的接口标准相比更为抽象，开发商利用这些接口标准支持机构的互操作性要求。许多这样的服务都是Web服务，但还有很多服务不是Web服务。此外，Web服务的大多数应用是在SOA环境外部发生的。事实上，许多这样的服务都是从业务到业务B2B的，并最终返回到原始的Web服务远景（即使没有绿页）。然而大多数B2BWeb服务只是基于标准的应用程序接口，缺乏一个架构所能够提供的松耦合，位置独立，以及业务灵活性。另外，还有许多机构试图实施SOA，但实际上却是在实施Web服务，最终只得到了冗长的，无法兼容和难以管理的服务，这些服务实际上和架构毫不相关。
当我们回过头来Web服务和SOA以往的历史就会发现二者之间的结合充满了艰难与曲折，因为Web服务在SOA的引入过程当中扮演了十分重要的角色，尽管SOA的发展远远超出了Web服务的范围，我们的工作还是没有完成，因为Web服务vs.SOA之间许多令人极为困惑的问题有待解决，也许人们最大的挑战还是要确保SOA确实和业务流程有关，而不是和集成化有关。只要供应商还错误地坚持软件是SOA成功关键，我们的工作就远没有完成。
