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

<sayHelloToResponse>

<message>Hello John, How are you?</message>

</sayHelloToResponse>

根節點仍然是接口的名字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">

<ns1:sayHelloToResponse

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<return xsi:type="xsd:string">Hello John, How are you doing?</return>

</ns1:sayHelloToResponse>

Listing 5與Listing 4的請求消息類似。在上面的代碼中，傳回值（即個性化的“Hello”消息）包含在Body區。SOAP消息文檔的格式非常靈活。例如，編碼方式不固定，而是由客戶程式指定。隻要是客戶程式和伺服器都認可的編碼方式，可以是任何合法的XML文檔。

另外，分離調用環境資訊意味着方法本身并不關心這類資訊。在目前的市場上，主流應用伺服器都遵從這一理念。早先，我曾經指出環境資訊可以包含事務和安全方面的資訊。事實上，環境可以涵蓋幾乎所有的東西。下面是一個SOAP消息頭的例子，它帶有一些事務方面的資訊：

Listing 6

<t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">

5

</t:Transaction>

名稱空間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: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>

我們來分析一下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

xmlns:SOAP-ENV="

http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="

http://www.w3.org/1999/XMLSchema-instance"

<t:Transaction xmlns:t="some-URI"

SOAP-ENV:mustUnderstand="1">

<name xsi:type="xsd:string">Tarak</name>

上面消息的Header區包含一個transaction元素，它指定了方法調用必須從屬于其中的事務編号。這裡我說“必須”是因為transaction元素使用了mustUnderstand屬性。如前所述，SOAP伺服器要麼遵照屬性的訓示處理請求，要麼聲明不能處理請求。假定SOAP伺服器不能處理，它必須傳回一個錯誤資訊。這時的應答應該類似于：

Listing 9

<faultcode>SOAP-ENV:MustUnderstand</faultcode>

<faultstring>SOAP Must Understand

Error</faultstring>

上面的代碼類似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"

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-Length: 615

<return xsi:type="xsd:string">Hello John, How are

you doing?</return>

這個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

Man: "http://schemas.xmlsoap.org/soap/envelope/"; ns=01

01-SOAPAction: "http://www.SmartHello.com/HelloApplication#sayHelloTo"

對于實際的SOAP消息來說，Listing 12和Listing 10沒有什麼不同。但請求頭中有一些不同的地方，例如，現在我們發出的不是POST請求，而是一個M-POST請求。正如前面所介紹的，象M-POST這樣的強制請求至少有一個強制擴充聲明。這裡我們就有一個：Man域描述了一個強制性的端到端擴充聲明，把頭字首01映射到了名稱空間http://schemas.xmlsoap.org/soap/envelope/。請注意這個字首關聯到SOAPAction域的方式。

一旦伺服器處理完該請求，它将傳回一個應答給客戶。應答内容類如（假設沒有出現錯誤）：

Listing 13

Ext:

同樣地，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的差異那樣明顯。