序
最近闲时在想能不能自己搞一套分布式开发的框架出来，因为深感使用标准WCF的一些配置繁琐，虽然造车轮的工作非常费精力，劳民伤财，但对理解现在的一些如.net remoting, wcf ,webservice的编程模型和通信原理是非常有帮助的，可在对SOAP的使用进行分析后决定还是不做了，抛弃代价不说，从数据解析、代码生成、安全配置等角度，.net平台的分布式其实做的非常好。可SOAP还是要复习一下的，之前写过一篇文章使用Fiddler来监控WCF的通信过程，观察SOAP的封装情况，其实还不够原生，所以还是重新梳理一下吧。
SOAP由来
一项新技术的诞生，往往是因为要解决某些问题，或者改良当时的技术的，SOAP是为了解决应用程序跨互联网通信问题的，之前的RPC（远程过程调用）方式虽然也可以解决远程通信问题，但是安全性和兼容性均存在一些问题，我没有使用过所以不便发表过多言论，这里只说SOAP的这个方案带来的好处：
- 作为协议，W3C统一编程标准
- 使用HTTP通信，跨互联网
- 基于XML，独立于任何平台
- 可绕过防火墙
从上面几点可以看出SOAP的最大好处是：由于有W3C的标准支持，当你部署一个服务到公网，在任何地方，任何平台都能以统一的标准解析服务中的标记，并自己生成访问服务的代码，进而使用这个服务。
基于这些优点，在2000年微软，IBM等公司将这套标准形成协议交由著名的W3C，进而才形成了编程领域的统一标准，当然，像这些大型的公司据说有部分员工就是W3C的顾问，国内的软件公司在这方面做的还不够，标准的制定对技术的发展有很大的推动。
SOAP标准
一个服务公开了自己的SOAP服务接口后，服务使用方是怎么识别出这些内容代表什么意思呢？这就是标准的意义--形成共识，一个SOAP消息的基本结构是
- Envelope 这个节点标注了SOAP的命名空间，也可以说标准，个人理解是这个地址是指出了此文件的标准制定方
- Body节点是说明了这个SOAP的调用方法等
SOAP消息还有另外两个不太常用的节点
- Header可以在这里加入一些头信息（记得吗？webservice的用户名密码验证）
- Fault是指在处理SOAP过程中发生的错误信息
SOAP消息收发
由于SOAP消息是通过HTTP方式发送的，那么一定是在HTTP标准下进行发送接收的，让我们通过Fiddler来观察一下是不是这样
首先我们向服务端发送一个请求
注意上图中大的矩形中内容其实就是普通的HTTP请求头，而下面跟着的即是我们的SOAP包了，这个数据包中含有
- Post 请求方式
- Content-Type 内容类型（这里是XML）和编码方式
- Host 主机
- Content-Lenth 数据大小
当服务端收到这个消息后就会作出相应的处理了，返回给客户端了一个数据包
服务端返回的格式依然是标准的HTTP协议格式
HTTP/1.1 200 OK 说明服务器成功处理请求
Server 是服务器的IIS，这里是VS中轻量级的web server
SOAP的自动化
SOAP是应用程序远程调用的基础，既然那么重要，可我们为什么不常见到上面说的那些消息格式呢？而经常使用的方式可能是：
总结
本文转自xshf12345 51CTO博客，原文链接：http://blog.51cto.com/wengyuli/593319，如需转载请自行联系原作者
