SOAP 技术与 B2B 应用集成（ 5 ）

本文最初由 IBM developerWorks 中国网站发表，其网址是

http://www.ibm.com/developerWorks/cn/

SOAP 技术总结及其在 InterOP Stack 中的作用

在先前的系列文章中，已经系统地介绍了 SOAP 技术的各个组成部分： SOAP Message 、 SOAP Envelope 、 SOAP Encoding 、 SOAP RPC Presentation 等。在这里，我就各个组成部分的协作和功能作一个总结。并就各个部分在 B2B 应用中的地位加以阐述。在本文的第二部分，将概述 InterOP Stack 整个技术体系与 SOAP 的关系及其协同，使大家能了解 SOAP 在整个体系中的功能及应用。在 SOAP 技术与 B2B 应用集成系列之后的文章系列中，我将会介绍 WSDL 和 UDDI ，到时候大家就能对整个 InterOP Stack 中各项技术的协作有一个更全面，更清楚的认识，并进一步认识到 SOAP 技术的重要性。

SOAP 技术总结

SOAP Message(SOAP 消息 ) 是用于传输应用入口调用信息的承载体，尤其是 B2B 应用调用。从根本上来看， SOAP Message 是从发送方到接受方的一种传输方法。在 B2B 应用中， SOAP 消息是 B2B 应用调用信息的基本承载体。

SOAP Envelope(SOAP 信封 ) 用于描述 SOAP Message 的结构，定义了一个以 SOAP Header ， SOAP Body 为子主体的描述结构。 SOAP Envelope 是 SOAP Message 的信息框架。在 B2B 应用中， SOAP Envelope 为 B2B 应用调用信息提供了一个基本的信息描述框架。

SOAP Header 提供了一个可伸缩的机制用于在分散的模块化扩展 SOAP 消息，而通讯双方并不需要有预先的约定知识。在 B2B 应用中的典型的扩展例子可以是实现一些诸如认证、事务管理以及支付的 Header 条目。

SOAP Body 元素提供一个简单的用于与消息的最终接收者交换必须处理的信息的机制。在 SOAP Body 中可以描述应用入口调用和响应的各种数据信息。在 B2B 应用中， Body 元素的应用可以是 B2B 应用调用请求信息 ( 如产品 ID 、产品数量等 ) 和响应信息 ( 如订单号、订单履行日期 ) 及错误信息 ( 如产品库存不够等 ) 。

SOAP Encoding(SOAP 遍序方法 ) 是基于一个简单类型系统，而这个系统是程序语言、数据库和半结构数据中类型系统的公共特性的泛化。默认的 SOAP Encoding 定义和 XML Schema 是相容的，基本一致的。 SOAP Encoding 使类似整数 (integer) 、字符串 (string) 、数组 (array) 、结构 (struct) 等数据类型得以在 SOAP 消息的表示。 SOAP Encoding 为 SOAP Header 和 SOAP Body 中的数据表示提供了默认的方式，当然你也可以使用其他任意基于 XML Schema 的型 / 值描述系统。

SOAP RPC Presentation(SOAP RPC 表示 ) 是一个用于表示远端过程调用和响应的约定，利用 XML 的可扩展性和可伸缩性来包装和交换 RPC 调用。目前通过绑定各种已有的 Internet 协议，譬如 HTTP 、 SMTP 、 POP3 等，利用这些协议的调用响应机制，完成 SOAP 的调用和响应。具体地说， SOAP 消息会作为这些协议的正文被发送。也就是说将 SOAP 协议包上了一个 HTTP 的外壳，在 HTTP Network 里面传输，当然 SMTP 、 POP3 也是同样。 SOAP RPC Presentation 是最终面向传输的绑定机制。

各个组件协作的组成可以参阅下图：

SOAP 技术在 InterOP Stack 体系中的作用和地位

如果把 B2B 应用利用 InterOP Stack 技术进行交互与程序员使用编程技术和资源进行应用开发相对比的话 ( 尽管不是非常贴切 ) 。 SOAP 就是各种编程语言中提供调用函数，调用服务，调用外部应用的标准调用方法和联编技术。 WSDL 就是使程序员理解调用界面的界面描述，即开发手册和参考手册。而 UDDI 则包含了函数、服务资源库，资源检索引擎等。

对于开发人员而言，他的流程一般是，通过 UDDI Operator 或 UDDI Search Engine 的 Web 界面在 UDDI Registry(Public 的或 Private 的 UDDI Registry) 上找到需要的 Web Service ，然后在 UDDI Registry 内，或通过 UDDI Registry 中的连接找到该 Web Service 的调用规范，该调用规范一般是使用 WSDL 描述，当然按照 InterOP Stack 系列技术的一贯惯例，该规范也可以使用任意另外一种相容的技术规范来描述。开发人员可以使用开发工具或通过手动方式理解该调用规范，然后在自己的应用中加上该调用规范定义的 Web Service 调用。然后开发出的应用就可以通过 SOAP 来调用该指定的 Web Service 了。

而对于具有自动集成相关应用的服务 (Service) 或应用 (Application) ，它的流程一般是，应用户需求通过 SOAP 协议访问 UDDI Operator 或 UDDI Registry 找到需要的 Web Service ， UDDI Operator 和 UDDI Registry 会通过 SOAP 协议响应 Web Service 的调用规范和调用规范的链接，应用程序得到使用 WSDL 描述的服务调用规范文本，通过解析该描述文本，自动生成本地调用接口绑定，并将所需的调用参数适当绑定并完成调用。

我们来考察一下这两种流程，第一种需要人去阅读 WSDL 文本，相对而言对开发人员要求比较高，而且造成不必要的麻烦，因为 WSDL 本来就是给计算机来阅读的。而第二种流程中，由应用来自动完成参数的绑定，这对应用程序的 AI 要求又过高了。因此建议在实施 Web Service 架构，使用 InterOP Stack 技术的时候，应当使用开发工具完成 WSDL 语言的解析并生成具体开发语言中的调用界面，比如 VB 中的 RPC 类型的 Interface ， Java 中的方法形式的 Interface 等等。最后由开发人员来完成参数的绑定。

从上面的分析中我们可以发现， SOAP 是整个体系的基础，是服务调用的基本协议。因此一个 SOAP 消息的传输网络对于 Web Service 体系的有效建设是多么必要。

结语

SOAP 技术与 B2B 应用集成的系列文章到这里就告一段落了，希望大家通过阅读本系列的文章对 SOAP 技术能有一个全面的认识，我将在以后的文章中介绍 Web Service 的另一个基础技术 WSDL ，以及 Web Service 的协作注册技术 UDDI 。希望大家能通过本专栏对 Web Service/InterOP Stack 这一今天的新兴技术，明天的主流技术有一个全面的认识。