XML Web Service 基础 (转微软MSDN）

开始使用 SOAP 时，最容易混淆的是 SOAP 规范及其许多实现方案之间的差异。多数使用 SOAP 的用户并不直接编写 SOAP 消息，而是使用 SOAP 工具包来创建和分析 SOAP 消息。这些工具包通常将函数调用从某种语言转换为 SOAP 消息。例如，Microsoft SOAP Toolkit 2.0 将 COM 函数调用转换为 SOAP，而 Apache Toolkit 将 JAVA 函数调用转换为 SOAP。函数调用的类型和支持的参数的数据类型随每个 SOAP 实现方案的不同而不同，因此适用于一个工具包的函数可能并不适用于另一个工具包。这并不是 SOAP 的限制，而是所使用的特定实现方案的限制。

到目前为止，SOAP 最引人注目的特征是它可以在许多不同的软件和硬件平台上实现。这意味着 SOAP 可用于链接企业内部和外部的不同系统。过去曾试过多种方法以提出一个可用于系统集成的通用通信协议，但它们都没有象 SOAP 一样获得广泛的认可。为什么呢？因为与许多早期的协议相比，SOAP 更小巧，而且更易于实现。例如，DCE 和 CORBA 的实现需要数年时间，所以只发布了很少几个实现方案。而 SOAP 可以利用现有的 XML 分析器和 HTTP 库完成大部分艰苦的工作，因此 SOAP 实现方案在数月内便可完成。这就是为什么现在已经有 70 多个 SOAP 实现方案的原因。当然，SOAP 并不具备 DCE 或 CORBA 的全部功能，虽然功能减少了，但由于其复杂程度大大降低了，因此 SOAP 更易于应用。

HTTP 的普及和 SOAP 的简单性使您几乎可以从任何环境调用它们，因此成为 XML Web Service 的理想基础。有关 SOAP 的详细信息，请参阅 MSDN （英文）主页。

安全性如何？

通常，刚接触 SOAP 的用户提出的第一个问题就是 SOAP 如何解决安全性问题。在其早期开发阶段，SOAP 被看作是基于 HTTP 的协议，所以认为 HTTP 的安全性对于 SOAP 已经足够了。毕竟目前有数以千计的 Web 应用程序都在使用 HTTP 安全性，所以这对于 SOAP 确实已经足够。因此，当前的 SOAP 标准假定安全性属于传输问题，而并不作为安全性问题处理。