RPC与Document绑定样式的权衡选择

 

本文摘自博文视点11月上市新书《Java Web服务：构建与运行》。

 

JWS既支持RPC绑定样式也支持Document绑定样式，同时Document绑定样式为默认值；在这两种绑定样式中，依照Web 服务基本概要（WS-I Basic Profile）的基本要求，这两种绑定样式只可以采用literal编码方式。在服务绑定样式上究竟选择RPC还是Document一直都是争论的话题。不管怎样，Document绑定样式，尤其是封装情况下，正在很快地被人们所认可。因此接下来简要地探讨这两种绑定样式选择上的权衡。

不管以怎样的权衡方式，都应该以严格的眼光来真正地理解事情的两面性，尤其是要从特定的角度来证明这种两面性。RPC样式比较常见的不足就是它只能够适用服务的请求/响应模式。尽管请求/响应模式在基于SOAP的Web服务中占主导地位，很多实际应用场景（比如在购买商品时验证新卡的有效性）都需要。

下面是RPC样式的一些优点：

•   由于有类型定义，自动生成的 WSDL 文档非常精简。
• WSDL 文档中的消息可以直接反映出对应的基础 Web 服务操作的名称，也就是在基于 Java 语言的 Web 服务中 @WebMethods 所注解的方法。因此从 WSDL 文档中人们可以直接获取服务操作的名称。
• 由于不需要承载更多类型及编码信息，消息的传输往往是高效的。

下面是RPC样式的一些缺点：

• 由于 WSDL 中没有类型定义部分，因此不能够提供 XSD 文档来校验 SOAP 消息体。
• 同样由于没有 XSD 来定义数据类型，服务能够使用的数据类型有限。因此服务只是局限于一些相对简单的类型，比如整数、字符串、日期、数组等。
•   RPC 样式对请求 / 响应消息的模式捆绑，使得服务与客户端之间耦合性增加。比如 Java 客户端 ch01.ts.TimeClient 中下面这句代码，在服务应答或抛出一个异常之前，调用会一直阻塞：

port.getTimeAsString()

相对异步调用方式而言，RPC样式下服务调用通常是同步的。下一节将提供一个例子来演示在请求/响应模式下，JWS是如何支持非阻塞客户端的。

• 以此样式实现的 Java 服务可能在其他语言平台下无法使用，这样也就违背了 Web 服务的互用性原则。同样也就不会有来自 Web 服务社区和 WS-I 小组的长期支持了。

下面是Document样式的一些优点：

• 可以利用 WSDL 文档类型部分的 XSD 文档直接来验证 SOAP 消息体。
• XML 模式语言除了支持整数、字符串及日期等这些简单数据类型之外，还支持任意复杂的类型，因此这种样式的 Web 服务所使用的数据类型不受限制。
•   只要在 XSD 中定义了明确的数据结构，如何构建 SOAP 消息体具有很大的灵活性。
• 包装行为吸取了 RPC 样式的一个重要优点，即 RPC 样式中 SOAP 消息体可以直接通过与之关联的服务操作名称来命名，同时又摒弃了 RPC 样式的不足之处。

下面是Document样式的不足之处：

• 在非包装版本中， SOAP 消息中没有提供服务操作的名称，一些特定的程序代码在分发消息时可能会变得复杂。
• 包装版本使得服务调用的复杂度有所增加，尤其是在 API 级别。就像前面的 AmazonClientW 例子一样，针对程序开发人员来说，基于包装的 Document 绑定样式的服务编写客户端代码也许就变成了一项极具挑战性的工作。
• 在 SOAP 消息体的 XML 包装元素中必须拥有一个服务操作的名称，因此包装版本不支持重载的服务操作。实际上，针对一个既定的元素名称也只能够有一个服务操作。

 

扩展阅读：Web服务技术，且看《Java Web服务》为您一一道来

互动网新书预售：http://www.china-pub.com/196168&ref=ps