以下为网上看到的对Web Service比较经典易懂的分析，转录之．

Web Service是最近几年比较火的一个东西，它带来了一大堆的新名词，所以显得比较炫。看透其华而不实的表面，它也就不再神奇。下面的讨论均以Java为参考。 

1 访问一个Web Service实际上可以看作调用一个函数，唯一不同的就是这个函数是远程的，这么一说，它和RMI就没有什么本质的区别了。 
既然是一个函数，当然要有函数的声明了，完成这个工作的就是WSDL，它详细的定义函数的原型，包括函数名、入口参数、出口参数，这就是WSDL中opertion完成的工作。 
既然是一个远程的函数，还要涉及与远程地址的一个绑定，这是WSDL中service的任务。 
Axis是一个可以通过WSDL生成相应访问代码的开发包，JBuilder中将它集成了进去，通过Wizard的方式简化了原本需要在命令行中手工完成的操作。 

2 既然是远程访问，就一定要有一个访问协议，Web Service的访问协议就是SOAP，SOAP建立在XML之上，不同的就是对XML原本没有限制的格式加上了一些限制，需要有envelope，在envelope中，还要分header和body。 
如果利用SOAP开发Web Service的程序，那就需要根据WSDL的定义来自行组装SOAP包，这显然要比利用WSDL直接面向Web Service开发要复杂一些。 
JAXM是一个利用SOAP进行通信的开发包，它简化了SOAP消息的打包过程。 

3 SOAP是建立在XML之上的，那么显然XML的开发包同样适合于SOAP。 
在这个层次上开发Web Service，除了要完成上一层的工作外，还要自行按照SOAP的格式组装SOAP消息，这显然又增加了工作量。 
XML的开发工具就比较多了，从最简单的SAX和DOM到DOM4J、JDOM，还有不少XML到对象绑定的工具，如JAXB、Castor等等。 
其实，不考虑Web Service，完全用XML做通信协议的情况也并不少见。知晓XML-RPC的存在，就不难理解了XML做通信的含义了。 

截至到这里所讨论的内容，Sun提供了JWSDP（Java Web Service Developer Pack），其中包含从XML解析到WSDL生成的全套解决方案。 

4 上面讨论的所有东西实际上都还停留在传递消息的内容上，并未涉及通信的过程。不要一看到Web Service的Web就想当然认为它只能通过HTTP来传输。前面的讨论可以看出，所有的消息内容与传输并无直接关系，所以，无论是以HTTP传输，还是SMTP或是自定义的协议都没有问题。 
在这个层次上开发Web Service，前面的种种险阻之外，还要完成对XML的手工解析工作。 
这里还是以最常见的HTTP方式来讨论。 
HTTP的开发就将Server和Client区别对待，Server的实现通常的选择是Servlet，让Web Server替我们完成HTTP协议的解析可以省去我们很多的作。Client的实现可以选择JDK自带的Http Client，Apache的Jakarta项目下的Commons子项目也提供了一个HttpClient。 

5 无论是HTTP还是SMTP，抑或是自定义协议，归根结底都是应用级的协议，底层的实现都是由Socket完成。到了这个层次基本就是原始时代了，什么都没有，一切都要手工完成。 
在这个层次上开发Web Service，所有前面的困难都要一一经历，此外，还有协议的开发等待着不幸至此的人们。 
到了这里，也不需要其它的工具了，JDK自带的Socket可以保打天下。 

6 还想往下吗？再往下就是操作系统的实现了，Java的平台无关就失去了意义，也超出了我目前所了解的范围，到此打住吧！ 

前面所提及应该算是Web Service的一个基本知识结构，这里并没有讨论UDDI等等的内容，一来我对它并不了解，二来那应该属于应用，不应该算Web Service实现中。 

虽然我们可能不会从最下层开发Web Service，但遇到底层的问题的情况却在所难免。 
我就曾经在开发一个Web Service应用的时候，被人抓住HTTP头中的SOAPAction大小写与某个所谓的规范不同，我查了半天HTTP规范和SOAP规范，知道了HTTP是区分大小，而SOAPAction就是应该这么写，据理力争，指出所谓规范的错误。 

经过前面的讨论，我们可以看出，Web Service并没有什么神秘可言，所有的东西都是建立在已有东西的基础之上。技术的发展不会是无中生有，只会是一个更好的解决方案而已，在追新求变之前，一个比较牢固的基础才是最重要

查看原文地址