包装的和非包装的Document绑定样式

为什么80%的码农都做不了架构师？>>>   

在WS-I基本概要中针对web服务的互用性默认采用Document绑定样式。通过WSDL文档中数据类型部分定义的XSD文档，Document绑定样式在web服务的SOAP消息中提供了清晰而又明确的数据类型。Document绑定样式由此进一步促进了web服务的这种互操作性，因为客户端可以很明确地了解服务中涉及的数据类型，以及包括在原始SOAP消息体中的文档应该如何组织。尽管如此，RPC绑定样式还是比较有吸引力的，因为在此种绑定样式下web服务的操作名称直接和服务底层操作实现名称相关联。例如，在java中用到的@WebMethod注解的名称为getTimeAsString，而在所生成的WSDL中，请求消息的名称也为getTimeAsString，同时响应消息的名称为getTimeAsStringResponse。可见，RPC绑定风格是比较利于程序进行客户端开发的。

虽然不是很正式，却被采用的包装行为可以给Document绑定样式提供RPC绑定样式的直观效果。包装行为力求兼备Document和RPC绑定样式的共同点。

非包装的Document绑定样式的示例：

<?xml version="1.0" ?>
<soapenv:Envelope xmlns:soapenv="http:schemas.xmlsoap.org/soap/envelope/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <soapenv:Body>
        <num1 xmlns:ans="http://ts.ch01/">27</num1>
        <num2 xmlns:ans="http://ts.ch01/">94</num2>
    </soapenv:Body>
</soapenv:Envelope>

包装的Document绑定样式的示例：

<?xml version="1.0" ?>
<soapenv:Envelope xmlns:soapenv="http:schemas.xmlsoap.org/soap/envelope/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
     <soapenv:Body>   
         <addNums xmlns:ans="http://ts.ch01/">
             <num1>27</num1>
             <num2>94</num2>
         </addNums>          
     </soapenv:Body>
</soapenv:Envelope>

非包装的SOAP请求消息体有两个名称，分别是num1和num2的元素。这两个元素包括相加的两个数值，而且SOAP体也没有包括完成加法任务的操作名称。而针对包装的SOAP请求消息体中有一个单独的名称为addNums的元素，这个名称就是请求的服务操作的名称，同时在这个单独的元素中包括两个子元素，每一个子元素中包括一个要相加的数值。带有包装的SOAP消息，其服务请求的操作非常清晰。操作的参数作为操作元素addNums的子元素非常直观地嵌入其中。

针对包装的Document绑定样式行为，其引导性非常直接明了。下面是这种包装行为的总结：

• SOAP消息体中应该只有一个单独的XML元素，在这个单独的XML元素中可以拥有多个XML子元素。比如，即使一个服务操作有输入参数和返回值，那么这些参数和返回值不应该在SOAP消息体中以一个单独的XML元素出现，而是应该作为主元素的子元素出现。前面的示例说明了这一点，其中addNums元素作为SOAP消息中一个单独的XML元素出现，而xml元素num1和num2作为addNums元素的子元素出现。

• WSDL文档的XSD和SOAP消息体中的主元素之间的关系是明确定义的。采用Document绑定样式的TimeServer服务可以说明这一点。在XSD中，有4个complexType元素，每一个complexType元素均定义了一种数据类型。比如名称分别为getTimeAsString和getTimeAsStringResponse的complexType元素。这些定义大致出现在XSD文档的下半部分。在XML元素定义的上半部分是XML元素定义，每一个XML元素都有一个name和一个type属性。complexType的名称和顶部定义的这些xml元素名称对应。比如名称为getTimeAsString的complexType同顶部定义的一个名称也是getTimeAsString的元素匹配。下面的XSD文档片段显示了这种对应关系：

<xs:element name="getTimeAsString" type="tns:getTimeAsString"></xs:element>
<xs:element name="getTimeAsStringResponse" type="tns:getTimeAsStringResponse">
....
<xs:complexType name="getTimeAsString"></xs:complexType>
<xs:complexType name="getTimeAsStringResponse">
    <xs:sequence>
        <xs:element name="return" type="xs:string" minOccurs="0">
        </xs:element>
    </xs:sequence>
</xs:complexType>

    另外，每一个complexType要么为空，要么包括一个xs:sequence子元素。子元素xs:sequence中包括了类型化的参数和返回值。TimeServer服务比较简单，请求的消息中不包括任何参数，返回值也只不过是一个单独的值。尽管如此，上面这个XSD文档代表了大多数情况下XSD文档的普遍结构。比如，如果getTimeAsStringResponse拥有多个返回值，那么每一个返回值均作为xs:sequence元素的子元素出现。最后，注意，XSD文档片段中的每一个XML元素都是被命名和类型化的。

•  XSD中的XML元素担任对SOAP消息体的包装。比如针对ch01.ts.TimeServer，一个简单的包装文档如下：

<?xml version="1.0" ?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
       xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <soapenv:Body>
        <ans:getTimeAsElapsedResponse xmlns:ans="http://ts.ch01/">
            <return>1205030105192</return>
        </ans:getTimeAsElapsedResponse>
    </soapenv:Body>
</soapenv:Envelope>

这个消息体同RPC绑定样式的服务所生成的SOAP消息体相同，同RPC绑定样式所不同的是，包装的Document绑定样式的服务在WSDL文档类型部分引用的XSD中包括清晰的类型和格式化消息。

• 请求封装器同服务操作拥有相同的名称（比如示例中的addNums）。响应封装器的名称就是请求封装器的名称加上“Response”一词（比如addNumsResponse）。

• WSDL文档的portType部分拥有被命名的服务操作（比如getTimeAsString操作），服务操作的消息被类型化。比如，输入消息getTimeAsString的类型是tns:getTimeAsString。下面是基于Document绑定样式服务所对应的WSDL文档中portType一节的内容：

<portType name="TimeServer">
    <operation name="getTimeAsString">
        <input message="tns:getTimeAsString"></input>
        <output message="tns:getTimeAsStringResponse"></output>
    </operation>
    <operation name="getTimeAsElapsed">
        <input message="tns:getTimeAsElapsed"></input>
        <output message="tns:getTimeAsElapsedResponse"></output>
    </operation>
</portType>

基于包装的Document绑定样式行为，不管是不是正式的，已经变得越来越来盛行。JWS支持这种做法。默认情况下，在java语言中，基于SOAP的web服务被包装成doc/lit（document/literal）模式，也就是绑定样式采用封装的Document样式，编码方式采用literal编码方式。

转载于:https://my.oschina.net/fhd/blog/217799