序
最近闲时在想能不能自己搞一套分布式开发的框架出来，因为深感使用标准WCF的一些配置繁琐，虽然造车轮的工作非常费精力，劳民伤财，但对理解现在的一些如.net remoting, wcf ,webservice的编程模型和通信原理是非常有帮助的，可在对SOAP的使用进行分析后决定还是不做了，抛弃代价不说，从数据解析、代码生成、安全配置等角度，.net平台的分布式其实做的非常好。可SOAP还是要复习一下的，之前写过一篇文章使用Fiddler来监控WCF的通信过程，观察SOAP的封装情况，其实还不够原生，所以还是重新梳理一下吧。SOAP由来
一项新技术的诞生，往往是因为要解决某些问题，或者改良当时的技术的，SOAP是为了解决应用程序跨互联网通信问题的，之前的RPC（远程过程调用）方式虽然也可以解决远程通信问题，但是安全性和兼容性均存在一些问题，我没有使用过所以不便发表过多言论，这里只说SOAP的这个方案带来的好处：- 作为协议，W3C统一编程标准
- 使用HTTP通信，跨互联网
- 基于XML，独立于任何平台
- 可绕过防火墙
基于这些优点，在2000年微软，IBM等公司将这套标准形成协议交由著名的W3C，进而才形成了编程领域的统一标准，当然，像这些大型的公司据说有部分员工就是W3C的顾问，国内的软件公司在这方面做的还不够，标准的制定对技术的发展有很大的推动。
SOAP标准
一个服务公开了自己的SOAP服务接口后，服务使用方是怎么识别出这些内容代表什么意思呢？这就是标准的意义--形成共识，一个SOAP消息的基本结构是在之前做的Demo中，一个SOAP消息是这样的：
上面其实就是一个XML文件内容，包含了服务中的方法名称和参数等内容，但是这个内容有两个节点是必不可少的：
- Envelope 这个节点标注了SOAP的命名空间，也可以说标准，个人理解是这个地址是指出了此文件的标准制定方
- Body节点是说明了这个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是应用程序远程调用的基础，既然那么重要，可我们为什么不常见到上面说的那些消息格式呢？而经常使用的方式可能是：var proxy=new TestService.AddServiceClient(); proxy.GetPerson();
这主要是因为开发工具或者说开发框架已经替我们做了协议识别的工作，这个过程跟WSDL密(网络服务描述语言)切相关，比如我们调用一个Webservice，
visualstudio就会自动根据服务端的WSDL来确定自己要生成的代理类。
总结
SOAP是一种很不错的跨应用程序、跨平台解决方案，利用XML的多平台性和W3C的统一标准，使各种程序能够在同一个标准下进行通信，我在想如果将XML改造成JSon来做会不会更好呢？
最新评论