摘要：Web服务的有效负载包装在SOAP消息中，而SOAP消息体通过绑定服务调用方式封装操作，绑定编码方式序列化参数。然而，调用方式和编码方式的不同组合就产生了多种SOAP绑定样式，而不同样式的SOAP消息构造各不相同，也有各自的优缺点。这就给服务的开发和调用带来了困难：如何选择服务绑定样式；如何根据绑定样式构造SOAP消息。
关键字：消息绑定、消息构造、互操作性、RPC、Document
1 引言
Web服务技术解决了异构平台/系统之间应用的整合问题，为企业间应用集成提供了技术基础。Web服务互联互通是Web服务应用和集成的基础，保证Web服务之间互联互通的一致性是促进Web服务技术应用和发展的关键技术问题之一。由于Web服务采用WSDL (Web Services Description Language)语言定义消息格式和内容、采用SOAP(Simple Obiect Access Protocol)协议进行消息通信。因此，Web服务之间互连互通的一致性就是WSDL/SOAP接口之间的一致性。
Web服务的有效负载通常包装在SOAP消息中，而SOAP消息结构由WSDL文档中的SOAP绑定定义确定。不同的调用方式和编码方式通过组合可以产生多种绑定样式，而每种样式的应用场景和对应的SOAP消息结构并不相同。如果没有正确的构造SOAP消息，则无法正确交换服务的有效负载，即使有效负载遵循提供者和使用者的公共XML模式也是如此。这就给服务的开发和调用带来了挑战：如何根据应用场景选择合适的服务绑定样式？如何根据绑定样式构造正确的SOAP消息？因此，理解SOAP消息的绑定机制和各种服务绑定样式的消息构造，以及它们各自的优缺点就显得非常重要。尤其是对于Web服务基础平台和工具（如Web服务运行平台、Web服务开发工具、Web服务测试工具等）的开发者而言就更加重要。
本文将详细介绍SOAP消息的绑定机制和根据绑定样式构造SOAP消息，以及解决互操作性问题的相关规范。本文的主要目的是为了帮助开发者更加全面透彻地理解SOAP消息的绑定和构造。
2 消息绑定
SOAP Body提供了一种消息交换的机制，是SOAP消息的实际负载，可包含任意内容。SOAP消息体(SOAP Body)通过绑定服务调用方式(RPC或者Document)封装操作，绑定编码方式(Encoded或者Literal)序列化参数。SOAP消息的绑定样式由style、use和encodingStyle这三个属性共同设置。style属性指定服务的调用方式，是采用RPC方式还是Document方式；use属性指定消息的编码方式，是采用Encoded方式还是采用Literal方式；而encodingStyle属性指定具体编码规则，例如可以指定SOAP编码规则、XML Schema编码规则等等，通常情况下都是采用XML Schema。
2.1 style属性
style属性描述了服务的调用方式，取值为”rpc”或者”document”，默认值为”document”。适用于SOAP Body元素的子元素（也可能是孙级元素）。此选项指定为WSDL文档中的soap:binding元素（通常情况下）或者soap:operation 的 style 属性。
l RPC
RPC: (Remote Procedure Call) 采用客户端/服务器方式(请求/响应)，发送请求到服务器端，服务端执行方法后返回结果。优点是跨语言跨平台，缺点是编译时无法排错，只能在运行时检查。
SOAP消息本质上是一种从发送方到接收方的单向传输，但是SOAP经常组合到实现请求/响应机制中。要让RPC使用SOAP，必须遵循几条规则。首先，请求和响应消息必须被编码成结构类型。其次，对一个操作的每一个输入参数，都必须有一个同名元素（或输入结构的成员）作为参数。最后，对每一个输出参数，都必须有一个名称匹配的元素（或输出结构的成员）。
style=”rpc”指明遵从SOAP标准，在SOAP Body中封装RPC调用的请求和返回操作。对该类消息的约束是必须把操作的名称作为封装了对操作的请求和响应消息负载的根元素名称。对于SOAP请求消息，请求操作的名称是根据WSDL文档中的wsdl:operation元素命名，后者对应Web服务方法。对于SOAP响应消息，响应操作的名称是请求操作的名称后面追加"Response"构成。操作元素中的每个子元素表示一个参数，根据WSDL文档中的wsdl:part元素命名。RPC请求/响应消息的格式(省略了名称空间限定)如下：
| RPC请求消息格式 | RPC响应消息格式 |
| <SOAP信封> <SOAP头部> …… </SOAP头部> <SOAP消息体> <请求操作名称> <参数名1>值</参数名1> <参数名2>值</参数名2> ...... </请求操作名称> </SOAP消息体> </SOAP信封> | <SOAP信封> <SOAP头部> …… </SOAP头部> <SOAP消息体> <响应操作名称> <参数名1>值</参数名1> <参数名2>值</参数名2> ...... </响应操作名称> </SOAP消息体> </SOAP信封> |
l Document
与RPC相比较Document方式在XML文件中不是做远程方法的映射，而是一份完整的自包含的业务文档。当服务器端收到这份文档后，先进行预处理（比如词汇的翻译和映射），然后再构造出返回消息。这个构造返回消息的过程中，往往不再是简简单单的一个方法调用，而是多个对象协同完成一个事务的处理，再将结果返回。
采用Document方式构造消息，SOAP Body元素中的内容完全由WSDL 中的 XML Schema定义，于是可以使用XML Schema验证SOAP Body元素中的内容。SOAP Body的子元素指定为消息部分在WSDL文档中定义的 wsdl:part 元素，该元素指向 XML Schema元素声明。通常wsdl:message不会包含多个wsdl:part 元素，所以SOAP Body 内容是真正的 XML 文档，尽管 WSDL 本身不禁止包含多个wsdl:part元素。Document请求/响应消息的格式(省略了名称空间限定)如下：
| Document请求消息格式 | Document响应消息格式 |
| <SOAP信封> <SOAP头部> …… </SOAP头部> <SOAP消息体> <输入消息> …. </输入消息> …. </SOAP消息体> </SOAP信封> | <SOAP信封> <SOAP头部> …… </SOAP头部> <SOAP消息体> <输出消息> …. </输出消息> …. </SOAP消息体> </SOAP信封> |
2.2 use属性
use属性描述了消息序列化的方式，取值为”encoded”或者”literal”，默认值是”literal”。 如果use=”encoded”，设置encodingStyle属性的值指定编码规则。如果use=”literal”，可以不用设置encodingStyle属性的值，通常情况都是使用默认的XML Schema。适用于出现在下一个级别的 Web 服务方法参数（或返回值）。此选项指定为WSDL文档中的 soap:body、soap:header、soap:fault和soap:headerfault元素的 use 属性。
l Encoded
SOAP 编码使用 XML Schema的一个子集在 XML 文档与其所表示的数据之间进行绑定。SOAP 编码还使用href属性对文档中多次出现的元素的引用。SOAP编码和XML Schema编码完全不同的地方是数组。SOAP规范的5.4.2节指定了一种特别的机制来表示 XML 中的编程语言数组，它使用一种特殊的SOAP-ENC:Array类型。而XML Schema是通过设置element的minOccurs和maxOccurs属性值表示数组。例如使用这两种编码方式对整形数组的定义如下：
| SOAP编码定义数组 <complexType name="ArrayOfInt"> <complexContent> <restriction base="SOAP-ENC:Array"> <sequence> <element name=”item” type=”xsd:int” minOccurs=”0” maxOccurs=”unbounded”/> </sequence> <attribute ref=" SOAP-ENC:arrayType" wsdl:arrayType="xsd:ArrayOfInt[]"/> </restriction> </complexContent> </complexType> |
| XML Schema定义数组 <complexType name="ArrayOfInt"> <sequence> <element name=”item” type=”xsd:int” minOccurs=”0” maxOccurs=”unbounded”/> </sequence> </complexContent> </complexType> |
假设一个加法服务的定义为public int[] add(int a[],int b[])，使用Encoded方式编码add方法的消息格式如下：
| <op:add xmlns:op=”http://act.buaa.edu.cn/add” xmlns: SOAP-ENC =” http://schemas.xmlsoap.org/soap/encoding/” xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=” http://www.w3.org/2001/XMLSchema-instance” > < a SOAP-ENC:arrayType=”xsd:int[2]” xsi:type=”SOAP-ENC:array”> <item xsi:type=”xsd:int”>45</item> <item xsi:type=”xsd:int”>36</item> </a> <b SOAP-ENC:arrayType=”xsd:int[2]” xsi:type=”SOAP-ENC:array”> <item xsi:type=”xsd:int”>235</item> <item xsi:type=”xsd:int”>67</item> </b> </op:add> |
l Literal
与Encoded相比，Literal采用XML Schema编码，而不是SOAP编码；Literal编码不需要数据类型属性。数据根据 WSDL 文档中指定的 XML Schema定义或导入 WSDL 文档的 XML Schema定义逐字进行格式设置。使用Literal方式编码add方法的消息格式如下：
| <op:add xmlns:op=”http://act.buaa.edu.cn/add”> <a> <item>45</item> <item>36</item> </a> <b> <item>235</item> <item>67</item> </b> </op:bdd> |
2.3 encodingStyle属性
WSDL规范中的encodingStyle属性和SOAP规范中的encodingStyle 属性定义是一样的。encodingStyle属性的值是一个URIs列表，由单个空格隔开，每个URI代表着一种消息的编码规则，它们按照编码的限制从强到弱排序。encodingStyle属性是用来指定SOAP消息的编码规则，也就是序列化的格式和类型系统。如果use=”encoded”，encodingStyle属性的值为”http://schemas.xmlsoap.org/soap/encoding/”，则表示使用SOAP规范的第5节的编码，这一节定义了将编程语言的类型映射到 XML 的基本机制。如果use=”literal”则使用外部提供的类型系统，也可以通过encodingStyle属性来指定Schema，但是通常情况下使用XML Schema来编码SOAP消息。
这其中的缘故是因为SOAP规范是在采用XML Schema规范之前编写的。因此，原始的SOAP规范必须提供一种方法来指明编码类型信息。然而，自从采用XML Schema之后，大多数语言使用自己的从XML Schema到编程语言类型之间的映射（或序列化规则），这使得SOAP编码变得过时。因此，推荐不要采用SOAP编码，而是采用使用Literal编码，在Literal映射中由 XML Schema 文档（通常是WSDL文档的形式）从外部指定映射。
3 消息构造
style和use属性都有两个值，通过它们之间的不同组合，就可以产生四种绑定样式，分别是rpc-literal、rpc-encoded、document-literal和document-encoded。为了使Document绑定样式能够支持RPC绑定样式的调用，增加了一种包装(Wrapped)样式，它只不过是对Document样式的使用进行了约束。这样就又增加了两种绑定样式， document-literal-wrapped和document-encoded-wrapped，一共合起来就有6种绑定样式。下面通过一个加法服务为例来说明在不同绑定样式下的SOAP消息构造，服务的定义如下：
| //Java Code public int add(int a , int b) { return a+b; } |
从服务的定义可以看出，输入操作的操作名为add，有a和b两个整数类型的输入参数。根据WSDL规范返回操作的操作名应该为addResponse，有一个整数类型的输出参数，假设命名为return。
操作的序列化是需要名称空间限定的。如果是RPC调用方式，则名称空间是soap :body的namespace属性值；如果是Document调用方式，名称空间则是输入消息引用的Schema的targetNamespace属性值。参数的序列化是否需要名称空间限定取决于Schema定义时elementFormDefault属性的值。如果值为”qualified”则表示需要限定，名称空间为Schema的targetNamespace属性值；如果值为”unqualified”表示不用限定，默认值为”unqualified”。操作序列化后的元素作为SOAP消息体的子元素，而每个参数序列化后的元素都是作为操作元素的子元素，排列的顺序和操作的参数定义顺序一样。
假定以下所有SOAP消息都是在如下条件下构造：
l 如果use= ”encoded”则encodingStyle的值为”http://schemas.xmlsoap.org/soap/encoding/”，如果use= ”literal”则使用” http://www.w3.org/2001/XMLSchema”编码。
l 如果style=”rpc”则wsdl:part 部分的类型引用使用type属性，如果style=”document”则使用element属性。
1) rpc-literal绑定样式
| WSDL描述： <wsdl:definitions xmlns:wsdl= " http://schemas.xmlsoap.org/wsdl/" xmlns:ns="http://act.buaa.edu.cn/add" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://act.buaa.edu.cn/add"> <wsdl:message name=”addRequest”> <wsdl:part name=”a” type=”xsd:int”/> <wsdl:part name=”b” type=”xsd:int ”/> </wsdl:message> <wsdl:message name=”addReponse”> <wsdl:part name=”return” type=”xsd:int”/> </wsdl:message> <!--Just assume it's rpc-literal. --> …… |
| SOAP请求消息： <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <op: add xmlns:op=“http://act.buaa.edu.cn/add”> <a>12</a> <b>45</b> </op: add > </env:Body> </env:Envelope> |
优点：WSDL 描述和SOAP消息基本达到了尽可能地简单易懂的要求；服务的操作名出现在SOAP消息的Body中，这样接收者就可以很轻松地把消息发送到方法的实现；没有类型编码，提高了吞吐量，减少了处理的性能开销。
缺点：在RPC模型中XML仅仅被用于描述方法的信息，不能充分利用XML的功能去描述和验证一份业务文档 ；不能使用Schema简单地检验此消息的有效性，因为只有参数a和b是Schema 中定义的内容，其余的 env:body 内容(例如add元素)都来自 WSDL 定义；无法直接从消息中获得参数的类型信息；RPC样式对请求/响应消息的模式捆绑，使得服务与客户端之间耦合性增加，一旦方法发生变化，客户端就需要做相应的改动；相对异步调用方式而言，RPC样式下服务调用通常是同步的。
2) rpc-encoded 绑定样式
| 参照rpc-literal绑定样式的WSDL文档 |
| SOAP请求消息： <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=” http://www.w3.org/2001/XMLSchema-instance” > <env:Body> <op: add xmlns:op=“http://act.buaa.edu.cn/add”> < a xsi:type=”xsd:int”>12</a> <b xsi:type=”xsd:int”>45</b> </op: add > </env:Body> </env:Envelope> |
与rpc-literal绑定样式唯一的区别就是请求消息的参数部分编码方式不一样。消息中的每个参数都有类型编码（比如 <a xsi:type=”int”>12</a>），直接从消息就可以知道参数的数据类型。但是这些类型信息降低了吞吐量和消息处理的性能。尤其是在大数据的情况下，性能开销明显。
rpc-encoded绑定样式主要在重载、数据图形和多态的情况下使用。WSDL 允许重载的操作，但是当参数个数相同的情况下，因为Literal编码方式没有类型信息，无法定位方法，所以rpc-literal就不支持这样的重载。数据图形的标准方式是使用href 标记，它是 rpc-encoded的样式。多态所生成的 SOAP 消息必须包含类型编码信息，这样接收终端才能知道它所接收的是父类的哪一个扩展。
3) document /literal绑定样式
| WSDL 描述： <wsdl:definitions xmlns:wsdl= " http://schemas.xmlsoap.org/wsdl/" xmlns:ns="http://act.buaa.edu.cn/add" targetNamespace=" http://act.buaa.edu.cn/add "> <wsdl :types> <xs:schema elementFormDefault="qualified" targetNamespace="http://act.buaa.edu.cn/add" xmlns:xs="http://www.w3.org/2001/XMLSchema" > <xs:element name="a" type="xs:int " /> <xs:element name="b" type="xs:int " /> <xs:element name="return" type="xs:int " /> </xs :schema> </wsdl :types> <wsdl:message name=”addRequest”> <wsdl:part name=”parameter1” element=”ns:a”/> <wsdl:part name=”parameter2” element=”ns:b”/> </wsdl:message> <wsdl:message name=”addReponse”> <wsdl:part name=”parameter” element=”ns:return”/> </wsdl:message> <!--Just assume it's document-literal. --> …… |
| SOAP 请求消息： <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:op=“http://act.buaa.edu.cn/add”> <env:Body> <op:a>12</op:a> <op:b>45</op:b> </env:Body> </env:Envelope> |
请求消息的参数元素添加了名称空间限定，这是因为输入消息在WSDL文档的Schema中定义，而且Schema的elementFormDefault=”qualified”。也就是说参数元素必须使用Schema的名称空间"http://act.buaa.edu.cn/add"进行限定。
优点：没有操作和类型编码信息，减少了消息的数据量，提高了消息处理性能；env:Body中每项内容都定义在Schema中，可以用任何XML检验器检验此消息的有效性。
缺点：WSDL文档变得比较复杂，这不过是一个非常小的缺点，因为 WSDL 并没有打算由人来读取；SOAP消息中没有提供服务操作的名称，一些特定的程序代码在分发消息时可能会变得复杂，并且有时变得不可能。如果使用HTTP作为底层传输协议，可以使用SOAPAction属性绑定操作的名称来解决消息分发的问题。虽然大多数情况下都是使用HTTP协议来传输SOAP消息，但是这种方法绑定了底层传输协议，限制了其他传输协议的使用。
4) document /encoded绑定样式
| 参照document-literal绑定样式的WSDL文档 |
| SOAP 请求消息： <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=” http://www.w3.org/2001/XMLSchema-instance” xmlns:op=“http://act.buaa.edu.cn/add”> <env:Body> <op:a xsi:type=”xsd:int”>12</op:a> <op:b xsi:type=”xsd:int”>45</op:b> </env:Body> </env:Envelope> |
与document-literal绑定样式唯一的区别就是请求消息的参数部分编码方式不一样。引入了类型编码，降低了吞吐量和消息处理的性能。这种绑定样式不被大多数Web服务实现平台支持。
5) document-literal-wrapped绑定样式
| WSDL描述： <wsdl:definitions xmlns:wsdl= " http://schemas.xmlsoap.org/wsdl/" xmlns:ns="http://act.buaa.edu.cn/add" targetNamespace=" http://act.buaa.edu.cn/add "> <wsdl :types> <xs:schema elementFormDefault="qualified" targetNamespace="http://act.buaa.edu.cn/xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" > <xs:element name="add"> <xs:complexType> <xs:sequence> <xs:element name="a" type="xs:int " /> <xs:element name="b" type="xs:int " /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="addResponse"> <xs:complexType> <xs:sequence> <xs:element name="return" type="xs:int " /> </xs:sequence> </xs:complexType> </xs:element> </xs :schema> </wsdl :types> <wsdl:message name=”addRequest”> <wsdl:part name=”parameter” element=”ns:add”/> </wsdl:message> <wsdl:message name=”addReponse”> <wsdl:part name=”parameter” element=”ns:addResponse”/> </wsdl:message> <!--Just assume it's document-literal-wrapped. --> …… |
| SOAP请求消息： <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <op: add xmlns:op=“http://act.buaa.edu.cn/add”> <op:a>12</op:a> <op:b>45</op:b> </op: add > </env:Body> </env:Envelope> |
此时SOAP Body中第一个元素的名称并不是操作的名称，而是Schema中的元素的名称。Schema中的元素的名称可以与操作名相同，也可以不同。如果取相同则是一种将操作名放入SOAP消息的巧妙方式。
虽然此SOAP 消息看起来与 rpc-literal的 SOAP 消息是完全一样的(如果不考虑名称空间限定)，但是这两种消息之间存在着微妙的区别。在 rpc-literal的 SOAP 消息中，<env:Body>下的<op:add>根元素是操作的名称。在document-literal-wrapped的SOAP 消息中，<op:add>元素是单个输入消息的组成部分引用的元素的名称。
document-literal-wrapped样式规定Document绑定操作的输入消息和输出消息都只有一个wsdl:part部分；该部分使用element属性引用一个元素；该元素是复杂类型并且没有属性；该元素的名称和操作的名称必须一样。
优点：包装行为吸取了RPC样式的一个重要优点，即RPC样式中SOAP消息体可以直接通过与之关联的服务操作名称来命名，同时又摒弃了RPC样式的不足之处；可以利用WSDL文档类型部分的Schema文档直接来验证SOAP消息体；只要在Schema中定义了明确的数据结构，如何构建SOAP消息体具有很大的灵活性；由于业务数据是自包含的，显然文档模型更利于采用异步处理。
缺点：WSDL 较为复杂, 但是这仍然是一个非常小的缺点。使得服务调用的复杂度有所增加，尤其是在API级别。针对程序开发人员来说，基于包装的document绑定样式的服务编写客户端代码也许就变成了一项极具挑战性的工作。在SOAP消息体的XML包装元素中必须拥有一个服务操作的名称，因此包装版本不支持重载的服务操作。实际上，针对一个既定的元素名称也只能够有一个服务操作。
6) document-encoded-wrapped绑定样式
| 参照document-literal-wrapped绑定样式的WSDL文档 |
| SOAP请求报文 <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=” http://www.w3.org/2001/XMLSchema-instance” > <env:Body> <op: add xmlns:op=“http://act.buaa.edu.cn/add”> <op:a xsi:type=”xsd:int”>12</op:a> <op:b xsi:type=”xsd:int”>45</op:b> </op: add > </env:Body> </env:Envelope> |
与document -literal-wrapped绑定样式唯一的区别就是请求消息的参数部分编码方式不一样。引入了类型编码，降低了吞吐量和消息处理的性能。
4 互操作性
虽然Web服务解决了异构平台/系统之间应用的互操作性，但是不同Web服务实现平台的差异性带来了新的互操作性问题。主要原因如下：
l 不同的标准化组织规定了许多不同的Web服务标准，各标准也有许多不同的版本。
l WSDL/SOAP协议的某些规定的模糊性和灵活性，使得每个人对协议本身的理解并不完全一致。
l 不同Web服务实现平台对Web服务标准的支持程度不一致。
于是成立了WS-I(Web Services Interoperability Organization)组织，它致力于促进跨平台、跨操作系统和跨程序语言的网络服务互操作性。然而WS-I不是一个标准制订组织，它只是站在实践的角度，为在不同的环境下如何选择和使用各标准组织提供的各类标准提出实践的建议，它是W3C的补充。
WS-I 的第一个基本概要(Basic Profile 1.0，简称BP 1.0)在阐明各个规范方面做得非常不错，但它并不完美。尤其对SOAP with Attachments (Sw/A)的支持仍然相当不明确。于是同一年WS-I发布了第二个基本概要(BP 1.1)用于描述SOAP 1.1、WSDL 1.1和带附件的MIME SOAP协议的互操作性。WS-I将附件从BP 1.1中分离出来，并对第一版中一些没有讨论的内容进行了补充。当时WS-I添加了两个互不包括的基本概要补充文档：AP 1.0 和 SSBP 1.0。AP 1.0 是附件概要 (Attachment Profile)，描述如何使用Sw/A。SSBP 1.0是简单SOAP绑定概要 (Simple SOAP Binding Profile)，描述并不支持Sw/A的Web服务引擎。WS-I 所提供的其他概要文件都是以这些基本概要文件为基础构建的。之后WS-I又发布了第三个基本概要(BP 1.2)和第四个基本概要(BP 2.0)，这两个基本概要都兼容BP 1.1。BP 1.2在BP 1.1的基础上添加了一些新的约束，而BP 2.0的最大不同之处就是它支持的SOAP版本是SOAP 1.2。
BP 1.1 对消息绑定样式进行了限制：禁止使用Encoded编码，只能使用XML Schema 1.0编码，名称空间为” http://www.w3.org/2001/XMLSchema”；只支持rpc-literal和document-literal（当然document-literal-wrapped也是document-literal样式）两种绑定样式；RPC绑定必须使用 wsdl:part 中的type属性，而 Document 绑定必须同element属性一起使用；属性element引用 XML 模式元素，而属性type则指示XSD中的 simpleType 和 complexType。
简而言之，Document 样式的消息基于 XML Schema元素定义，而 RPC 样式的消息则使用 XML Schema类型定义。而且，只有全局级别的元素和类型能够在 WSDL 定义中定义，这些元素和类型是 XSD 中的 <schema> 的直接子项。所有非直接子项组件都是本地的，通常嵌套在另一个模式组件中，此处的组件将引用模式元素、complexType 或 simpleType。
扫一扫
1456
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
