[转]SOAP协议初级指南(三)
与存取元素相关的另一个问题是由于类型关系引起的可代换性。由于前面的adjustment类不是一个final类型的类，transfer对象的from和to域实际引用继承类型的实例是可能的。为了支持这种类型兼容的替换，SOAP使用一个名域限定的类型属性的XML Schema约定。这种类型属性的值是一个对元素具体的类型的限制的名字。考虑下面的adjustment扩展类：
package com.bofsoap.IBank;
public class auditedadjustment extends adjustment {
public int auditlevel;
}
给出下面Java语言：
transfer xfer = new transfer();
xfer.from = new auditedadjustment();
xfer.from.account = 3514; xfer.from.amount = -100;
xfer.from.auditlevel = 3;
xfer.to = new adjustment();
xfer.to.account = 3518; xfer.from.amount = 100;
在SOAP中transfer对象的序列化形式如下所示：
＜t:transfer
xmlns:xsd=‘http://www.w3.org/1999/XMLSchema‘
xmlns:t=‘urn:develop-com:java:com.bofsoap.IBank‘
＞
＜from xsd:type=‘t:auditedadjustment‘ ＞
＜account＞3514＜/account＞
＜amount＞-100.0＜/amount＞
＜auditlevel＞3＜/auditlevel ＞
＜/from＞
＜to＞
＜account＞3518＜/account＞
＜amount＞100.0＜/amount＞
＜/to＞
＜/t:transfer＞
在这里xsd:type属性引用一个名域限定的类型名，它能被反序列化程序用于实例化对象的正确类型。因为to存取元素引用到一个被预料的类型的实例（而不是一个可代替的继承类型），xsd:type属性是不需要的。
刚才的transfer类设法回避了一个关键问题。如果正被序列化的transfer对象用下面这种方式初始化将会发生什么情况：
transfer xfer = new transfer();
xfer.from = new adjustment();
xfer.from.account = 3514; xfer.from.amount = -100;
xfer.to = xfer.from;
基于以前的议论，在SOAP 中transfer对象的序列化形式如下所示：
＜t:transfer
xmlns:t=‘urn:develop-com:java:com.bofsoap.IBank‘＞
＜from＞
＜account＞3514＜/account＞
＜amount＞-100.0＜/amount＞
＜/from＞
＜to＞
＜account＞3514＜/account＞
＜amount＞-100.0＜/amount＞
＜/to＞
＜/t:transfer＞
这个表达有两个问题。首先最容易理解的问题是同样的信息被发送了两次,这导致了一个比实际所需要消息的更大的消息。一个更微妙的但是更重要的问题是由于反序列化程序不能分辨两个带有同样值的adjustment对象与在两个地方被引用的一个单一的adjustment对象的区别，两个存取元素间的身份关系就被丢失。如果这个消息接收者已经在结果对象上执行了下面的测试，(xfer.to == xfer.from)将不会返回true。
void processTransfer(transfer xfer) {
if (xfer.to == xfer.from)
handleDoubleAdjustment(xfer.to);
else
handleAdjustments(xfer.to, xfer.from);
}
(xfer.to.equals(xfer.from))可能返回true的事实只是比较了两个存取元素的值而不是它们身份。
为了支持必须保持身份关系的类型的序列化，SOAP支持多引用存取元素。目前我们接触到的存取元素是单引用存取元素，也就是说，元素值是嵌入在存取元素下面的，而且其它存取元素被允许引用那个值（这很类似于在NDR中的[unique]的概念）。多引用存取元素总是被编码为只包含已知的soap:href属性的空元素。soap:href属性总是包含一个代码片段标识符，它对应于存取元素引用到的实例。如果to和from存取元素已经被编码为多引用存取元素，序列化的transfer对象如下所示：
＜t:transfer
xmlns:t=‘urn:develop-com:java:com.bofsoap.IBank‘＞
＜from soap:href=‘#id1‘ /＞
＜to soap:href=‘#id1‘ /＞
＜/t:transfer＞
这个编码假设与adjustment类兼容的一个类型的实例已经在envelope中的其它地方被序列化，而且这个实例已经被用soap:id属性标记，如下所示：
＜t:adjustment soap:id=‘id1‘
xmlns:t=‘urn:develop-com:java:com.bofsoap.IBank‘＞
＜account＞3514＜/account＞
＜amount＞-100.0＜/amount＞
＜/t:adjustment＞
对多引用存取元素，把代码段的标识符（例如#id1）分解到正确的实例是反序列化程序的工作。
前面的讨论解释了多引用存取元素怎样与它的目标实例相关联。下面要讨论的是目标实例在哪里被序列化。这就关系到独立元素和包的概念。
独立元素
在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:id="id1"＞Hello, SOAP＜/field2＞
＜/t:mytype＞
尽管事实是存取元素2有一个soap:id属性，它实际上是一个存取元素而不是独立元素。
SOAP数组
数组被编码为组合类型的一个特殊的例子。在SOAP中，一个数组必须有一个秩（维数）和一个容量。一个数组被编码为一个组合类型，其中每一个数组元素被编码为一个子元素，这个子元素的名字是元素的名域限制的类型名。
假设有下面的COM IDL类型定义：
struct POINTLIST {
long cElems;
[size_is(cElems)] POINT points[];
};
这个类型的实例将被序列化为：
＜t:POINTLIST xmlns:t=‘uri for POINTLIST‘＞
＜cElems＞3＜/cElems＞
＜points xsd:type=‘t:POINT[3]‘ ＞
＜POINT＞lt;x＞3＜/x＞lt;y＞4＜/y＞lt;/POINT＞
＜POINT＞lt;x＞7＜/x＞lt;y＞5＜/y＞lt;/POINT＞
＜POINT＞lt;x＞1＜/x＞lt;y＞9＜/y＞lt;/POINT＞
＜/points＞
＜t:POINTLIST＞
如果points域被标记为[ptr]属性，这个编码将用一个多引用存取元素，如下所示：
＜t:POINTLIST xmlns:t=‘uri for POINTLIST‘＞
＜cElems＞3＜/cElems＞
＜points soap:href="#x9" /＞
＜/t:POINTLIST＞
＜t:ArrayOfPOINT soap:id=‘x9‘ xsd:type=‘t:POINT[3]‘＞
＜POINT＞lt;x＞3＜/x＞lt;y＞4＜/y＞lt;/POINT＞
＜POINT＞lt;x＞7＜/x＞lt;y＞5＜/y＞lt;/POINT＞
＜POINT＞lt;x＞1＜/x＞lt;y＞9＜/y＞lt;/POINT＞
＜/t:ArrayOfPOINT＞
当把一个数组编码为一个独立元素时，标记名是带前缀ArrayOf的类型名。
象NDR和CDR一样，SOAP支持部分转换的数组。如果子元素的数量少于所声明的容量，这些元素被假设正从数组的末尾丢失。这能够通过在正包含的数组元素上使用soap:offset属性来被忽略。
＜t:ArrayOfPOINT soap:id=‘x9‘ xsd:type=‘t:POINT[5]‘
soap:offset=‘[1]‘＞
＜POINT＞lt;x＞1＜/x＞lt;y＞9＜/y＞lt;/POINT＞
＜/t:ArrayOfPOINT＞
soap:offset属性表示出现在数组中的第一个元素的索引。在上面的例子中，元素0，2到4都是不被转换的。SOAP也支持稀疏数组，这是通过使用soap:position属性来把每个元素用它的绝对索引来注释而实现的：
＜t:ArrayOfPOINT soap:id=‘x9‘ xsd:type=‘t:POINT[9]‘＞
＜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错误代码或者一个专门应用的名域限制的值。当前的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的熟悉程度，以及你的目标平台的成熟度，你所花费的时间会有所不同。
