基于SOAP协议的Web服务风格之比较
前面我们已经看到，SOAP可以在后台替我们完成那些比较困难的工作。但我们并没有看到服务器端和客户端交互的XML文档，实际上，我们可以利用一些TCP/IP监测工具，比如Apache的TCPMon工具来查看SOAP中传输的XML文档，其结果如代码清单16所示：
代码清单16 – SOAP中的XML请求文档
<?xml version="1.0" ?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ns1="http://item.service.soap.soajava.packt.com/">
<soapenv:Body>
<ns1:insert>
<arg0>
<code>XY</code>
<description>xy desc</description>
<id>26</id>
</arg0>
</ns1:insert>
</soapenv:Body>
</soapenv:Envelope>
代码清单17 – SOAP中的XML应答文档
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:insertResponse
xmlns:ns2="http://item.service.soap.soajava.packt.com/">
<return>
<retCode>OK</retCode>
<retMessage>Item was inserted successfully</retMessage>
</return>
</ns2:insertResponse>
</S:Body>
</S:Envelope>
您可以看出，SOAP的XML消息以Envelope元素开始，包含一个必须的Body元素，但SOAP消息中的header元素是可选的。Body元素中包含的内容就是要传输消息的有效负载。然而，我们在使用SOAP时会有多种选择，就前面的例子而言，我们为了简明起见，只采用了SOAP的缺省设置。您有可能听说过SOAP的绑定风格(Binding style，其值为RPC或Document风格)、使用(use，其值为Encoded或Literal)或参数风格(parameter style，其值为Bare或Wrapped)。在本节中，我们将探讨一下这些概念，重点介绍一下SOAP的绑定风格。
在解释这些概念之前，我们先花点时间解释一下WS-I这个概念，它是Web Service-Interoperability(Web服务的可互操作性)的缩写，它代表了一整套的标准，这些标准组合起来可以让我们在异种环境中(比如.Net和Java)进行数据交换。绑定风格、使用和参数风格可以任意组合，但只有以下的组合和WS-I兼容，所以它们是我们讨论的重点：
(1) RPC/Literal
(2) Document/Literal(bare或unwrapped)
(3) Document/Literal wrapped
WS-I规定，use属性值不能等于”encoded(已编码的)”。如果use属性值等于encoded，数据将按照SOAP编码规范进行编码，但要验证经过SOAP编码的消息是否违反WSDL描述将非常困难，而验证工作又是可互操作性的基础，所以WS-I不对数据进行编码，它只传输literal(不经编码的)的数据。
SOAP服务的可选架构一 : RPC/Literal
SOAP服务的第一个可选架构为RPC/Literal，它决定我们是否要在Web服务中使用RPC还是要使用Document作为SOAP的绑定风格。RPC(远程过程调用)是远程调用的一种通用机制，驻留在一台计算机(或虚拟机)上的程序可被运行在远程机器(或虚拟机)上的程序调用，这种方法已经使用了几十年。RPC可由多种技术实现，其中比较流行的有CORBA、DCOM和RMI。实现技术虽然不同，但RPC调用都具有以下特点：
(1) 需要有远程地址
(2) 需要调用的方法(或操作)名
(3) 需要一系列参数
(4) 需要同步应答
请注意，除了上面的第一个特点，RPC调用与本机调用几乎相同。那么，古老的RPC方法和SOAP服务又有什么关系呢？其实它们之间关系非同一般，SOAP在其早期定义(尚未发布之前)中，其设计只支持RPC。从某种意义上说，当时的SOAP是当时各种分布式编程技术的集大成者，它对这些技术进行了标准化。
我们可以对前面的Web服务稍加修改，加些注解(annotation)，我们就可以将它转化为RPC风格(JAX-WS的缺省风格为Document而非RPC)，其实现代码如下：
代码清单18 – SOAP的RPC风格
@WebService
@SOAPBinding(style=SOAPBinding.Style.RPC)
public class ItemWs {
@WebMethod
public Outcome insert(@WebParam(name="itemParam") Item item,
@WebParam(name="categoryParam") String category)
{
//Insert item ...
您会看到，我们在方法中加了另一个参数category，这样我们就可以把某个商品插入到某一指定的商品集中，并且我们使用了@WebParam注解给方法中的参数命名。
现在我们来发布这个服务，我们只需要运行带有EndPoint.publish的那个主类即可，而不需要运行wsgen来生成服务器端的类。然后，请使用wsimport工具根据发布的WSDL生成客户端类，并导入到客户端项目中，这样，我们就可以通过下面的方式在客户端调用该RPC风格的SOAP服务。
Outcome outcome = itemWs.insert(item1, "A");
如果我们监测XML请求文档，我们将会看到如下结构：
代码清单19 –RPC风格的SOAP请求文档
<soapenv:Body>
<ans:insert xmlns:ans="http:// ... ">
<itemParam>
<code>XY</code>
<description>xy desc</description>
<id>26</id>
</itemParam>
<categoryParam>A</categoryParam>
</ans:insert>
</soapenv:Body>
我们可以从上面的请求文档中看到RPC的典型风格，即方法名加上一系列参数。其相应的WSDL(您可以使用TCP监测工具查看)文档如下所示：
代码清单20 –RPC风格的WSDL文档
<types>
<xsd:schema>
<xsd:import schemaLocation="http://127.0.0.1:8002/SoaBookSOAP_RPC_server/itemWs?xsd=1"
namespace="http://item.service.soap.soajava.packt.com/"></xsd:import>
</xsd:schema>
</types>
<message name="insert">
<part name="itemParam" type="tns:item"></part>
<part name="categoryParam" type="xsd:string"></part>
</message>
<message name="insertResponse">
<part name="return" type="tns:outcome"></part>
</message>
<portType name="ItemWs">
<operation name="insert" parameterOrder="itemParam categoryParam">
<input message="tns:insert"></input>
<output message="tns:insertResponse"></output>
</operation>
</portType>
<binding name="ItemWsPortBinding" type="tns:ItemWs">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http">
</soap:binding>
<operation name="insert">
<soap:operation soapAction=""></soap:operation>
<input>
<soap:body use="literal" namespace=
"http://item.service.soap.soajava.packt.com/">
</soap:body>
</input>
<output>
<soap:body use="literal" namespace=
"http://item.service.soap.soajava.packt.com/">
</soap:body>
</output>
</operation>
</binding>
<service name="ItemWsService">
<port name="ItemWsPort" binding="tns:ItemWsPortBinding">
<soap:address location=
"http://127.0.0.1:8002/SoaBookSOAP_RPC_server/itemWs">
</soap:address>
</port>
</service>
</definitions>
上面WSDL的XML Schema文档可以通过下面的URL地址来访问：
http://127.0.0.1:8001/SoaBookSOAP_RPC_server/itemWs?xsd=1
WSDL的XML Schema文档内容如下所示：
代码清单21 –RPC风格WSDL文档的XML Schema(XSD)文档
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:tns="http://item.service.soap.soajava.packt.com/" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://item.service.soap.soajava.packt.com/" version="1.0">
<xs:element name="Item" type="tns:item"></xs:element>
<xs:element name="Outcome" type="tns:outcome"></xs:element>
<xs:complexType name="item">
<xs:sequence>
<xs:element name="code" type="xs:string"
minOccurs="0"></xs:element>
<xs:element name="description" type="xs:string"
minOccurs="0"></xs:element>
<xs:element name="id" type="xs:int"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="outcome">
<xs:sequence>
<xs:element name="retCode" type="xs:string"
minOccurs="0"></xs:element>
<xs:element name="retMessage" type="xs:string"
minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
这里，我们需要注意的是，上面的XSD只定义了复杂类型元素，如本例中的Item和Outcome类型，但它没有办法提供有效的信息来验证简单数据类型的参数，也不能验证SOAP消息的其它部分。因此，采用RPC架构的主要问题是，如何才能验证要交换消息的XML文档符合XSD规范？
接下来我们看看Document风格的架构能否客服这一缺点。
SOAP服务的可选架构二 : Document/Literal
这种SOAP风格的实现也称之为”bare”或”unwrapped”(未组装的)的Document风格，为什么叫未组装的Document，我们马上会解释其中的含义。但现在请您注意，JAX-WS中的参数类型的缺省值是wrapped(已组装的)，因此，为了使用bare类型的document风格，我们需要在源代码中显式声明：
代码清单22 –Document风格SOAP服务实现
@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
parameterStyle=SOAPBinding.ParameterStyle.BARE)
public class ItemWs {
@WebMethod
public Outcome insert(@WebParam(name="itemParam") Item item,
@WebParam(name="categoryParam") String category) {
...
如果您现在按正常的步骤在客户端调用上面的服务，您会在导入由WSDL产生的客户端类时发现下面的错误：
error: operation "insert": more than one part bound to body
这个错误有助于我们理解RPC和Document风格的SOAP实现方法之间的区别，我们已经了解，WS-I只允许SOAP消息体中只能包含一个XML根元素，这是为什么呢？
Document风格是SOAP实现的一种新方法，它不同于以往的方法。其表现在，服务要求的输入是”一个文档”，而不是一个带方法名及其相应参数的一个请求。这意味着在Document风格中，我们应该传入一个对象，这个对象将是Web服务的唯一输入。Document中会包含服务调用的所有有用信息，但不是方法名及其相应参数值的组合。这就是WS-I为什么只允许Document只能包含一个根元素的原因。
因此，为了调用上面的Document风格的服务，把商品插入到商品目录中，并保持和WS-I兼容，我们应重构服务的源代码。我们应该新建一个对新，比如ItemInsertRequest对象，这个对象将包装所有需要的信息(商品及其目录)。这就是为什么这种风格又称之为”bare”或”unwrapped”的Document风格的由来，它没有对XML消息的组成部分进行包装，我们必须手动的显式包装它们。
代码清单23 –Document风格的SOAP服务对请求进行组装
@XmlRootElement(name = "ItemInsertRequest")
public class ItemInsertRequest {
private Item item;
private String category;
...
而且，为了使Web服务只需要一个参数，我们还需要对Web服务的实现进行重构，其实现代码如下：
代码清单24 –Document风格的SOAP服务实现代码(使用了上面定义的封装类)
@WebMethod
public Outcome insert(@WebParam(name="itemInsertRequestParam")
ItemInsertRequest itemInsertRequest) {
...
此时，但客户端使用wsimport工具生成客户端需要的类时，就不会产生上面的错误，客户端最终调用服务的代码如下：
代码清单25 –Document风格的客户端调用代码
ItemInsertRequest req = new ItemInsertRequest();
req.setItem(item1);
req.setCategory("A");
Outcome outcome = itemWs.insert(req);
上面的代码执行后，它会想服务器发出SOAP请求，其请求消息体的内容如下：
代码清单26 –Document风格XML请求
<ns1:itemInsertRequestParam>
<category>A</category>
<item>
<code>XY</code>
<description>xy desc</description>
<id>26</id>
</item>
</ns1:itemInsertRequestParam>
请注意，上面Document风格的XML请求在结构上虽然和RPC风格相似(请参展代码清单19)，但我们现在处理的是XML文档(Document)，而不是对远程方法的调用。在Document文档中，商品及其目录只是文档的属性；但在RPC风格的方法调用中，它们是作为方法的参数传入的。
代码清单27–Document风格WSDL
<message name="insert">
<part element="tns:itemInsertRequestParam"
name="itemInsertRequestParam"></part>
</message>
...
<binding name="ItemWsPortBinding" type="tns:ItemWs">
<soap:binding style="document"
这时，上面WSDL附属的XSD就可以用来对整个WSDL文档进行验证。
代码清单28–Document风格WSDL附属的XSD文档
<xs:element name="Item" type="tns:item"></xs:element>
<xs:element name="ItemInsertRequest"
type="tns:itemInsertRequest"></xs:element>
<xs:element name="Outcome" type="tns:outcome"></xs:element>
<xs:element nillable="true" name="insertResponse"
type="tns:outcome"></xs:element>
<xs:element nillable="true" name="itemInsertRequestParam"
type="tns:itemInsertRequest"></xs:element>
<xs:complexType name="itemInsertRequest">
<xs:sequence>
<xs:element name="category" type="xs:string"
minOccurs="0"></xs:element>
<xs:element name="item" type="tns:item"
minOccurs="0"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="item">
<xs:sequence>
<xs:element name="code" type="xs:string"
minOccurs="0"></xs:element>
<xs:element name="description" type="xs:string"
minOccurs="0"></xs:element>
<xs:element name="id" type="xs:int"></xs:element>
</xs:sequence>
</xs:complexType>
Document/Literal风格的SOAP服务的主要优势在于，它能对整个XML交换消息进行验证。
但是，使用这种方法，我们会丢掉一些信息，如我们在SOAP消息中没有发现操作的名称；在某些情况下，比如在使用SMTP等异步TCP/IP协议来传输消息时，这可能会有所不足。因为此时消息的派发将变得非常困难，有时甚至不可能做到。
另外，这种方法的另一个缺点是，对那些已经开发完成的应用，我们得考虑花力气对它们进行改造，即对服务器端和客户端的代码进行重构。
SOAP服务的可选架构三 : Document/Literal Wrapped
Document/Literal Wrapped风格是JAX-WS的缺省风格，在我们第一个SOAP示例中，我们用的就是这种风格(请参考程序清单14)。因此，下面的注解其实是没用的。
代码清单29–Document Wrapped风格的服务实现
@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)
现在，我们在Document bare风格代码的基础上，初始化Web服务的结构。
代码清单30–Document Wrapped风格的服务实现
@WebMethod
public Outcome insert(@WebParam(name="itemParam") Item item,
@WebParam(name="categoryParam") String category) {
要在客户端调用该Web服务，按照正常的步骤进行即可(此时需要调用wsgen工具生成服务器端需要的类)。
现在，即使Web方法中带有类似于RPC风格的多个参数，在服务的调用过程中也不会产生错误。这是如何做到的呢？原来，它只是对方法名和参数进行简单的封装，将方法名和参数当成一个新的对象，新对象名和Web方法名正好一致。当然，这个封装过程是自动完成的。此时，SOAP消息体的内容如下：
代码清单31–Document Wrapped风格的XML请求
<ns1:insert>
<itemParam>
<code>XY</code>
<description>xy desc</description>
<id>26</id>
</itemParam>
<categoryParam>A</categoryParam>
</ns1:insert>
总之，Document/literal wrapped风格集成Document和RPC方法的优势，它具有以下优点：
(1) SOAP消息可以用XML Schema进行验证
(2) SOAP消息体只有一个子元素，因此它和WS-I兼容
(3) 如果Web方法带有多个参数，不需要修改代码就可发布这种类型的服务
(4) 操作的方法名包含在SOAP消息中
2850
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
