本文摘自博文视点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