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并没有什么神秘可言，所有的东西都是建立在已有东西的基础之上。技术的发展不会是无中生有，只会是一个更好的解决方案而已，在追新求变之前，一个比较牢固的基础才是最重要