终于明白了Document Exchange vs. RPC models

Document Exchange vs. RPC models
    使用 RPC-encoded 还是 document-style 进行交互是在创建体系结构的过程中首先要决定的事情之一。这个选择会影响到体系结构中的耦合级别。
    RPC (remote procedure call)实际上是对一个远程方法的调用，尽管Web services是基于XML的，但你仍然可以采用类似RPC的方式来与后台服务进行交互。这种交互通常是一个简单的请求/响应过程。客户端发送一个包含方法调用的SOAP消息，应用服务器接收这个请求，转换后传递给后台对象(比如，Java object, EJB method, 或者 C# method)。创建基于RPC的Web services 几乎不需要开发人员做任何工作，因为所需的工作仅仅是创建映射关系而已。注意，即使采用这种方式，XML文件也仅仅是作为调用请求的载体。
    采用document-style，"business documents"以XML格式通过网线传输。，"business documents"不是被直接映射为后台方法调用，因为它们实际上是完整的、自包含的业务文档。Web services接收到XML文档之后，可能先对它进行预处理，执行一些任务，然后创建响应返回。在XML文档和后台对象之间通常没有直接的映射关系，实际上，一个请求很可能会激活几个后台组件完成服务任务。开发人员必须自己完成很多工作来实现XML数据的处理和映射，而且市场上基本没有能够自动完成这种工作的工具。document-style经常会与异步通讯协议一起来搭建一个稳定的、松散耦合的体系架构。
    你可以把RPC vs. document style类比为打电话和发送电子邮件。一个是同步的请求响应模式，一个是异步的事件队列处理模式。
    一般的情况下你都应该在系统架构中采用document style消息。尽管RPC模式可以让你迅速实现Web services，但当你要与超出你控制范围之外的客户、供应商和合作伙伴进行协作的时候，这种模式往往不能提供足够的支持。你需要一个体系结构来把你（还有你的客户端应用）保护起来，使你不受远端服务的 具体实现的影响。
    Document style消息具有如下优点：

• 你可以充分利用XML的能力来描述和验证业务数据，而采用RPC方式的时候，XML描述的仅仅是调用的方法及其参数。 
• 客户端和服务提供者之间无需采用紧密耦合的服务协议，RPC通常是静态的，当所调用的方法的signature改变的时候，客户端也需要跟着改变。而document style就不会有这么严格的要求。 
• 因为是自包含的，document style 更适合于异步处理。 

    document style 最大的缺陷就是实现起来比较困难，尽管如此，它所带来的灵活性使得实现所付出的代价显得物有所值，而且越来越多的平台提供商开始为这种方式提供支持。诸如WS-I这样的组织也在倡导采用该方式。