許多開發者都遇到過這樣的情形：一個CORBA客戶程序需要獲得分布式組件對象模型（DCOM）客戶程序的服務，或者相反。常見的解決方案是使用一個COM/CORBA橋。然而，這種解決方案存在許多問題。假設在兩個已經很復雜的系統之間（CORBA ORB和COM之間）引入了一個新的軟件，在CORBA的Internet Inter-ORB Protocol（IIOP）到DCOM的Object Remote Procedure Call（ORPC）之間，繁雜的雙向轉換將使得中間起橋接作用的軟件變得很復雜。任何對IIOP協議和ORPC協議的修改都導致修改橋接軟件。如果我說SOAP能夠緩解這個問題，你會怎么想呢？感興趣嗎？
SOAP的全稱是Simple Object Access Protocol，即簡單對象訪問協議。簡單地說，SOAP是一種有線協議，類似于CORBA的IIOP、DCOM的ORPC或Java遠程方法調用的Java遠程方法協議（Java Remote Method Protocol，JRMP）。你也許會懷疑，既然已經有了那么多有線協議，為什么我們還需要另外一種？事實上，這不正好導致前面所討論的問題嗎？這些問題都有道理，但是，SOAP和其他有線協議有所不同。
我們來分析一下：
- IIOP、ORPC和JRMP都是二進制協議，而SOAP則是一種使用XML的以文本為基礎的協議。利用XML進行數據編碼為SOAP帶來一些獨一無二的功能。例如，調試以SOAP為基礎的應用程序更容易，因為閱讀XML要比閱讀二進制數據容易得多。另外，由于所有的SOAP消息都是文本格式，和IIOP、ORPC或者JRMP相比，SOAP更容易和防火墻協作。
- SOAP協議以非供應商私有的協議為基礎，即XML、HTTP和Simple Mail Transfer Protocol（SMTP），所有供應商都可以使用SOAP協議。例如，Microsoft和各個CORBA ORB供應商（例如Iona）一樣，已經承諾支持SOAP。IBM在創建SOAP協議的過程中起到了重要的作用，它也為Java程序員創建了一個優秀的SOAP工具包。該公司已經把工具包捐贈給Apache Software Foundation的XML Project，后者以該軟件包為基礎，構造出了Apache-SOAP實現。這個實現在Apache許可之下免費提供給用戶。再返回來看本文開頭提出的問題，如果DCOM使用SOAP，ORB供應商也使用了SOAP，那么，COM/CORBA協同操作中出現的問題將變得不值一提。
SOAP決不只是一個漂亮的口號，它是一種即將深入滲透到未來分布式計算的技術。人們希望，SOAP結合其他技術，比如UDDI（Universal Discovery Description, and Integration）和WSDL（Web Services Description Language），在Web服務這一概念的支持下，改變未來商業應用跨越Web進行通信的方法。我甚至無法充分地表達出在開發者的工具包中加上SOAP知識的重要程度。這是一個關于SOAP的系列文章，總共四篇。這是第一篇，介紹一些基礎知識。我們將從SOAP這一思想的構思說起。
一、SOAP簡介
如前所述，SOAP用XML作為數據編碼格式。用XML作為數據編碼格式并非SOAP的原創，實際上這是一種相當自然的選擇。XML-RPC和ebXML也同樣使用XML。要了解這方面的更多信息，請參見本文最后的“參考資源”。
請考慮下面的Java接口：
Listing 1
public interface Hello
{
public String sayHelloTo(String name);
} |
客戶程序在調用sayHelloTo()方法時提供了一個名字，它希望從服務器接收到一則個性化的“Hello”信息。現在，假定RMI、CORBA和DCOM都不存在，開發者必須負責串行化方法調用，并把消息發送給遠程機器。幾乎所有的人都會說“這該使用XML”，我同意。因此，讓我們先從對服務器的請求格式開始。假設要模擬sayHelloTo("John")調用，我打算發送的請求是：
Listing 2
<?xml version="1.0"?>
<Hello>
<sayHelloTo>
<name>John</name>
</sayHelloTo>
</Hello> |
在這里，我把接口的名字作為根結點。另外，我還把方法名字和參數名字都當作節點。接下來，我們要把這個請求發送給服務器。我們不創建自己的TCP/IP消息，而是使用HTTP。因此，下面的步驟應該是把請求封裝成HTTP POST請求格式，然后把它發送給服務器。實際創建該HTTP POST請求的詳細過程在本文后面介紹，現在，我們先假定它已經創建完畢。服務器接收到了這個請求，解碼XML，然后再以XML格式向客戶程序發送應答。假設應答內容如下：
Listing 3
<?xml version="1.0"?>
<Hello>
<sayHelloToResponse>
<message>Hello John, How are you?</message>
</sayHelloToResponse>
</Hello> |
根節點仍然是接口的名字Hello。但這一次，原來對應著方法的節點名字不再是sayHelloTo，而是方法的名字加上“Response”字符串。客戶程序知道自己調用了哪一個方法，要找出被調用方法的返回值，它只需查看名字為方法名字加上“Response”字符串的元素。
以上就是SOAP的根本思路。Listing 4顯示了同一請求用SOAP XML編碼之后的結果：
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> |
看起來稍微復雜了一點，對吧？實際上，它和我們前面編寫的請求類似，只是略微擴展了一些東西。首先，注意SOAP文檔通過一個Envelope（根節點）、一個Header區、一個Body區，整潔地組織到一起。Header區用來封裝那些與方法本身無直接關系的數據，提供環境方面的信息，比如事務ID和安全信息。Body區包含面向方法本身的信息。在Listing 2中，我們自己編寫的XML只包含一個Body區。
第二，注意Listing 4大量地應用了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文檔都擁有的標準名稱空間。
最后，在Listing 4中，接口名稱（即Hello）不再象在Listing 2中那樣成為節點的名字；相反，它引用了一個名稱空間nsl。另外，參數的類型信息也隨同參數的值一起發送給了服務器。注意信封（Envelope）encodingStyle屬性的值。這個屬性值設置成了http://schemas.xmlsoap.org/soap/encoding/。這個值告訴服務器用來編碼（即串行化）方法的編碼方式；服務器需要這個信息，以便正確地解除方法的串行化。對于服務器來說，SOAP文檔的自我描述能力是相當完善的。
對于上面的SOAP請求，服務器的應答如下：
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的請求消息類似。在上面的代碼中，返回值（即個性化的“Hello”消息）包含在Body區。SOAP消息文檔的格式非常靈活。例如，編碼方式不固定，而是由客戶程序指定。只要是客戶程序和服務器都認可的編碼方式，可以是任何合法的XML文檔。
另外，分離調用環境信息意味著方法本身并不關心這類信息。在當前的市場上，主流應用服務器都遵從這一理念。早先，我曾經指出環境信息可以包含事務和安全方面的信息。事實上，環境可以涵蓋幾乎所有的東西。下面是一個SOAP消息頭的例子，它帶有一些事務方面的信息：
Listing 6
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header> |
名稱空間t映射到了與特定應用有關的URI。這里的5表示的是該方法從屬于其中的事務ID。注意SOAP信封mustUnderstand屬性的應用。這個屬性被設置成了1，它表示服務器要么理解并按照要求處理該事務請求，要么表示無法處理該請求；這是SOAP規范所要求的。
二、錯誤處理
使用SOAP并不意味著任何時候所有的請求都會獲得成功。許多地方可能會出現差錯。例如，服務器可能無法訪問某個關鍵性的資源（比如數據庫），因而無法順利地處理請求。
讓我們返回“Hello”實例，為它加上一個假想的約束，即“在星期二向別人說Hello不合法。”因此，星期二的時候，即使發送給服務器的請求是合法的，服務器也會把一個錯誤信息返回給客戶端。應答內容將如下所示：
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服務器必須始終通過該元素報告所有錯誤情況。Fault元素必須包含faultcode和faultstring元素，不能有例外。faultcode是一個能夠標識問題的代碼；客戶程序按照SOAP規范的要求利用faultcode進行算法處理。SOAP規范定義了一小組錯誤代碼供用戶使用。另一方面，faultstring是供人類閱讀的錯誤信息。
Listing 7的代碼還包含了一個detail元素。由于錯誤在處理SOAP消息的Body區時出現，detail元素必須出現。正如你將在本文后面看到的，如果錯誤在處理Header區時出現，detail元素不應出現。在Listing 7中，應用利用detail元素提供當前錯誤更詳細、更自然的解釋，即星期二不允許說Hello。SOAP還提供另外一個面向具體應用的錯誤代碼，即半可選的faultfactor元素，但上面的錯誤信息中沒有顯示這個元素。之所以稱這個元素是半可選的，是因為如果錯誤消息不是由請求最終處理點的服務器發送，即由一個中間服務器發送，則錯誤消息必須包含該元素。SOAP對faultcode元素不應出現的情形沒有作任何規定。
在Listing 7中，錯誤起源于方法調用本身，處理該方法的應用導致了這個錯誤。現在，我們來看一下另一種類型的錯誤，這種錯誤由于服務器不能處理請求頭信息而導致。舉例來說，假設所有的Hello消息必須在一個事務環境之內生成，則請求類似于：
| 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區包含一個transaction元素，它指定了方法調用必須從屬于其中的事務編號。這里我說“必須”是因為transaction元素使用了mustUnderstand屬性。如前所述，SOAP服務器要么遵照屬性的指示處理請求，要么聲明不能處理請求。假定SOAP服務器不能處理，它必須返回一個錯誤信息。這時的應答應該類似于：
| 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顯示的錯誤信息。但應該注意的是，detail元素不再出現。正如我在前面指出的：SOAP規范規定，如果錯誤在處理Header區的時候出現，則錯誤消息中不應包含detail元素。事實上，我們可以根據detail元素是否出現，迅速判定錯誤是在處理Body區還是在處理Header區時出現。
三、SOAP與HTTP
在第一個例子中，我通過HTTP把定制的XML請求發送給服務器，但沒有詳細介紹這么做涉及到了哪些操作。現在我們回過頭來看那個問題。怎樣才能把一個SOAP請求（而不是定制的XML）通過HTTP發送給服務器？SOAP很自然地遵循了HTTP的請求/應答消息模型。這個模型在HTTP請求中提供SOAP請求參數，在HTTP應答中提供SOAP應答參數。實際上，SOAP 1.0特別指明HTTP作為它的傳輸協議。SOAP 1.1略有放松。雖然SOAP 1.1仍舊可以使用HTTP，但它也可以使用其他協議，比如SMTP。在這個系列的文章中，我只討論通過HTTP使用SOAP的情形。
讓我們返回Hello示例。如果我們通過HTTP把SOAP請求發送給服務器，則代碼應該類似于：
| 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請求與Listing 4的請求基本相同，但Listing 10的開頭加入了一些HTTP特有的代碼。第一行代碼表明這是一個遵循HTTP 1.1規范的POST請求，POST的目標是http://www.SmartHello.com/HelloApplication。下一行指示內容的類型，在HTTP消息中包含SOAP實體時，內容類型必須是text/xml。Content-Length指明了POST請求有效載荷的長度。
第四行是SOAP特有的，而且它是必不可少的。SOAPAction HTTP請求頭指明了SOAP HTTP請求的目標，它的值是一個標識目標的URI。SOAP不對該URI的格式作任何限制，實際上，這個URI甚至不必對應某個實際的位置。
SOAPAction的一個可能的應用是，
防火墻檢查該請求頭的值，決定是否允許請求通過
防火墻。
一旦服務器處理完請求，它將向客戶返回一個應答。應答的內容如Listing 11所示（假設沒有出現錯誤）：
| 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>
|
這個SOAP應答與Listing 5所顯示的一樣，但前面加上了一些HTTP特有的代碼。由于沒有出現錯誤，第一行代碼顯示應答狀態是200。在HTTP協議中，200應答狀態代碼表示“一切正常”。如果在處理SOAP消息（Header區或者Body區）的時候出現了任何錯誤，則返回的狀態代碼將是500。在HTTP中，500狀態代碼表示“internal server error”。此時，上述SOAP應答的第一行代碼將是：
| HTTP 500 Internal Server Error |
四、HTTP擴充框架
許多應用對服務的需求超過了傳統HTTP提供的服務。其結果就是，這類應用擴充了傳統的HTTP協議。然而，這種擴充是應用本身私有的。HTTP擴充框架試圖確立一個通用的HTTP擴充機制，從而解決這個問題。HTTP擴充框架的擴充之一是增加了一個M-POST方法，其中的M表示Mandatory（必須遵循的，強制的）。如果一個HTTP請求包含至少一個強制的擴充聲明，那么這個請求就稱為強制的請求。引入強制的擴充聲明通過Man或者C-Man頭進行。強制請求的請求方法名字必須帶有“M-”前綴，例如，強制的POST方法稱為M-POST。
SOAP 1.0要求客戶程序首先發送一個HTTP POST請求，只有當服務器返回錯誤510時才發送M-POST請求。SOAP 1.1不再對客戶作這種限制，也就是說，SOAP 1.1允許客戶從發送任何一種類型的請求開始。下面的請求就是迄今為止我們一直在討論的那個請求，但它現在是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>
|
對于實際的SOAP消息來說，Listing 12和Listing 10沒有什么不同。但請求頭中有一些不同的地方，例如，現在我們發出的不是POST請求，而是一個M-POST請求。正如前面所介紹的，象M-POST這樣的強制請求至少有一個強制擴充聲明。這里我們就有一個：Man域描述了一個強制性的端到端擴充聲明，把頭前綴01映射到了名稱空間http://schemas.xmlsoap.org/soap/envelope/。請注意這個前綴關聯到SOAPAction域的方式。
一旦服務器處理完該請求，它將返回一個應答給客戶。應答內容類如（假設沒有出現錯誤）：
| 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顯示的應答類似于對普通POST請求的應答（如Listing 11所示），兩者的不同之處在于Ext域。
在通過HTTP使用SOAP的過程中，我們欣喜地看到，實際的SOAP消息（SOAP信封和它里面的所有內容）總是保持不變，就如消息尚未加載HTTP協議時一樣。根據這一事實可以推斷出，HTTP不是能夠與SOAP協作的唯一協議。例如，SOAP可以方便地和SMTP協議或者其他定制的私有協議一起運行。唯一的要求是兩者——客戶端和服務器端——都理解該協議。
五、SOAP的特點：簡單
至此為止，我們討論了SOAP定義的方方面面，但有許多領域的問題SOAP沒有定義。SOAP規范的創立者明確地排除了一些關系密切的領域，比如構造對象模型，還有其他許多已經確立的標準。
造成這種現象的原因可以從分析SOAP的目標理解。SOAP的目標除了擴展性之外，另一個主要的設計目標是簡單。為了保持SOAP簡單，SOAP規范的創立者決定，只定義那些對于創建一個輕型協議來說絕對必須的東西。例如，SOAP沒有定義/指定任何有關分布式垃圾收集、類型安全或版本控制、雙向HTTP通信、消息盒（Message-box）運輸或管道處理、對象激活等方面的內容。SOAP的目標就是成為一種簡單的協議——一種在任何操作系統上，單個開發者能夠用任何語言化數天時間實現的協議。考慮到這一點，SOAP在許多方面沒有作出明確定義實際上是一件好事，因為在構造分布式系統時，所有現有的技術都可以方便地采用SOAP，即使不同技術之間的差異象CORBA和DCOM的差異那樣明顯。
■ 結束語
在這篇文章中，我介紹了SOAP的一些基本概念，以及它之所以如此設計的一些原因。然而，相對于SOAP這座冰山來說，這只是它的一角。要查看有關SOAP的更多信息，請查閱參考資源部分給出的SOAP規范鏈接。隨著本系列文章的展開，我將在這里介紹有關SOAP規范所有你必須了解的知識。
在第二部分中，我將介紹Apache的SOAP實現。我們將使用該實現，創建一個利用SOAP作為有線協議的簡單分布式應用