转自ibm java dev
------------------
web 服务是通过 wsdl 文档来描述的。wsdl 绑定描述了如何把服务绑定到消息传递协议（特别是 soap 消息传递协议）。wsdl soap 绑定可以是 rpc 样式的绑定，也可以是文档样式的绑定。同样，soap 绑定可以有编码的用法，也可以有文字的用法。这给我们提供了四种样式/用法模型：
- rpc/编码
- rpc/文字
- 文档/编码
- 文档/文字
除了这些样式之外，还有一种样式也很常见，它称为文档/文字包装的样式，算上这一种，在创建 wsdl 文件时您就有了五种绑定样式可以从中选择。您应该选择哪一种呢？
对于本文的讨论，让我们从 中的 java 方法开始，并且对其应用 jax-rpc java-to-wsdl 规则
public void mymethod(int x);
|
采用 中的方法并且使用您喜欢的 java-to-wsdl 工具来运行它，指定您想让它生成 rpc/编码的 wsdl。您最后应该得到如 所示的 wsdl 片断。
现在用“5”作为参数 x 的值来调用此方法。我们将发送一个与 类似的 soap 消息。
对于这个 rpc/编码的示例中的 wsdl 和 soap 消息，有许多需要注意的事项：
- wsdl 基本达到了尽可能地简单易懂的要求。
- 操作名出现在消息中，这样接收者就可以很轻松地把消息发送到方法的实现。
- 类型编码信息（比如
xsi:type="xsd:int" ）通常就是降低吞吐量性能的开销。 - 您不能简单地检验此消息的有效性，因为只有
5 行包含在 schema 中定义的内容；其余的 soap:body 内容都来自 wsdl 定义。
有没有一种方法能够保留这些优点而消除其中的缺点呢？或许有。让我们来看一看 rpc/文字的样式。
用于我们的方法的 rpc/文字的 wsdl 看起来与 rpc/编码的 wsdl 几乎一样（请参见 ）。只是绑定的用法由 编码改为 文字。仅此而已。
rpc/文字的 soap 消息又是怎样的呢（请参见 ）？这里的更改要多一点。去掉了类型编码。
下面是这种方法的优点和缺点：
- wsdl 还是基本达到了尽可能地简单易懂的要求。
- 操作名仍然出现在消息中。
- 去掉了类型编码。
- 您仍然不能简单地检验此消息的有效性，因为只有
5 行包含在 schema 中定义的内容；其余的 soap:body 内容都来自 wsdl 定义。
文档样式如何呢？它们能够帮助克服这些困难吗？
我不知道有谁懂得这种方法的真正含义。我也不知道这种方法的任何实现。它将可能从 wsdl 的后续版本中消失。所以我们还是讨论别的吧。
文档/文字的 wsdl 对 rpc/文字的 wsdl 作了一些更改。它们之间的不同之处显示在 中。
而现在的 soap 应该如 所示：
下面是这种方法的优点和缺点：
- 没有编码信息
- 您可以在最后用任何 xml 检验器检验此消息的有效性。
soap:body （ 5 ）中每项内容都定义在 schema 中。
- wsdl 变得有些复杂。不过，这是一个非常小的缺点，因为 wsdl 并没有打算由人来读取。
- soap 消息中缺少操作名。而如果没有操作名，发送就可能比较困难，并且有时变得不可能。
文档/文字的样式看起来似乎只是重新安排了 rpc/文字的模型的优点和缺点。您可以检验消息的有效性，但是您失去了操作名。有没有一种方法可以改进这一点呢？有的。它就是文档/文字包装的样式。
在我说明文档/文字包装的样式的含义之前，让我给您展示 和 中的 wsdl 和 soap 消息。
wsdl schema 现在把参数放在包装中（请参见 ）。
注意到此 soap 消息看起来非常类似于 rpc/文字的 soap 消息。您可能会说，它看起来与 rpc/文字的 soap 消息是完全一样的，不过，这两种消息之间存在着微妙的区别。在 rpc/文字的 soap 消息中，
文档/文字包装的样式的特征有：
- 输入消息只有一个组成部分。
- 该部分就是一个元素。
- 该元素有与操作相同的名称。
- 该元素的复杂类型没有属性。
下面是这种方法的优点和缺点：
- 没有编码信息。
- 出现在 soap:body 中的每项内容都是由 schema 定义的，所以您现在可以很容易地检验此消息的有效性。
- 方法名又出现在 soap 消息中。
- wsdl 甚至更复杂，但是这仍然是一个非常小的缺点。
如您所见，文档/文字包装的样式还是有一些缺点，不过与优点比起来，它们都显得无足轻重。
这种包装的样式来源于 microsoft。没有定义这种样式的规范；所以虽然这种样式是一个好的东西，但不幸的是，为了与 microsoft 和其他公司的实现进行互操作，现在惟一的选择就是根据 microsoft wsdl 的输出来猜测它是如何工作的。文档/文字包装的样式也实现在 ibm websphere sdk for web services 中（请参见 ）。在这个示例中，样式是相当明显的；但是也存在个别情况，在这些情况中，由于缺少定义而导致需要操作的适当事项不够特别清晰。我们希望看到的最理想的情况就是将来能有像 web 服务互操作组织（web services interoperability organization）这样的独立团体来帮助对此进行稳定化和标准化。
至此，本文已经给了您这样的一个印象，文档/文字包装的样式是最好的方法。而实际的情况往往确实如此。不过，仍然存在着一些情况，在这些情况下，您最好是换一种别的样式。
如果您已经重载了操作，就不能采用文档/文字包装的样式。
想象一下，除了我们一直在使用的方法之外，还有另一种方法，请参见 。
public void mymethod(int x);
public void mymethod(int x, string y);
|
wsdl 允许重载的操作。但是当您添加包装的样式到 wsdl 时，需要元素有与操作相同的名称，并且在 xml 中不能有两个名称相同的元素。所以您必须采用文档/文字非包装的样式或某种 rpc 样式。
由于文档/文字非包装的样式没有提供操作名，所以在有些情况下，您将需要采用某种 rpc 样式。比如说 中的一组方法。
public void mymethod(int x);
public void mymethod(int x, string y);
public void someothermethod(int x);
|
现在假定您的服务器接收到文档/文字的 soap 消息（您可以回过头在 中看一看它）。服务器应该发送哪一种方法呢？所有您能确切知道的就是，它一定不是 mymethod(int x, string x) ，因为消息只有一个参数，而这种方法需要两个参数。它可能是其他两种方法中的一种。采用文档/文字的样式，您没有办法知道是哪一种方法。
假定服务器接收到一个 rpc/文字的消息（比如 中的），而不是文档/文字的消息。对于这种消息，服务器很容易决定把它发送到哪一种方法。您知道操作名是 mymethod，并且也知道只有一个参数，所以它必定是 mymethod(int x) 。
采用 rpc/编码的理由有很多。其中两个主要的原因是：
数据图形
设想您有一个二进制树，其中的节点定义在 中。
根据这种节点定义，我们可以构造一个树形结构，它的根节点 a 通过它左边和右边的的链接可以指向节点 b（请参见 ）。
发送数据图形的标准方式是使用 href 标记，它是 rpc/编码的样式（ ）的一部分。
在任何文字的样式中，href 属性都是不可用的，这样图形链接就不再起作用了（ 和 ）。您仍然有一个根节点 a，它从左边指向一个节点 b，从右边指向另一个节点 b。这两个 b 节点是等同的，但它们不是相同的节点。是复制了数据而不是引用了两次数据。
在文字样式中，您可以通过各种方法构造图形，但是却没有标准的方法；所以您做的任何事情很可能不能与网络中其他端点上的服务进行互操作。
多态性
看一看 中使用多态性 schema 的 wsdl。
当您把一个 dog 的实例传送给 train 操作时，所生成的 soap 消息必须包含类型编码信息，这样接收终端才能知道它所接收的是 animal 的哪一个扩展（请参见 ）。这种类型编码信息可用在 rpc/编码的样式中。
有四种绑定样式（其实真正有五种，不过文档/编码的样式没有什么意义）。虽然每种样式都有自己的用武之地，但是在大多数情况下，最好的样式是文档/文字包装的样式。