＜POINT soap:position=‘[3]‘＞lt;x＞3＜/x＞lt;y＞4＜/y＞lt;/POINT＞
＜POINT soap:position=‘[7]‘＞lt;x＞4＜/x＞lt;y＞5＜/y＞lt;/POINT＞
＜/t:ArrayOfPOINT＞
在这个例子中，元素0到2，4到6，以及8到9都不是被转换的。
请注意，在SOAP中数组的精确语法在这篇文章写作时还在被重新审查以调整到即将推出的W3C XML Schema规范中。要不断了解SOAP规范的最新版本来获得更多的细节。
错误处理
一个服务器有时将不能正确地为一个方法请求提供服务。这可能是由于一般的HTTP错误造成的（如请求-URI不能被映射到本地的资源或一个HTTP级的安全违反）。也可能是在SOAP翻译软件中的问题，如马歇尔打包错误或一个必须的头不能被认出。 ![]() ![]() ![]() ![]()
![]() ![]() ![]() ![]() 其它可能的原因包括一个请求不能正确地被服务，或者应用/对象代码决定要返回一个应用级的错误给调用者。这些情况在SOAP规范中都被清楚地加以处理。
如果在分发对任何SOAP代码的调用之前一个错误发生在HTTP层，一个纯HTTP响应必须被返回。标准的HTTP状态代码编号将被采用，400级的代码表示一个客户引发的错误，500级的代码表示服务器引发的错误。这通常在代码执行前由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错误代码或者一个专门应用的名域限制的值。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＞
假设具体应用的错误需要被返回。在应用定义的错误的情况下，考虑应用的异常/错误对象时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 等程序间的互操作性。
上一篇:基于Windows的入门级IDS构建过程详述
下一篇:基于CS模式的Winsock网络通讯程序
|
精品推荐