独立元素
在SOAP中， 一个独立元素表示至少被一个多引用存取元素引用的类型的实例。所有的独立元素用soap:id属性作标记，而且这个属性的值在整个SOAP envelope中必须是唯一的。独立的元素被编码就好象是它们被一个存取元素打包，这个存取元素的标记名是实例的名域限制的类型名。在上面的例子中，实 例的名域限制的类型名是t:adjustment。
SOAP限制独立元素能被编码的场所。SOAP定义了一个能适用于任何元素的属 性：(soap:Package)。这个属性被用于控制独立元素能在哪里被解码。SOAP序列化规则指出独立元素必须编码为soap:Header元素或 soap:Body元素的直接子元素，或者是任何其它标记为soap:Package=‘true’的元素。通过把一个元素注释为包，你能保证编码那个实 例的XML元素是完全自包含的，并且在这个包以外没有任何引用到这个元素的多引用存取元素。
假设transfer 类对应于一个方法请求。如果transfer类型不是一个包，被to和from存取元素引用的独立元素将作为soap:Body元素的直接子元素出现，如 图10所示。如果transfer类型是一个合法的SOAP包类型，编码可能象图11所示。注意，因为transfer元素是一个包，所有多引用存取器元 素都引用被包含的元素。这使得把transfer元素看成一个能从它的父辈元素中分离出的独立的XML代码段变得更为容易。
多引用存取元素总是引用独立元素的模型是有一个例外的。SOAP允许包含字符串和二进值数据的存取元素是多引用存取元素的目标。这意味着下面的代码是合法的：
＜t:mytype＞
＜field1 soap:href="#id1" /＞
＜field2 soap:>Web服务器软件自动处理。
假设在HTTP层一切正常，错误发生的下一个地方是在那些翻译和分发对应用代码（如COM对象和CORBA伺服对象）的SOAP调用。如果错误发生在这 一层，服务器必须返回一个错误消息来代替一个标准的响应消息。一个错误消息是下列被编码为soap:Body的根元素的类型的实例。
＜schema
targetNamespace=‘urn:schemas-xmlsoap-org:soap.v1‘
＞
＜element name=‘Fault‘＞
＜type＞
＜element name=‘faultcode‘ type=‘string‘ /＞
＜element name=‘faultstring‘ type=‘string‘ /＞
＜element name=‘runcode‘ type=‘string‘ /＞
＜element name=‘detail‘ /＞
＜/type＞
＜/element＞
＜/schema＞
faultcode存取元素必须包含一个用已知的整数表示的SOAP错误代码或者一个专门应用的名域限制的值。当前的SOAP 错误代码如图12所示。Faultstring存取元素包含对发生的错误的可读性的描述。runcode 存取元素包含一个字符串，它的值必须是Yes, No或 Maybe，表明被请求的操作实际上是否在错误产生之前被执行。Detail存取元素是可选的，用于包含一个专门应用的异常对象。
下面是一个对应于一个包含无法识别的必须的头元素的请求的SOAP错误的例子：
＜soap:Envelope
xmlns:soap=‘urn:schemas-xmlsoap-org:soap.v1‘
＞
＜soap:Body＞
＜soap:Fault＞ ;
＜faultcode＞200＜/faultcode＞
＜faultstring＞
Unrecognized ‘causality‘ header
＜/faultstring＞
＜runcode＞No＜/runcode＞
＜/soap:Fault＞
＜/soap:Body＞
＜/soap:Envelope＞
假设具体应用的错误需要被返回，你可能看到如图13所示的代码。在应用定义的错误的情况下，考虑应用的异常/错误对象时detail存取元素起到了soap:Body 元素的作用。
奥秘
一个遗留的HTTP问题还需要进一步阐明。SOAP支持（但不需要）HTTP扩展框架约定来指定必须的HTTP头扩展。这些约定主要有两个目的。首先， 它们允许任意的URI被用于限定给定的HTTP头的范围（象XML名域一样）。第二，这些约定允许把必须的头与可选的头区分开来（象 soap:mustUnderstand)。下面是一个使用HTTP扩展框架来把SOAPMethodName头定义成为一个必须的头扩展：
M-POST /foobar HTTP/1.1
Host: 209.110.197.2
Man: "urn:schemas-xmlsoap-org:soap.v1; ns=42"
42-SOAPMethodName: urn:bobnsid:IFoo#DoIt
Man头映射SOAP URI到前缀为42的头，并表示没有认出SOAP的服务器必须返回一个HTTP错误，状态代码为501 (没有被实现) 或 510 (没有被扩展)。HTTP方法必须是M-POST，表明目前是必须的头扩展。
结论
SOAP是一个被类型化的序列化格式，它恰巧用HTTP 作为请求/响应消息传输协议。SOAP被设计为与正将出现的XML Schema规范密切配合，并支持在Internet的任何地方运行的COM, CORBA, Perl, Tcl, 和 Java-language, C, Python, 或 PHP 等程序间的互操作性。
希望本文给了你一个对这个协议具体细节的更清晰的理解。我鼓励你用SOAP进行实验，或者试着使用SOAP使能的系统之一（列在http://www.develop.com/soap/），或者自己做一些工作。我本人发现采用脚本语言（Jscript），使一个基本的SOAP客户与服务器建立并运行只花费了不到一个小时。针对你对HTTP和XML的熟悉程度，以及你的目标平台的成熟度，你所花费的时间会有所不同。
在SOAP中， 一个独立元素表示至少被一个多引用存取元素引用的类型的实例。所有的独立元素用soap:id属性作标记，而且这个属性的值在整个SOAP envelope中必须是唯一的。独立的元素被编码就好象是它们被一个存取元素打包，这个存取元素的标记名是实例的名域限制的类型名。在上面的例子中，实 例的名域限制的类型名是t:adjustment。
SOAP限制独立元素能被编码的场所。SOAP定义了一个能适用于任何元素的属 性：(soap:Package)。这个属性被用于控制独立元素能在哪里被解码。SOAP序列化规则指出独立元素必须编码为soap:Header元素或 soap:Body元素的直接子元素，或者是任何其它标记为soap:Package=‘true’的元素。通过把一个元素注释为包，你能保证编码那个实 例的XML元素是完全自包含的，并且在这个包以外没有任何引用到这个元素的多引用存取元素。
假设transfer 类对应于一个方法请求。如果transfer类型不是一个包，被to和from存取元素引用的独立元素将作为soap:Body元素的直接子元素出现，如 图10所示。如果transfer类型是一个合法的SOAP包类型，编码可能象图11所示。注意，因为transfer元素是一个包，所有多引用存取器元 素都引用被包含的元素。这使得把transfer元素看成一个能从它的父辈元素中分离出的独立的XML代码段变得更为容易。
多引用存取元素总是引用独立元素的模型是有一个例外的。SOAP允许包含字符串和二进值数据的存取元素是多引用存取元素的目标。这意味着下面的代码是合法的：
＜t:mytype＞
＜field1 soap:href="#id1" /＞
＜field2 soap:>Web服务器软件自动处理。
假设在HTTP层一切正常，错误发生的下一个地方是在那些翻译和分发对应用代码（如COM对象和CORBA伺服对象）的SOAP调用。如果错误发生在这 一层，服务器必须返回一个错误消息来代替一个标准的响应消息。一个错误消息是下列被编码为soap:Body的根元素的类型的实例。
＜schema
targetNamespace=‘urn:schemas-xmlsoap-org:soap.v1‘
＞
＜element name=‘Fault‘＞
＜type＞
＜element name=‘faultcode‘ type=‘string‘ /＞
＜element name=‘faultstring‘ type=‘string‘ /＞
＜element name=‘runcode‘ type=‘string‘ /＞
＜element name=‘detail‘ /＞
＜/type＞
＜/element＞
＜/schema＞
faultcode存取元素必须包含一个用已知的整数表示的SOAP错误代码或者一个专门应用的名域限制的值。当前的SOAP 错误代码如图12所示。Faultstring存取元素包含对发生的错误的可读性的描述。runcode 存取元素包含一个字符串，它的值必须是Yes, No或 Maybe，表明被请求的操作实际上是否在错误产生之前被执行。Detail存取元素是可选的，用于包含一个专门应用的异常对象。
下面是一个对应于一个包含无法识别的必须的头元素的请求的SOAP错误的例子：
＜soap:Envelope
xmlns:soap=‘urn:schemas-xmlsoap-org:soap.v1‘
＞
＜soap:Body＞
＜soap:Fault＞ ;
＜faultcode＞200＜/faultcode＞
＜faultstring＞
Unrecognized ‘causality‘ header
＜/faultstring＞
＜runcode＞No＜/runcode＞
＜/soap:Fault＞
＜/soap:Body＞
＜/soap:Envelope＞
假设具体应用的错误需要被返回，你可能看到如图13所示的代码。在应用定义的错误的情况下，考虑应用的异常/错误对象时detail存取元素起到了soap:Body 元素的作用。
奥秘
一个遗留的HTTP问题还需要进一步阐明。SOAP支持（但不需要）HTTP扩展框架约定来指定必须的HTTP头扩展。这些约定主要有两个目的。首先， 它们允许任意的URI被用于限定给定的HTTP头的范围（象XML名域一样）。第二，这些约定允许把必须的头与可选的头区分开来（象 soap:mustUnderstand)。下面是一个使用HTTP扩展框架来把SOAPMethodName头定义成为一个必须的头扩展：
M-POST /foobar HTTP/1.1
Host: 209.110.197.2
Man: "urn:schemas-xmlsoap-org:soap.v1; ns=42"
42-SOAPMethodName: urn:bobnsid:IFoo#DoIt
Man头映射SOAP URI到前缀为42的头，并表示没有认出SOAP的服务器必须返回一个HTTP错误，状态代码为501 (没有被实现) 或 510 (没有被扩展)。HTTP方法必须是M-POST，表明目前是必须的头扩展。
结论
SOAP是一个被类型化的序列化格式，它恰巧用HTTP 作为请求/响应消息传输协议。SOAP被设计为与正将出现的XML Schema规范密切配合，并支持在Internet的任何地方运行的COM, CORBA, Perl, Tcl, 和 Java-language, C, Python, 或 PHP 等程序间的互操作性。
希望本文给了你一个对这个协议具体细节的更清晰的理解。我鼓励你用SOAP进行实验，或者试着使用SOAP使能的系统之一（列在http://www.develop.com/soap/），或者自己做一些工作。我本人发现采用脚本语言（Jscript），使一个基本的SOAP客户与服务器建立并运行只花费了不到一个小时。针对你对HTTP和XML的熟悉程度，以及你的目标平台的成熟度，你所花费的时间会有所不同。
我来自：向东博客
独立元素在SOAP中， 一个独立元素表示至少被一个多引用存取元素引用的类型的实例。所有的独立元素用soap:id属性作标记，而且这个属性的值在整个SOAP envelope中必须是唯一的。独立的元素被编码就好象是它们被一个存取元素打包，这个存取元素的标记名是实例的名域限制的类型名。在上面的例子中，实 例的名域限制的类型名是t:adjustment。
SOAP限制独立元素能被编码的场所。SOAP定义了一个能适用于任何元素的属 性：(soap:Package)。这个属性被用于控制独立元素能在哪里被解码。SOAP序列化规则指出独立元素必须编码为soap:Header元素或 soap:Body元素的直接子元素，或者是任何其它标记为soap:Package=‘true’的元素。通过把一个元素注释为包，你能保证编码那个实 例的XML元素是完全自包含的，并且在这个包以外没有任何引用到这个元素的多引用存取元素。
假设transfer 类对应于一个方法请求。如果transfer类型不是一个包，被to和from存取元素引用的独立元素将作为soap:Body元素的直接子元素出现，如 图10所示。如果transfer类型是一个合法的SOAP包类型，编码可能象图11所示。注意，因为transfer元素是一个包，所有多引用存取器元 素都引用被包含的元素。这使得把transfer元素看成一个能从它的父辈元素中分离出的独立的XML代码段变得更为容易。
多引用存取元素总是引用独立元素的模型是有一个例外的。SOAP允许包含字符串和二进值数据的存取元素是多引用存取元素的目标。这意味着下面的代码是合法的：
＜t:mytype＞
＜field1 soap:href="#id1" /＞
＜field2 soap:>Web服务器软件自动处理。
假设在HTTP层一切正常，错误发生的下一个地方是在那些翻译和分发对应用代码（如COM对象和CORBA伺服对象）的SOAP调用。如果错误发生在这 一层，服务器必须返回一个错误消息来代替一个标准的响应消息。一个错误消息是下列被编码为soap:Body的根元素的类型的实例。
＜schema
targetNamespace=‘urn:schemas-xmlsoap-org:soap.v1‘
＞
＜element name=‘Fault‘＞
＜type＞
＜element name=‘faultcode‘ type=‘string‘ /＞
＜element name=‘faultstring‘ type=‘string‘ /＞
＜element name=‘runcode‘ type=‘string‘ /＞
＜element name=‘detail‘ /＞
＜/type＞
＜/element＞
＜/schema＞
faultcode存取元素必须包含一个用已知的整数表示的SOAP错误代码或者一个专门应用的名域限制的值。当前的SOAP 错误代码如图12所示。Faultstring存取元素包含对发生的错误的可读性的描述。runcode 存取元素包含一个字符串，它的值必须是Yes, No或 Maybe，表明被请求的操作实际上是否在错误产生之前被执行。Detail存取元素是可选的，用于包含一个专门应用的异常对象。
下面是一个对应于一个包含无法识别的必须的头元素的请求的SOAP错误的例子：
＜soap:Envelope
xmlns:soap=‘urn:schemas-xmlsoap-org:soap.v1‘
＞
＜soap:Body＞
＜soap:Fault＞ ;
＜faultcode＞200＜/faultcode＞
＜faultstring＞
Unrecognized ‘causality‘ header
＜/faultstring＞
＜runcode＞No＜/runcode＞
＜/soap:Fault＞
＜/soap:Body＞
＜/soap:Envelope＞
假设具体应用的错误需要被返回，你可能看到如图13所示的代码。在应用定义的错误的情况下，考虑应用的异常/错误对象时detail存取元素起到了soap:Body 元素的作用。
奥秘
一个遗留的HTTP问题还需要进一步阐明。SOAP支持（但不需要）HTTP扩展框架约定来指定必须的HTTP头扩展。这些约定主要有两个目的。首先， 它们允许任意的URI被用于限定给定的HTTP头的范围（象XML名域一样）。第二，这些约定允许把必须的头与可选的头区分开来（象 soap:mustUnderstand)。下面是一个使用HTTP扩展框架来把SOAPMethodName头定义成为一个必须的头扩展：
M-POST /foobar HTTP/1.1
Host: 209.110.197.2
Man: "urn:schemas-xmlsoap-org:soap.v1; ns=42"
42-SOAPMethodName: urn:bobnsid:IFoo#DoIt
Man头映射SOAP URI到前缀为42的头，并表示没有认出SOAP的服务器必须返回一个HTTP错误，状态代码为501 (没有被实现) 或 510 (没有被扩展)。HTTP方法必须是M-POST，表明目前是必须的头扩展。
结论
SOAP是一个被类型化的序列化格式，它恰巧用HTTP 作为请求/响应消息传输协议。SOAP被设计为与正将出现的XML Schema规范密切配合，并支持在Internet的任何地方运行的COM, CORBA, Perl, Tcl, 和 Java-language, C, Python, 或 PHP 等程序间的互操作性。
希望本文给了你一个对这个协议具体细节的更清晰的理解。我鼓励你用SOAP进行实验，或者试着使用SOAP使能的系统之一（列在http://www.develop.com/soap/），或者自己做一些工作。我本人发现采用脚本语言（Jscript），使一个基本的SOAP客户与服务器建立并运行只花费了不到一个小时。针对你对HTTP和XML的熟悉程度，以及你的目标平台的成熟度，你所花费的时间会有所不同。