尽管是转载的，但是原文中几处错误或者不规范的表达，我已经进行了修改。
大部分 Web 服务都是围绕着远程过程调用而构建的，而 WSDL 规范允许另外一种 Web 服务体系结构：文档样式（ document style ）。在该体系结构中，整个文档在服务客户端和服务器之间进行交换。在本文中， James McCarthy 将向您解释文档样式以及应该何时使用它。
在 Web 服务描述语言（ Web Service Definition Language ， WDSL ）规范中隐含着一个非常巧妙的转换开关，它可以将 Web 服务的 SOAP 绑定从远程过程调用转换成 pass-through 文档。在 SOAP 协议绑定中的样式属性可以包含这两个值中的一个： rpc 或 document 。当属性被设定为文档样式时，客户端知道应该使用 XML 模式而不是远程过程调用约定。本文将提供对这个 WSDL 转换开关的说明，描述它的好处，并将解释应该何时使用 pass-through 文档。
首先，让我们简要地谈谈 WSDL 的一些要点，来理解这个巧妙的转换是如何发生的。 WSDL 是一项 XML 规范，它被用来描述Web服务以及对于到达端点（服务）的协议相关的需求。 WSDL 用抽象术语来描述服务；通过可扩展的绑定定义，它能够为使用具体术语调用服务定义协议和数据格式规范。下面的语法是直接从 WSDL 规范中摘 录出来的，展示了在绑定中所包含的可扩展性元素：
|
<wsdl:definitions .... >
<wsdl:binding name="nmtoken" type="qname"> *
<-- extensibility element (1) --> *
<wsdl:operation name="nmtoken"> *
<-- extensibility element (2) --> *
<wsdl:input name="nmtoken"? > ?
<-- extensibility element (3) -->
</wsdl:input>
<wsdl:output name="nmtoken"? > ?
<-- extensibility element (4) --> *
</wsdl:output>
<wsdl:fault name="nmtoken"> *
<-- extensibility element (5) --> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions> |
WSDL 规范通常描述三种绑定扩展： HTTP GET/POST 、 MIME 以及 SOAP version 1.1 。 HTTP GET/POST 和 MIME 中定义的绑定扩展用来定义与标准的 Web 应用程序进行通信的需
求，这些应用程序可能返回（也可能不返回） XML 文档。在发送或返回 XML 文档时， HTTP GET/POST 绑定的扩展是隐式的文档样式。
SOAP 绑定扩展用来定义支持 SOAP 信封协议的服务。 SOAP 信封是一种简单模式，它设计成能包含 XML 消息，提供特定于应用程序的消息头和消息体。 SOAP 绑定的扩展使 WSDL 文档能够声明 SOAP 消息的需求，这样应用程序就能够与服务正确通信。 SOAP 扩展允许将 SOAP 消息的样式声明为文档或 RPC 。如果在 soap:binding 元素中声明了样式属性，那么该样式将成为所有没有显式声明的样式属性的 soap:operation 元素的缺省值。如果在 soap:binding 元素中没有声明样式属性，那么缺省的样式就是文档。下面是文档样式的显式声明：
|
<soap:binding style="document" transport="uri"> |
不管 soap:binding 元素中的声明如何， soap:operation 元素可以覆盖每个操作的声明，就像这样的：
|
<soap:operation soapAction="uri" style="document"> |
在声明了文档样式的 SOAP 消息中，原始（ as-is ）或编码（ encoded ）的消息被直接放置在 SOAP 信封的体部。
如果样式声明为 RPC ，消息就封装在包装器元素中，同时带有从操作名属性中提取的的元素的名称以及从操作名称空间属性中提取的名称空间。
勿庸置疑，使用 XML 调用跨平台的远程过程调用的能力是非常有用的，它是使用 Web 服务的非常有说服力的理由。但是如果 Web 服务仅仅局限于 RPC 消息传递，这项技术的影响将是有限的。幸运的是，开发人员可以选择是使用 RPC 还是文档样式的消息传递，并且能够使用适合的技术来完成他们面临的任务。
XML 规范开发用来使通常锁定于专有格式的常规数据可以以一种人易读的、自描述的、自验证的开放格式来描述。当 Web 服务使用文档消息传递时，它可以利用 XML 的全部能力来描述和验证高级业务文档。当服务使用 RPC 消息格式化时， XML 描述方法以及为方法调用编码的参数，但是却不能用来执行高级业务规则。为了执行这些规则， RPC 消息必须包含 XML 文档作为字符串参数并且在被调用的方法中隐藏验证。出于这个原因， XML 的某些好处就丧失了，或者至少是被隐藏在后台应用程序里了。
使用文档消息传递的另外一个原因在于，远程过程调用必须是相对静态的，并且对接口的任何变化都将破坏服务和应用程序之间的契约。如果服务是广泛分布的，那么很可能大量的应用程序已经从它的 WSDL 文档中产生了存根代码。改变 WSDL 将会导致所有依赖于特定方法签名的应用程序被破坏，而且许多支持行产生问题。好的设计要求 RPC 消息服务的方法签名不应该改变。使用文档消息传递，规则更严格，并且可以使 XML 模式得到显著增强和改变，同时又不会破坏调用应用程序。
当业务使用基于 Web 的应用程序通过 Internet 交换信息时，应用程序应该能够使用有保证的交付机制来提高它的可靠性、可伸缩性和性能。为了达到这个目的，应用程序通常将使用异步消息队列。由于文档消息通常是自包含的，所以它更适合于异步处理，并且可以直接放到队列中。之所以说应用程序的可靠性得到了提高，是因为即使目标应用程序当前不是活动的，消息队列也可以保证消息的交付；之所以说性能得到了提高，是因为 Web 应用程序只是把文档发送到队列中，然后便可以自由地执行其他的任务；之所以说可扩展性得到了提高，是因为文档被下传到一个或多个应用程序的实例以进行处理。
业务文档的设计通常很好地适于面向对象的体系结构。结果，两个应用程序可以设计成通过使用 XML 交换对象的状态。与对象序列化相比，在对象交换中，交换的每个端点都可以自由地设计它认为合适的对象，只要交换符合达成协议的 XML 文件格式即可。不使用对象序列化的一个原因是为了支持对象在客户端和服务器端的实现。许多现有的特定于行业的 XML 模式被设计成客户端 / 服务器体系结构，在这种体系结构中，在客户端上完成的处理与预定在服务器上完成的处理是分离的。通常的情况是，客户端仅仅以服务器要求的特定文档格式请求或保存信息。当然，这种类型的交换也能用 RPC 消息完成，但是这种消息的编码方式限制了每个端点上的对象的设计。在文档样式中就不会出现这些限制问题。
什么时候应该使用文档样式呢？简单地说：只要没有连接到已存在的远程过程调用，任何时候都可以使用文档方式。使用文档方式比起通常花费额外的工作来连接服务，好处要大得多。不过需要提醒的是：一般来说，构建一个使用文档消息传递的服务的工作量要比构建一个 RPC 消息服务所需的工作量大。这些额外的工作通常包括 XML 模式的设计或对已存在的模式的支持、以及从文档中提取相关的信息。模式设计是重要的，因为 XML 解析器使用这个模式来验证文档，支持预定的业务规则。服务需要进行额外的工作来从文档中提取用于处理请求的相关信息。相比之下， RPC 消息只需要设计方法的接口，通过方法的接口， RPC 消息就可以自动地编组和解组参数。
当您决定发布一项服务时，您可能应该考虑下列问题。我将在下面的部分中分析您的答案的结果。
- 这项服务是连接到已存在的过程调用，并且这个过程调用是无状态的吗？
- 这项服务是仅在您的组织内部使用，还是也可以被外部用户所使用？
- 参数之一仅仅是 XML 文档规范吗？
- 这项服务需要请求 / 响应体系结构吗？
- 参数表示了可以从用于验证的 XML 文档模式受益的复杂结构吗？
- 所有需要进行交换的信息都能够合理地存放在内存中吗？
如果必须以特定的顺序调用多个过程来维护应用程序状态，您应该考虑在您的服务中使用文档体系结构。如果需要多个过程调用，那么过程就不是无状态的，并且服务必须维护应用程序状态。在 Web 服务中维护状态可能是困难的；在远程过程调用的情况下，很少有客户端平台会产生能够支持状态信息的存根代码。一个可能的解决方案是使用文档体系结构，并在文档内部传送整个事务的内容。在这种情况下，服务将执行调用，以确保服务内部保持正确的顺序，并且状态信息的维护不超出单个事务的范围。如果仍然需要状态信息，可以将状态信息记录在最终得到的文档中，客户端应用程序也可以维护一个用于服务识别它的状态的令牌。
如果一个应用程序被发布到组织以外，发布者就很难控制谁正依赖于这个服务，以及如果做出任何改动后果会怎样。在这种情况下，使用文档消息传递和支持像 ebXML 这样的通用交换协议可能更加有利。通用交换协议正发展成能改善外部交换的管理，因此新的贸易合作伙伴协定就可以快速地部署。同样，如果您的服务不需要请求 / 响应体系结构，那么通用交换协议就可以更好地设计来处理认证、可靠消息交付以及异步请求 / 响应。
如果您的服务正使用字符串参数来传递或返回 XML 文档，或者它的参数之一是一个具有复杂结构且需要自定义处理的对象，那么文档消息传递就可能是较好的选择。将参数的真实含义隐藏在字符串里经常会导致带有无效参数的有效调用。如果服务发布了 XML 文档模式，那么在调用服务之前根据这个模式进行验证就会更加容易。复杂结构经常用来传递组成完整事务的数百条信息。在处理复杂的结构时，远程过程服务可能不得不处理自定义的编组代码，同时应用程序仍然负责仔细地验证结构的每个元素。如果使用文档消息传递，那么应用程序程序员就可以使用 XML 模式来将验证下传到文档设计器，并且不需要自定义的编组代码。
择使用文档样式的消息传递还是 RPC 样式的消息传递时，需要考虑的最后一个因素是需要处理的信息量大小。由于采用 RPC 样式的消息传递来编组参数的大部分（如果不是全部的话）实现都是在内存中执行这项操作，所以内存约束可能会使得 RPC 消息传递行不通。许多文档消息传递服务能够选择是用 DOM 还是用 SAX 来处理文档，因而能够最小化内存中的处理。这对于 Web 服务尤为关键，因为它可能需要处理成千上万的请求，而且其中许多是同时发生的。
在您设计下一个 Web 服务时，您需要考虑当前的 WSDL 规范为您提供的所有选择。在开始创建过程性的接口之前，考虑好将如何使用服务，谁将使用它，以及需要交换的数据的类型和数量。设计开发文档样式的 Web 服务可能需要稍多一些的工作量，但是在很多情况下，这些额外的工作量将会换取更高的信息质量和更可靠的交换性能。