[zt]SOAP风格中 RPC与Document的区别

大部分 Web 服务都是围绕着远程过程调用而构建的,而 WSDL 规范允许另外一种 Web 服务体系结构:文档样式(document style)。在该体系结构中,整个文档在服务客户端和服务器之间进行交换。
在 WSDL规范中隐含着一个非常巧妙的转换开关,它可以将 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 消息完成,但是这种消息的编码方式限制了每个端点上的对象的设计。在文档样式中就不会出现这些限制问题。
什么时候应该使用文档样式呢?简单地说:只要没有连接到已存在的远程过程调用,任何时候都可以使用文档方式。使用文档方式比起通常花费额外的工作来连接服

Comments are closed.