在很多场合的交流中，常常遇到把
SOA和Web Service混用的情况，所以想在这次的Blog里，结合网上的各种观
点，谈谈个人对两个概念的理解。用一句话来概括基本的观点就是“SOA不是Web Service，Web Service是目前最适合实现SOA的技术”。 之所以SOA和Web Service被混为一谈，最可能的原因了也就在于此吧。
早在1996年Gartner就前瞻性地提出了面向服务架构的思想(SOA)，该年赫赫有名的Netscape
才发布了Navigator 2.0，整个互联网刚刚庆祝超过500,000网站的诞生，网络上的商业应用还是凤毛麟角，Web
Service不知为何物，SOA还只是束之高阁的理论概念。直到2000年以后，W3C才成立了相关的委员会，开始讨论Web
Service的相关标准;各大厂商一边积极参与标准制定，一边推出了一系列实实在在的产品。新的技术和新的产品出现，SOA找到了可以依托的凭借。随着
Web Service技术的推出和应用，SOA的思想被一个个效益显著的信息系统建设项目不断的示范，才逐渐成为现今的热门话题。类似的情况让人联想到爱因斯坦提出来的理论，著名的质量能量转化等式E=mc2，直到人们掌握了核子裂变技术，才成功生产出了原子弹，向世人展示了这个理论等式的巨大威力。
因为现在几乎所有的SOA应用场合都是和Web Service绑定的，所以不免有时候这两个概念混用。不可否认Web
Service是现在最适合实现SOA的技术，SOA的走红在很大程度上归功于Web
Service标准的成熟和应用普及。因为现在大家基本上认同Web Service技术在几方面体现了SOA的需要：
首先是基于标准访问的独立功能实体满足了松耦合要求：在Web Service中所有的访问都通过SOAP访问进行，用WSDL定义的接口封装，通过UDDI进行目录查找，可以动态改变一个服务的提供方而无需影响客户端的配置，外界客户端是根本不关心访问服务器端的实现。
其次，适合大数据量低频率访问符合服务大颗粒度功能：基于性能和效率平衡的要求，SOA的服务提供的是大颗粒度的应用功能，而且跨系统边界的访问频率也不会象程序间函数调用那么频繁。通过使用WSDL和基于文本(Literal)的SOAP请求，可以实现能一次性接收处理大量数据。
最后，基于标准的文本消息传递为异构系统提供通讯机制：Web Service所有的通讯是通过SOAP进行的，而SOAP是基于XML的，XML是结构化的文本消息。从最早的EDI开始，文本消息也许是异构系统间通讯最好的消息格式，适用于SOA强调的服务对异构后天宿主系统的透明性。
综合上述观点，Web Service不愧为当前SOA的最好选择。然而，就SOA思想本身而言，并不一定要局限于Web
Service方式的实现。更应该看到的是SOA本身强调的是实现业务逻辑的敏捷性要求，是从业务应用角度对信息系统实现和应用的抽象。随着人们认识的提
高，还会有新技术不断的发明出来，更好的来满足这个要求。就好像在核子裂变之后，人们又发现了威力更加强大的核子聚变。为了要有一个更高的角度来看待问
题，SOA和Web Service还是不应该混为一谈
Web Service是就现在而言最适合实现SOA的一些技术的集合，事实上最近SOA的火爆在很大程度上归功于Web
Service标准的成熟和应用的普及为广泛的实现SOA架构提供了基础。下面让我们看看Web
Service中的各种协议是如何互相工作来满足SOA所需的特点的：
独立的功能实体：通过UDDI的目录查找，我们可以动态改变一个服务的提供方而无需影响客户端的应用程序配置。所有的访问都通过SOAP访问进行，只要WSDL接口封装良好，外界客户端是根本没有办法直接访问服务器端的数据的。
大数据量低频率访问：通过使用WSDL和基于文本(Literal)的SOAP请求，我们可以实现能一次性接收大量数据的接口。这里需要着重指出的是
SOAP请求分文本方式和远程调用(RPC)两种方式，正如上文已经提到的，采用远程调用方式的SOAP请求并不符合这点要求。但是令人遗憾的是现有的大
多数SOAP请求采用的仍然是远程调用(RPC)方式，在某些平台上，例如IBM
WebSphere的早期版本，甚至没有提供文本方式的SOAP支持。
基于文本的消息传递：Web Service所有的通讯是通过SOAP进行的，而SOAP是基于XML的，不同版本之间可以使用不同的DTD或者XML Schema加以辨别和区分。因此只需要我们为不同的版本提供不同的处理就可以轻松实现版本控制的目标。
screen.width-500)this.width=screen.width-500" border="0">