Terry.Li-彬

許多開發(fā)者都遇到過這樣的情形：一個(gè)CORBA客戶程序需要獲得分布式組件對(duì)象模型（DCOM）客戶程序的服務(wù)，或者相反。常見的解決方案是使用一個(gè)COM/CORBA橋。然而，這種解決方案存在許多問題。假設(shè)在兩個(gè)已經(jīng)很復(fù)雜的系統(tǒng)之間（CORBA ORB和COM之間）引入了一個(gè)新的軟件，在CORBA的Internet Inter-ORB Protocol（IIOP）到DCOM的Object Remote Procedure Call（ORPC）之間，繁雜的雙向轉(zhuǎn)換將使得中間起橋接作用的軟件變得很復(fù)雜。任何對(duì)IIOP協(xié)議和ORPC協(xié)議的修改都導(dǎo)致修改橋接軟件。如果我說SOAP能夠緩解這個(gè)問題，你會(huì)怎么想呢？感興趣嗎？

SOAP的全稱是Simple Object Access Protocol，即簡(jiǎn)單對(duì)象訪問協(xié)議。簡(jiǎn)單地說，SOAP是一種有線協(xié)議，類似于CORBA的IIOP、DCOM的ORPC或Java遠(yuǎn)程方法調(diào)用的Java遠(yuǎn)程方法協(xié)議（Java Remote Method Protocol，JRMP）。你也許會(huì)懷疑，既然已經(jīng)有了那么多有線協(xié)議，為什么我們還需要另外一種？事實(shí)上，這不正好導(dǎo)致前面所討論的問題嗎？這些問題都有道理，但是，SOAP和其他有線協(xié)議有所不同。

我們來分析一下：

• IIOP、ORPC和JRMP都是二進(jìn)制協(xié)議，而SOAP則是一種使用XML的以文本為基礎(chǔ)的協(xié)議。利用XML進(jìn)行數(shù)據(jù)編碼為SOAP帶來一些獨(dú)一無二的功能。例如，調(diào)試以SOAP為基礎(chǔ)的應(yīng)用程序更容易，因?yàn)殚喿xXML要比閱讀二進(jìn)制數(shù)據(jù)容易得多。另外，由于所有的SOAP消息都是文本格式，和IIOP、ORPC或者JRMP相比，SOAP更容易和防火墻協(xié)作。
• SOAP協(xié)議以非供應(yīng)商私有的協(xié)議為基礎(chǔ)，即XML、HTTP和Simple Mail Transfer Protocol（SMTP），所有供應(yīng)商都可以使用SOAP協(xié)議。例如，Microsoft和各個(gè)CORBA ORB供應(yīng)商（例如Iona）一樣，已經(jīng)承諾支持SOAP。IBM在創(chuàng)建SOAP協(xié)議的過程中起到了重要的作用，它也為Java程序員創(chuàng)建了一個(gè)優(yōu)秀的SOAP工具包。該公司已經(jīng)把工具包捐贈(zèng)給Apache Software Foundation的XML Project，后者以該軟件包為基礎(chǔ)，構(gòu)造出了Apache-SOAP實(shí)現(xiàn)。這個(gè)實(shí)現(xiàn)在Apache許可之下免費(fèi)提供給用戶。再返回來看本文開頭提出的問題，如果DCOM使用SOAP，ORB供應(yīng)商也使用了SOAP，那么，COM/CORBA協(xié)同操作中出現(xiàn)的問題將變得不值一提。

SOAP決不只是一個(gè)漂亮的口號(hào)，它是一種即將深入滲透到未來分布式計(jì)算的技術(shù)。人們希望，SOAP結(jié)合其他技術(shù)，比如UDDI（Universal Discovery Description, and Integration）和WSDL（Web Services Description Language），在Web服務(wù)這一概念的支持下，改變未來商業(yè)應(yīng)用跨越Web進(jìn)行通信的方法。我甚至無法充分地表達(dá)出在開發(fā)者的工具包中加上SOAP知識(shí)的重要程度。這是一個(gè)關(guān)于SOAP的系列文章，總共四篇。這是第一篇，介紹一些基礎(chǔ)知識(shí)。我們將從SOAP這一思想的構(gòu)思說起。

一、SOAP簡(jiǎn)介
如前所述，SOAP用XML作為數(shù)據(jù)編碼格式。用XML作為數(shù)據(jù)編碼格式并非SOAP的原創(chuàng)，實(shí)際上這是一種相當(dāng)自然的選擇。XML-RPC和ebXML也同樣使用XML。要了解這方面的更多信息，請(qǐng)參見本文最后的“參考資源”。

請(qǐng)考慮下面的Java接口：

Listing 1 public interface Hello { public String sayHelloTo(String name); }

客戶程序在調(diào)用sayHelloTo()方法時(shí)提供了一個(gè)名字，它希望從服務(wù)器接收到一則個(gè)性化的“Hello”信息。現(xiàn)在，假定RMI、CORBA和DCOM都不存在，開發(fā)者必須負(fù)責(zé)串行化方法調(diào)用，并把消息發(fā)送給遠(yuǎn)程機(jī)器。幾乎所有的人都會(huì)說“這該使用XML”，我同意。因此，讓我們先從對(duì)服務(wù)器的請(qǐng)求格式開始。假設(shè)要模擬sayHelloTo("John")調(diào)用，我打算發(fā)送的請(qǐng)求是：

Listing 2 <?xml version="1.0"?> <Hello> <sayHelloTo> <name>John</name> </sayHelloTo> </Hello>

在這里，我把接口的名字作為根結(jié)點(diǎn)。另外，我還把方法名字和參數(shù)名字都當(dāng)作節(jié)點(diǎn)。接下來，我們要把這個(gè)請(qǐng)求發(fā)送給服務(wù)器。我們不創(chuàng)建自己的TCP/IP消息，而是使用HTTP。因此，下面的步驟應(yīng)該是把請(qǐng)求封裝成HTTP POST請(qǐng)求格式，然后把它發(fā)送給服務(wù)器。實(shí)際創(chuàng)建該HTTP POST請(qǐng)求的詳細(xì)過程在本文后面介紹，現(xiàn)在，我們先假定它已經(jīng)創(chuàng)建完畢。服務(wù)器接收到了這個(gè)請(qǐng)求，解碼XML，然后再以XML格式向客戶程序發(fā)送應(yīng)答。假設(shè)應(yīng)答內(nèi)容如下：

Listing 3 <?xml version="1.0"?> <Hello> <sayHelloToResponse> <message>Hello John, How are you?</message> </sayHelloToResponse> </Hello>

根節(jié)點(diǎn)仍然是接口的名字Hello。但這一次，原來對(duì)應(yīng)著方法的節(jié)點(diǎn)名字不再是sayHelloTo，而是方法的名字加上“Response”字符串。客戶程序知道自己調(diào)用了哪一個(gè)方法，要找出被調(diào)用方法的返回值，它只需查看名字為方法名字加上“Response”字符串的元素。

以上就是SOAP的根本思路。Listing 4顯示了同一請(qǐng)求用SOAP XML編碼之后的結(jié)果：

Listing 4 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <ns1:sayHelloTo xmlns:ns1="Hello" SOAP-ENV:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding/"> <name xsi:type="xsd:string">John</name> </ns1:sayHelloTo> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

看起來稍微復(fù)雜了一點(diǎn)，對(duì)吧？實(shí)際上，它和我們前面編寫的請(qǐng)求類似，只是略微擴(kuò)展了一些東西。首先，注意SOAP文檔通過一個(gè)Envelope（根節(jié)點(diǎn)）、一個(gè)Header區(qū)、一個(gè)Body區(qū)，整潔地組織到一起。Header區(qū)用來封裝那些與方法本身無直接關(guān)系的數(shù)據(jù)，提供環(huán)境方面的信息，比如事務(wù)ID和安全信息。Body區(qū)包含面向方法本身的信息。在Listing 2中，我們自己編寫的XML只包含一個(gè)Body區(qū)。

第二，注意Listing 4大量地應(yīng)用了XML名稱空間。SOAP-ENV映射到名稱空間http://schemas.xmlsoap.org/soap/envelope/，xsi映射到http://www.w3.org/1999/XMLSchema-instance，而xsd映射到http://www.w3.org/1999/XMLSchema。這三者是所有SOAP文檔都擁有的標(biāo)準(zhǔn)名稱空間。

最后，在Listing 4中，接口名稱（即Hello）不再象在Listing 2中那樣成為節(jié)點(diǎn)的名字；相反，它引用了一個(gè)名稱空間nsl。另外，參數(shù)的類型信息也隨同參數(shù)的值一起發(fā)送給了服務(wù)器。注意信封（Envelope）encodingStyle屬性的值。這個(gè)屬性值設(shè)置成了http://schemas.xmlsoap.org/soap/encoding/。這個(gè)值告訴服務(wù)器用來編碼（即串行化）方法的編碼方式；服務(wù)器需要這個(gè)信息，以便正確地解除方法的串行化。對(duì)于服務(wù)器來說，SOAP文檔的自我描述能力是相當(dāng)完善的。

對(duì)于上面的SOAP請(qǐng)求，服務(wù)器的應(yīng)答如下：

Listing 5 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-nstance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:sayHelloToResponse xmlns:ns1="Hello" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <return xsi:type="xsd:string">Hello John, How are you doing?</return> </ns1:sayHelloToResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Listing 5與Listing 4的請(qǐng)求消息類似。在上面的代碼中，返回值（即個(gè)性化的“Hello”消息）包含在Body區(qū)。SOAP消息文檔的格式非常靈活。例如，編碼方式不固定，而是由客戶程序指定。只要是客戶程序和服務(wù)器都認(rèn)可的編碼方式，可以是任何合法的XML文檔。

另外，分離調(diào)用環(huán)境信息意味著方法本身并不關(guān)心這類信息。在當(dāng)前的市場(chǎng)上，主流應(yīng)用服務(wù)器都遵從這一理念。早先，我曾經(jīng)指出環(huán)境信息可以包含事務(wù)和安全方面的信息。事實(shí)上，環(huán)境可以涵蓋幾乎所有的東西。下面是一個(gè)SOAP消息頭的例子，它帶有一些事務(wù)方面的信息：

Listing 6 <SOAP-ENV:Header> <t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1"> 5 </t:Transaction> </SOAP-ENV:Header>

名稱空間t映射到了與特定應(yīng)用有關(guān)的URI。這里的5表示的是該方法從屬于其中的事務(wù)ID。注意SOAP信封mustUnderstand屬性的應(yīng)用。這個(gè)屬性被設(shè)置成了1，它表示服務(wù)器要么理解并按照要求處理該事務(wù)請(qǐng)求，要么表示無法處理該請(qǐng)求；這是SOAP規(guī)范所要求的。

二、錯(cuò)誤處理
使用SOAP并不意味著任何時(shí)候所有的請(qǐng)求都會(huì)獲得成功。許多地方可能會(huì)出現(xiàn)差錯(cuò)。例如，服務(wù)器可能無法訪問某個(gè)關(guān)鍵性的資源（比如數(shù)據(jù)庫(kù)），因而無法順利地處理請(qǐng)求。

讓我們返回“Hello”實(shí)例，為它加上一個(gè)假想的約束，即“在星期二向別人說Hello不合法。”因此，星期二的時(shí)候，即使發(fā)送給服務(wù)器的請(qǐng)求是合法的，服務(wù)器也會(huì)把一個(gè)錯(cuò)誤信息返回給客戶端。應(yīng)答內(nèi)容將如下所示：

Listing 7 <SOAP-ENV:Envelope xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Server Error</faultstring> <detail> <e:myfaultdetails xmlns:e="Hello"> <message> Sorry, my silly constraint says that I cannot say hello on Tuesday. </message> <errorcode> 1001 </errorcode> </e:myfaultdetails> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

我們來分析一下http://schemas.xmlsoap.org/soap/envelope/名稱空間定義的Fault元素。Fault元素總是Body元素的直接子元素，所有的SOAP服務(wù)器必須始終通過該元素報(bào)告所有錯(cuò)誤情況。Fault元素必須包含faultcode和faultstring元素，不能有例外。faultcode是一個(gè)能夠標(biāo)識(shí)問題的代碼；客戶程序按照SOAP規(guī)范的要求利用faultcode進(jìn)行算法處理。SOAP規(guī)范定義了一小組錯(cuò)誤代碼供用戶使用。另一方面，faultstring是供人類閱讀的錯(cuò)誤信息。

Listing 7的代碼還包含了一個(gè)detail元素。由于錯(cuò)誤在處理SOAP消息的Body區(qū)時(shí)出現(xiàn)，detail元素必須出現(xiàn)。正如你將在本文后面看到的，如果錯(cuò)誤在處理Header區(qū)時(shí)出現(xiàn)，detail元素不應(yīng)出現(xiàn)。在Listing 7中，應(yīng)用利用detail元素提供當(dāng)前錯(cuò)誤更詳細(xì)、更自然的解釋，即星期二不允許說Hello。SOAP還提供另外一個(gè)面向具體應(yīng)用的錯(cuò)誤代碼，即半可選的faultfactor元素，但上面的錯(cuò)誤信息中沒有顯示這個(gè)元素。之所以稱這個(gè)元素是半可選的，是因?yàn)槿绻e(cuò)誤消息不是由請(qǐng)求最終處理點(diǎn)的服務(wù)器發(fā)送，即由一個(gè)中間服務(wù)器發(fā)送，則錯(cuò)誤消息必須包含該元素。SOAP對(duì)faultcode元素不應(yīng)出現(xiàn)的情形沒有作任何規(guī)定。

在Listing 7中，錯(cuò)誤起源于方法調(diào)用本身，處理該方法的應(yīng)用導(dǎo)致了這個(gè)錯(cuò)誤。現(xiàn)在，我們來看一下另一種類型的錯(cuò)誤，這種錯(cuò)誤由于服務(wù)器不能處理請(qǐng)求頭信息而導(dǎo)致。舉例來說，假設(shè)所有的Hello消息必須在一個(gè)事務(wù)環(huán)境之內(nèi)生成，則請(qǐng)求類似于：

Listing 8 <SOAP-ENV:Envelope xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi=" http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Header> <t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1"> 5 </t:Transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <ns1:sayHelloTo xmlns:ns1="Hello" SOAP-ENV:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding/"> <name xsi:type="xsd:string">Tarak</name> </ns1:sayHelloTo> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

上面消息的Header區(qū)包含一個(gè)transaction元素，它指定了方法調(diào)用必須從屬于其中的事務(wù)編號(hào)。這里我說“必須”是因?yàn)閠ransaction元素使用了mustUnderstand屬性。如前所述，SOAP服務(wù)器要么遵照屬性的指示處理請(qǐng)求，要么聲明不能處理請(qǐng)求。假定SOAP服務(wù)器不能處理，它必須返回一個(gè)錯(cuò)誤信息。這時(shí)的應(yīng)答應(yīng)該類似于：

Listing 9 <SOAP-ENV:Envelope xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:MustUnderstand</faultcode> <faultstring>SOAP Must Understand Error</faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

上面的代碼類似Listing 7顯示的錯(cuò)誤信息。但應(yīng)該注意的是，detail元素不再出現(xiàn)。正如我在前面指出的：SOAP規(guī)范規(guī)定，如果錯(cuò)誤在處理Header區(qū)的時(shí)候出現(xiàn)，則錯(cuò)誤消息中不應(yīng)包含detail元素。事實(shí)上，我們可以根據(jù)detail元素是否出現(xiàn)，迅速判定錯(cuò)誤是在處理Body區(qū)還是在處理Header區(qū)時(shí)出現(xiàn)。

三、SOAP與HTTP
在第一個(gè)例子中，我通過HTTP把定制的XML請(qǐng)求發(fā)送給服務(wù)器，但沒有詳細(xì)介紹這么做涉及到了哪些操作。現(xiàn)在我們回過頭來看那個(gè)問題。怎樣才能把一個(gè)SOAP請(qǐng)求（而不是定制的XML）通過HTTP發(fā)送給服務(wù)器？SOAP很自然地遵循了HTTP的請(qǐng)求/應(yīng)答消息模型。這個(gè)模型在HTTP請(qǐng)求中提供SOAP請(qǐng)求參數(shù)，在HTTP應(yīng)答中提供SOAP應(yīng)答參數(shù)。實(shí)際上，SOAP 1.0特別指明HTTP作為它的傳輸協(xié)議。SOAP 1.1略有放松。雖然SOAP 1.1仍舊可以使用HTTP，但它也可以使用其他協(xié)議，比如SMTP。在這個(gè)系列的文章中，我只討論通過HTTP使用SOAP的情形。

讓我們返回Hello示例。如果我們通過HTTP把SOAP請(qǐng)求發(fā)送給服務(wù)器，則代碼應(yīng)該類似于：

Listing 10 POST http://www.SmartHello.com/HelloApplication HTTP/1.0 Content-Type: text/xml; charset="utf-8" Content-Length: 587 SOAPAction: "http://www.SmartHello.com/HelloApplication#sayHelloTo" <SOAP-ENV:Envelope xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi=" http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <ns1:sayHelloTo xmlns:ns1="Hello" SOAP-ENV:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding/"> <name xsi:type="xsd:string">Tarak</name> </ns1:sayHelloTo> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Listing 10代表的SOAP請(qǐng)求與Listing 4的請(qǐng)求基本相同，但Listing 10的開頭加入了一些HTTP特有的代碼。第一行代碼表明這是一個(gè)遵循HTTP 1.1規(guī)范的POST請(qǐng)求，POST的目標(biāo)是http://www.SmartHello.com/HelloApplication。下一行指示內(nèi)容的類型，在HTTP消息中包含SOAP實(shí)體時(shí)，內(nèi)容類型必須是text/xml。Content-Length指明了POST請(qǐng)求有效載荷的長(zhǎng)度。

第四行是SOAP特有的，而且它是必不可少的。SOAPAction HTTP請(qǐng)求頭指明了SOAP HTTP請(qǐng)求的目標(biāo)，它的值是一個(gè)標(biāo)識(shí)目標(biāo)的URI。SOAP不對(duì)該URI的格式作任何限制，實(shí)際上，這個(gè)URI甚至不必對(duì)應(yīng)某個(gè)實(shí)際的位置。

SOAPAction的一個(gè)可能的應(yīng)用是，防火墻檢查該請(qǐng)求頭的值，決定是否允許請(qǐng)求通過防火墻。

一旦服務(wù)器處理完請(qǐng)求，它將向客戶返回一個(gè)應(yīng)答。應(yīng)答的內(nèi)容如Listing 11所示（假設(shè)沒有出現(xiàn)錯(cuò)誤）：

Listing 11 HTTP/1.0 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: 615 <SOAP-ENV:Envelope xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi=" http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:sayHelloToResponse xmlns:ns1="Hello" SOAP-ENV:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding/"> <return xsi:type="xsd:string">Hello John, How are you doing?</return> </ns1:sayHelloToResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

這個(gè)SOAP應(yīng)答與Listing 5所顯示的一樣，但前面加上了一些HTTP特有的代碼。由于沒有出現(xiàn)錯(cuò)誤，第一行代碼顯示應(yīng)答狀態(tài)是200。在HTTP協(xié)議中，200應(yīng)答狀態(tài)代碼表示“一切正常”。如果在處理SOAP消息（Header區(qū)或者Body區(qū)）的時(shí)候出現(xiàn)了任何錯(cuò)誤，則返回的狀態(tài)代碼將是500。在HTTP中，500狀態(tài)代碼表示“internal server error”。此時(shí)，上述SOAP應(yīng)答的第一行代碼將是：

HTTP 500 Internal Server Error

四、HTTP擴(kuò)充框架
許多應(yīng)用對(duì)服務(wù)的需求超過了傳統(tǒng)HTTP提供的服務(wù)。其結(jié)果就是，這類應(yīng)用擴(kuò)充了傳統(tǒng)的HTTP協(xié)議。然而，這種擴(kuò)充是應(yīng)用本身私有的。HTTP擴(kuò)充框架試圖確立一個(gè)通用的HTTP擴(kuò)充機(jī)制，從而解決這個(gè)問題。HTTP擴(kuò)充框架的擴(kuò)充之一是增加了一個(gè)M-POST方法，其中的M表示Mandatory（必須遵循的，強(qiáng)制的）。如果一個(gè)HTTP請(qǐng)求包含至少一個(gè)強(qiáng)制的擴(kuò)充聲明，那么這個(gè)請(qǐng)求就稱為強(qiáng)制的請(qǐng)求。引入強(qiáng)制的擴(kuò)充聲明通過Man或者C-Man頭進(jìn)行。強(qiáng)制請(qǐng)求的請(qǐng)求方法名字必須帶有“M-”前綴，例如，強(qiáng)制的POST方法稱為M-POST。

SOAP 1.0要求客戶程序首先發(fā)送一個(gè)HTTP POST請(qǐng)求，只有當(dāng)服務(wù)器返回錯(cuò)誤510時(shí)才發(fā)送M-POST請(qǐng)求。SOAP 1.1不再對(duì)客戶作這種限制，也就是說，SOAP 1.1允許客戶從發(fā)送任何一種類型的請(qǐng)求開始。下面的請(qǐng)求就是迄今為止我們一直在討論的那個(gè)請(qǐng)求，但它現(xiàn)在是M-POST格式：

Listing 12 M-POST http://www.SmartHello.com/HelloApplication HTTP/1.1 Content-Type: text/xml; charset="utf-8" Content-Length: 587 Man: "http://schemas.xmlsoap.org/soap/envelope/"; ns=01 01-SOAPAction: "http://www.SmartHello.com/HelloApplication#sayHelloTo" <SOAP-ENV:Envelope xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi=" http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <ns1:sayHelloTo xmlns:ns1="Hello" SOAP-ENV:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding/"> <name xsi:type="xsd:string">Tarak</name> </ns1:sayHelloTo> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

對(duì)于實(shí)際的SOAP消息來說，Listing 12和Listing 10沒有什么不同。但請(qǐng)求頭中有一些不同的地方，例如，現(xiàn)在我們發(fā)出的不是POST請(qǐng)求，而是一個(gè)M-POST請(qǐng)求。正如前面所介紹的，象M-POST這樣的強(qiáng)制請(qǐng)求至少有一個(gè)強(qiáng)制擴(kuò)充聲明。這里我們就有一個(gè)：Man域描述了一個(gè)強(qiáng)制性的端到端擴(kuò)充聲明，把頭前綴01映射到了名稱空間http://schemas.xmlsoap.org/soap/envelope/。請(qǐng)注意這個(gè)前綴關(guān)聯(lián)到SOAPAction域的方式。

一旦服務(wù)器處理完該請(qǐng)求，它將返回一個(gè)應(yīng)答給客戶。應(yīng)答內(nèi)容類如（假設(shè)沒有出現(xiàn)錯(cuò)誤）：

Listing 13 HTTP/1.0 200 OK Ext: Content-Type: text/xml; charset="utf-8" Content-Length: 615 <SOAP-ENV:Envelope xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi=" http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:sayHelloToResponse xmlns:ns1="Hello" SOAP-ENV:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding/"> <return xsi:type="xsd:string">Hello John, How are you doing?</return> </ns1:sayHelloToResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

同樣地，Listing 13顯示的應(yīng)答類似于對(duì)普通POST請(qǐng)求的應(yīng)答（如Listing 11所示），兩者的不同之處在于Ext域。

在通過HTTP使用SOAP的過程中，我們欣喜地看到，實(shí)際的SOAP消息（SOAP信封和它里面的所有內(nèi)容）總是保持不變，就如消息尚未加載HTTP協(xié)議時(shí)一樣。根據(jù)這一事實(shí)可以推斷出，HTTP不是能夠與SOAP協(xié)作的唯一協(xié)議。例如，SOAP可以方便地和SMTP協(xié)議或者其他定制的私有協(xié)議一起運(yùn)行。唯一的要求是兩者——客戶端和服務(wù)器端——都理解該協(xié)議。

五、SOAP的特點(diǎn)：簡(jiǎn)單
至此為止，我們討論了SOAP定義的方方面面，但有許多領(lǐng)域的問題SOAP沒有定義。SOAP規(guī)范的創(chuàng)立者明確地排除了一些關(guān)系密切的領(lǐng)域，比如構(gòu)造對(duì)象模型，還有其他許多已經(jīng)確立的標(biāo)準(zhǔn)。

造成這種現(xiàn)象的原因可以從分析SOAP的目標(biāo)理解。SOAP的目標(biāo)除了擴(kuò)展性之外，另一個(gè)主要的設(shè)計(jì)目標(biāo)是簡(jiǎn)單。為了保持SOAP簡(jiǎn)單，SOAP規(guī)范的創(chuàng)立者決定，只定義那些對(duì)于創(chuàng)建一個(gè)輕型協(xié)議來說絕對(duì)必須的東西。例如，SOAP沒有定義/指定任何有關(guān)分布式垃圾收集、類型安全或版本控制、雙向HTTP通信、消息盒（Message-box）運(yùn)輸或管道處理、對(duì)象激活等方面的內(nèi)容。SOAP的目標(biāo)就是成為一種簡(jiǎn)單的協(xié)議——一種在任何操作系統(tǒng)上，單個(gè)開發(fā)者能夠用任何語(yǔ)言化數(shù)天時(shí)間實(shí)現(xiàn)的協(xié)議。考慮到這一點(diǎn)，SOAP在許多方面沒有作出明確定義實(shí)際上是一件好事，因?yàn)樵跇?gòu)造分布式系統(tǒng)時(shí)，所有現(xiàn)有的技術(shù)都可以方便地采用SOAP，即使不同技術(shù)之間的差異象CORBA和DCOM的差異那樣明顯。

■ 結(jié)束語(yǔ)
在這篇文章中，我介紹了SOAP的一些基本概念，以及它之所以如此設(shè)計(jì)的一些原因。然而，相對(duì)于SOAP這座冰山來說，這只是它的一角。要查看有關(guān)SOAP的更多信息，請(qǐng)查閱參考資源部分給出的SOAP規(guī)范鏈接。隨著本系列文章的展開，我將在這里介紹有關(guān)SOAP規(guī)范所有你必須了解的知識(shí)。

在第二部分中，我將介紹Apache的SOAP實(shí)現(xiàn)。我們將使用該實(shí)現(xiàn)，創(chuàng)建一個(gè)利用SOAP作為有線協(xié)議的簡(jiǎn)單分布式應(yīng)用