|
Russell Butek
Web 服务顾问, IBM
2003 年 10 月 31 日
2005 年 6 月 29 日 更新
WSDL 绑定样式可以是 RPC 样式或文档样式。用法可以是编码的，也可以是文字的。您如何决定使用哪一种样式/用法的组合呢？本文将帮助您解决这个问题。
引言
Web 服务是通过 WSDL 文档来描述的。WSDL 绑定描述了如何把服务绑定到消息传递协议（特别是 SOAP 消息传递协议）。WSDL SOAP 绑定可以是 RPC 样式的绑定，也可以是文档样式的绑定。同样，SOAP 绑定可以有编码的用法，也可以有文字的用法。这给我们提供了四种样式/用法模型：
- RPC/编码
- RPC/文字
- 文档/编码
- 文档/文字
除了这些样式之外，还有一种样式也很常见，它称为文档/文字包装的样式，算上这一种，在创建 WSDL 文件时您就有了五种绑定样式可以从中选择。您应该选择哪一种呢？
在我进一步讨论以前，让我阐明一些容易混淆的地方。这里，这些术语是非常不合适的：RPC 与文档。这些术语意味着 RPC 样式应该用于 RPC 编程模型，文档样式应该用于文档或消息编程模型。 但事实完全不是这样。样式对于编程模型没有任何意义。它只是指明了如何将 WSDL 绑定转化为 SOAP 消息。其他就没什么了。你可以将任一种样式用于任何编程模型。
同样，术语编码和文字只对于 WSDL 到 SOAP 映射有意义，可是，至少这里，这两个单词的字面意思更容易理解一些。
对于这篇讨论，让我们从清单 1 中的 Java 方法开始，并且应用 JAX-RPC Java-to-WSDL 规则（参阅参考资料查看 JAX-RPC 1.1 规范）。 清单 1. Java 方法
public void myMethod(int x, float y);
|
RPC/编码
采用清单 1 中的方法并且使用你喜欢的 Java-to-WSDL 工具来运行，指定您想让它生成 RPC/编码的 WSDL。您最后应该得到如清单 2 所示的 WSDL 片断。 清单 2. 用于 myMethod 的 RPC/编码的 WSDL
<message name="myMethodRequest">
<part name="x" type="xsd:int"/>
<part name="y" type="xsd:float"/>
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
<!-- I won't bother with the details, just assume it's RPC/encoded. -->
|
现在用“5”作为参数 x 的值，“5.0”作为参数 y 的值来调用这个方法。发送一个如清单 3 所示的SOAP 消息。 清单 3. 用于 myMethod 的 RPC/编码的 SOAP 消息
<soap:envelope>
<soap:body>
<myMethod>
<x xsi:type="xsd:int">5</x>
<y xsi:type="xsd:float">5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
|
|
关于前缀和命名空间的注意事项
为了简单起见，在本文的大部分 XML 示例中，我省略了命名空间和前缀。不过，我还是使用了少数前缀，您可以假定它们是用下列名称空间进行定义的：
- xmlns:xsd="http://www.w3.org/2001/XMLSchema"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
关于命名空间和 WSDL-to-SOAP 映射的讨论，请参考文章“Handle namespaces in SOAP messages you create by hand”（参阅 参考资料）。 |
关于 RPC/编码例子中的 WSDL 和 SOAP 消息有一些需要注意的地方：
优点
- WSDL 尽可能的简单明了。
- 操作名出现在消息中，因此接收者可以很容易的将消息分派到操作的实现。
缺点
|
遵照 WS-I
各种 Web 服务规范有时候是不一致和不明确的。WS-I 组织成立用来解决这些规范上的问题。它已经定义了许多概要，指明了你应该如何编写 Web 服务来实现互操作性。要获取 WS-I 的更多信息，请参阅参考资料中的 WS-I 链接。 |
- 类型编码信息（
xsi:type="xsd:int"）通常就是降低吞吐量性能的开销。
- 你不能很容易的验证这个消息的有效性，因为只有
<x ...>5</x> 和 <y ...>5.0</y> 行包含 Schema 中定义的内容；soap:body 内容的其余部分来自于 WSDL 定义。
- 虽然它是合法的 WSDL，但 RPC/encoded 是不遵守 WS-I 的。
有没有一种方法可以取其精华，弃其糟粕呢？可能有。让我们看一下 RPC/文字样式。
RPC/文字
用于这个方法的 RPC/文字样式的 WSDL 看起来与 RPC/编码的 WSDL（清单 4）几乎一样。绑定的用法从 编码 变为 文字。仅此而已。 清单 4. 用于 myMethod 的 RPC/文字样式的 WSDL
<message name="myMethodRequest">
<part name="x" type="xsd:int"/>
<part name="y" type="xsd:float"/%gt;
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
<!-- I won't bother with the details, just assume it's RPC/literal. -->
|
RPC/文字的 SOAP 消息又是怎样的呢（参阅清单 5）？这里的更改要多一点。去掉了类型编码。 清单 5. 用于 myMethod 的 RPC/literal SOAP 消息
<soap:envelope>
<soap:body>
<myMethod>
<x>5</x>
<y>5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
|
|
关于 xsi:type 和文字用法的注意事项
虽然在一般情况下，xsi:type 没有出现在文字 WSDL 的 SOAP 消息中，但是仍然有一些情况，类型信息是必须的，并且它将以多种形式出现。如果 API 期望一个基础类型，并且发送一个扩展实例，则必须提供这个实例的类型以便正确的反序列化该对象。 |
这里是这种方法的优点和缺点：
优点
- WSDL 尽可能的简单明了。
- 操作名仍然出现在消息中。
- 去掉了类型编码。
- RPC/文字是遵循 WS-I 的。
缺点
- 你仍然不能很容易的验证这个消息的有效性，因为只有
<x ...>5</x> 和 <y ...>5.0</y> 行中包含定义在 Schema 中的内容；soap:body 内容的其余部分来自于 WSDL 定义。
文档样式如何呢？它们能够帮助克服这些困难吗？
文档/编码
没有人使用这个样式。它不遵循 WS-I。因此此处略过。
文档/文字
文档/文字的 WSDL 在 RPC/文字的 WSDL 基础上做了一些修改。其不同点已经在清单 6 中指出。 清单 6. 用于 myMethod 的文档/文字 WSDL
<types>
<schema>
<element name="xElement" type="xsd:int"/>
<element name="yElement" type="xsd:float"/>
</schema>
</types>
<message name="myMethodRequest">
<part name="x" element="xElement"/>
<part name="y" element="yElement"/>
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
<!-- I won't bother with the details, just assume it's document/literal. -->
|
用于这个 WSDL 的 SOAP 消息如清单 7 所示： 清单 7. 用于 myMethod 的文档/文字 SOAP 消息
<soap:envelope>
<soap:body>
<xElement>5</xElement>
<yElement>5.0</yElement>
</soap:body>
</soap:envelope>
|
|
关于消息组成部分的注意事项
我本来可以只更改绑定，就像我从 RPC/编码转到 RPC/所做的那样。它将是合法的 WSDL。然而，WS-I 基本概要（WS-I Basic Profile）规定文档/文字的消息的组成部分引用元素而不是类型，所以我遵循了 WS-I（并且此处使用元素部分可以很好地把我们带到关于文档/文字包装的样式的讨论）。 |
下面是这种方法的优点和缺点：
优点
- 没有类型编码信息。
- 您可以在最后用任何 XML 检验器检验此消息的有效性。
soap:body 里面的所有内容都定义在 schema 中。
- 文档/文字是遵循 WS-I 的，但是有限制（参阅缺点）。
缺点
- WSDL 有一点复杂。不过，这是一个非常小的缺点，因为 WSDL 并没有打算由人来读取。
- SOAP 消息中缺少操作名。而如果没有操作名，发送就可能比较困难，并且有时变得不可能。
- WS-I 仅仅允许 SOAP 消息中
soap:body 的一个子元素。正如你在清单 7 中所见的那样，该消息的 soap:body 有两个子元素。
文档/文字样式似乎只是重新排列了一下 RPC/文字模型中的优点和缺点。你可以验证该消息，但是你已经失去了操作名。有没有什么办法可以改进这一点呢？是的，它就是文档/文字包装模式。
文档/文字包装模式
在我描述文档/文字包装模式的规则之前，让我先向您展示 WSDL 和 SOAP 消息，如清单 8 和 清单 9 所示。 清单 8. 用于 myMethod 的文档/文字封装的 WSDL。
<types>
<schema>
<element name="myMethod">
<complexType>
<sequence>
<element name="x" type="xsd:int"/>
<element name="y" type="xsd:float"/>
</sequence>
</complexType>
</element>
<element name="myMethodResponse">
<complexType/>
</element>
</schema>
</types>
<message name="myMethodRequest">
<part name="parameters" element="myMethod"/>
</message>
<message name="empty">
<part name="parameters" element="myMethodResponse"/>
</message>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
<!-- I won't bother with the details, just assume it's document/literal. -->
|
WSDL Schema 现在把参数放在包装中（参阅清单 9）。 清单 9. 用于 myMethod 的文档/文字包装的 SOAP 消息
<soap:envelope>
<soap:body>
<myMethod>
<x>5</x>
<y>5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
|
注意这个 SOAP 消息同 RPC/文字的 SOAP 消息（清单 5）非常相似。您可能会说，它看起来与 RPC/文字的 SOAP 消息是完全一样的，不过，这两种消息之间存在着微妙的区别。在 RPC/文字的 SOAP 消息中，<soap:body> 的 <myMethod> 子句是操作的名称。在文档/文字包装的 SOAP 消息中，<myMethod> 子句是单个输入消息的组成部分引用的元素的名称。因此，包装的样式具有这样的一个特征，输入元素的名称与操作的名称是相同的。此样式是把操作名放入 SOAP 消息的一种巧妙方式。
文档/文字包装的样式的特征有：
- 输入消息只有一个组成部分。
- 该部分是一个元素。
- 该元素同操作有相同的名称。
- 该元素的复杂类型没有属性。
下面是该种方法的优缺点：
优点
- 没有类型编码信息。
soap:body 中出现的所有内容都定义在 schema 中，所以您可以很容易地检验此消息的有效性。
- 方法名又出现在 SOAP 消息中。
- 文档/文字是遵守 WS-I 的，并且包装模式符合了 WS-I 的限制，即 SOAP 消息的
soap:body 只有一个子元素。
缺点
文档/文字包装的样式还是有一些缺点，不过与优点比起来，它们都显得微不足道。
|
RPC/文字包装？
从 WSDL 的角度来考虑，没有理由只是把把包装的样式和文档/文字绑定联系在一起。它可以很容易地应用于 RPC/文字绑定。但是这样做是相当不明智的。SOAP 将包含操作的一个 myMethod 元素和元素名称的子 myMethod 元素。另外，即使它是一个合法的 WSDL，RPC/文字元素部分也不遵循 WS-I。 |
文档/文字的样式在哪里定义？
这种包装类型来源于 Microsoft?。并没有任何规范来定义这个类型；因此虽然这个类型是一个好东西，但不幸的是，为了与 Microsoft 和其他公司的实现进行互操作，现在惟一的选择就是根据 Microsoft WSDL 的输出来猜测它是如何工作的。该模式已经出现了一段时间，并且业界也很好的理解了它，虽然该模式在例子中是非常明显的，但是也有一些内容不够清晰。我们希望一个独立的组织比如 WS-I 来帮助稳定和标准化这一模式。
为什么不始终采用文档/文字包装的样式
至此，本文已经给了您这样的一个印象，文档/文字包装的样式是最好的方法。而实际的情况往往确实如此。不过，仍然存在着一些情况，在这些情况下，您最好是换一种别的样式。
采用文档/文字非包装的样式的理由
如果您已经重载了操作，就不能采用文档/文字包装的样式。
想象一下，除了我们一直在使用的方法之外，还有另一种方法，请参见清单 10。 清单 10. 用于文档/文字包装的有问题的方法
public void myMethod(int x, float y);
public void myMethod(int x);
|
|
关于重载的操作的注意事项
WSDL 2.0 不会允许重载的操作。这对于一些允许该操作的语言（比如 Java）来说是不幸的。一些规范（比如 JAX-RPC）将不得不定义一个名称转换模式（name mangling scheme）来将重载的方法映射到 WSDL 中。WSDL 2.0 只不过将问题从 WSDL-to-SOAP 映射转移到 WSDL-to-language 映射中。 |
WSDL 允许重载的操作。但是当你向 WSDL 上添加包装模式的时候，需要元素有与操作相同的名称，并且在 XML 中不能有两个名称相同的元素。所以您必须采用文档/文字非包装的样式或某种 RPC 样式。
采用 RPC/文字的样式的理由
由于文档/文字非包装的样式没有提供操作名，所以在有些情况下，您将需要采用某种 RPC 样式。比如说清单 11 中的一组方法。
清单 11. 用于文档/文字非包装的样式的问题方法
public void myMethod(int x, float y);
public void myMethod(int x);
public void someOtherMethod(int x, float y);
|
现在假设你的服务器接收到了文档/文字的 SOAP 消息，你可以回头看一下清单 7。服务器应该发送哪一种方法呢？所有您能确切知道的就是，它一定不是 myMethod(int x)，因为消息有两个参数，而这种方法只需要一个参数。它可能是其他两种方法中的一种。采用文档/文字的样式，您没有办法知道是哪一种方法。
假定服务器接收到一个 RPC/文字的消息，而不是文档/文字的消息，如清单 5 所示。对于这种消息，服务器很容易决定把它发送到哪一种方法。你知道该操作名称是 myMethod，并且你知道你有两个参数，因此肯定是 myMethod(int x, float y)。
采用 RPC/编码的理由
使用 RPC/编码样式最重要的原因是为了数据图表。设想你有一个二进制树，如清单 12 所示。 清单 12. 二进制树节点 schema
<complexType name="Node">
<sequence>
<element name="name" type="xsd:string"/>
<element name="left" type="Node" xsd:nillable="true"/>
<element name="right" type="Node" xsd:nillable="true"/>
</sequence>
</complexType>
|
根据这种节点定义，你可以构建一个树，其根节点 -- A -- 通过左/右链接指向节点 B（参阅图 1）。
图 1. 编码树。
发送数据图表的标准方式是使用 href 标签，它是 RPC/编码的样式（清单 13）的一部分。 清单 13. RPC/编码的二进制树
<A>
<name>A</name>
<left href="12345"/>
<right href="12345"/>
</A>
<B id="12345">
<name>B</name>
<left xsi:nil="true"/>
<right xsi:nil="true"/>
</B>
|
在任何文字样式中，href 属性都是不可用的，这样图形链接就不再起作用了（参阅清单 14 和 图 2）。你仍然有一个根节点 A，其指向左边的节点 B和右边的另一个节点 B。这些节点 B 都是一样的，但是它们不是相同的节点。数据被复制而不是引用两次。 清单 14. 文字二进制树
<A>
<name>A</name>
<left>
<name>B</name>
<left xsi:nil="true"/>
<right xsi:nil="true"/>
</left>
<right>
<name>B</name>
<left xsi:nil="true"/>
<right xsi:nil="true"/>
</right>
</A>
|
图 2. 文字树
在文字样式中，您可以通过各种方法构造图表，但是却没有标准的方法；所以您做的任何事情很可能不能与网络中其他端点上的服务进行互操作。
SOAP 响应消息
到目前为止我已经讨论了请求消息。但是响应消息呢？它们是怎样的呢？现在你应该很清楚一个文档/文字消息的响应消息应该是怎样的。soap:body 的内容是由 schema 定义的，因此你所需要做的就是查看该 schema 来了解响应消息的内容。比如，参考清单 15 来查看清单 8 中的 WSDL 文件的响应消息。 清单 15. 用于 myMethod 的文档/文字包装的响应 SOAP 消息
<soap:envelope>
<soap:body>
<myMethodResponse/>
</soap:body>
</soap:envelope>
|
但是用于 RPC 样式响应的 soap:body 的子元素是什么呢？WSDL 1.1 规范并不是很清楚。但是 WS-I 解决了这个问题。WS-I 的 Basic Profile 指明了在 RPC/文字响应消息中，soap:body 子元素的名称是“... 相应的 wsdl:operation 名称加上字符串 'Response' 作为后缀。”奇怪！这正是常规包装模式的响应元素的名称。因此清单 15 可以应用到 RPC/文字消息和文档/文字包装的消息。（因为 RPC/编码并不是遵守 WS-I 的，WS-I Basic Profile 并不关心 RPC/编码的响应是怎样的，但是你可以假设应用在这里的约定也可以应用在其他任何地方。）因此响应消息的内容并不神秘。
结束语
这里有四种绑定样式（其实是五个，但是文档/编码的样式是没有意义的）。虽然每种样式都有自己的用处，但是在大多数情况下，最好的样式是文档/文字包装的样式。
参考资料
关于作者
Russell Butek 是 IBM 的一名 Web 服务顾问。他是 IBM WebSphere Web 服务引擎的开发人员之一。他也是 JAX-RPC Java Specification Request （JSR） 专家组的 IBM 代表。他从事 Apache 的 AXIS SOAP 引擎的实现方面的研究，推动了 AXIS 1.0 遵循 JAX-RPC 1.0。以前，他是 IBM CORBA ORB 的开发人员和许多 OMG 特别工作组的 IBM 代表：包括可移植拦截器特别工作组（他是这个特别工作组的主席）、核心特别工作组以及互操作性特别工作组。你可以通过 butek@us.ibm.com 与他联系。 | |