您现在的位置：程式碼之家 >> 編程語言 > >> Java 程式設計 >> Java 程式設計入門

SOAP 協議深度解析：從 RPC 歷史演進到 XML 編碼實戰

編輯：Java 程式設計入門

引言：為什麼需要 SOAP？

在分散式運算演進歷程中，SOAP (Simple Object Access Protocol) 以「不發明任何新技術」為哲學，結合 HTTP 傳輸 與 XML 編碼，解決了 CORBA、DCOM 等傳統 ORPC 技術在防火牆穿透、跨平台互通、廠商綁定等方面的痛點。本文將從 RPC 歷史脈絡切入，深入剖析 SOAP 的架構設計、編碼規則與錯誤處理機制。

RPC 協定演進脈絡

從訊息傳遞到請求/回應

分散式應用的兩大通訊模型：

訊息傳遞：非同步、鬆散耦合，需顯式設計並行處理邏輯
請求/回應：同步阻塞，符合傳統程式呼叫慣例，自然適合 RPC

雖然兩者可互相實現，但 RPC 因設計簡單、映射自然，成為主流選擇。

早期 RPC：Sun RPC 與 DCE RPC

Sun RPC → NFS (Network File System) 廣泛用於 UNIX
DCE RPC → Windows NT 系統服務基石

兩者證實可用於大規模應用，但缺乏物件導向支援。

ORPC 時代：DCOM 與 CORBA IIOP/GIOP

90 年代物件導向浪潮催生 ORPC，核心差異在於：

引入 物件端點 ID 定位目標物件
方法識別符決定呼叫哪個方法
參數編碼：DCOM 用 NDR，CORBA 用 CDR，兩者不相容
物件參考傳遞：DCOM 用 OBJREF，CORBA 用 IOR

傳統 ORPC 的四大困境

廠商綁定：DCOM 綁定 Windows，CORBA 綁定特定 ORB 產品，跨廠商互通困難
環境依賴：需嚴格治理的網路環境，「開箱即用」幾率低
技術門檻高：複雜的資料排列、類型資訊、位元操作規則
網際網路不友善：防火牆/Proxy 封鎖非 HTTP 協定，通道技術脆弱且不互通

伺服器叢集內部問題較小（機器少、同管理域、直連 IP），但客戶端到伺服器的跨網際網路通訊極具挑戰。

HTTP：更好的 RPC 傳輸層

簡單、普及、防火牆友善（Port 80）
請求/回應模天然符合 RPC
文字基礎標頭，易除錯、易開發
IIS、Apache 等 Web Server 即可作為 SOAP ORB

HTTP 缺少統一的參數編碼格式，這正是 XML 的用武之地。

XML：中立、可擴展的網路資料表達

核心特性

平台中立、大量解析器支援
文字基礎，低技術門檻易處理
命名空間消除元素歧義
XML Schema 提供型別系統與擴充機制

範例：命名空間與型別標註

<sp:reverse_string 
    xmlns:sp="urn:schemas-develop-com:StringProcs"
    xmlns:doc="https://foo.com/documentation">
  <sp:string1>Hello, World</sp:string1>
  <doc:comment>This is a comment!!</doc:comment>
</sp:reverse_string>

<customer xmlns:xsd="https://www.w3.org/1999/XMLSchema">
  <name xsd:type="string">Don Box</name>
  <age xsd:type="float">23.5</age>
</customer>

SOAP 架構：HTTP + XML = SOAP

SOAP 訊息結構

POST /string_server/Object17 HTTP/1.1
Host: 209.110.197.2
Content-Type: text/xml
Content-Length: 152
SOAPMethodName: urn:strings-com:IString#reverse

<Envelope>
  <Body>
    <m:reverse xmlns:m="urn:strings-com:IString">
      <theString>Hello, World</theString>
    </m:reverse>
  </Body>
</Envelope>

SOAPMethodName 標頭：格式為 命名空間URI#方法名，功能等同 DCOM/CORBA 的介面 ID
Envelope/Body：標準包裝，Body 第一個子元素必須與 SOAPMethodName 對應
回應格式：方法名 + Response 後綴，無 SOAPMethodName 標頭

伺服器分派機制彈性

SOAP 不規定伺服器如何使用 Request-URI 分派請求：可映射到類別、單例物件、或透過 Cookie/查詢字串還原物件狀態。客戶端無需知曉細節，僅遵循 HTTP/XML 規則發送請求。

SOAP 編碼規則核心

請求/回應結構化

將方法參數打包為隱含結構：

請求結構：包含 [in]、[in,out] 參數
回應結構：包含 [out]、[in,out] 參數
序列化風格：元素正規格式 (ENF)，每個欄位對應一個子元素

SOAP 資料型別體系

型別	說明
結構元素	Envelope、Header、Body 三大核心
根元素	Body/Header 直屬子元素，代表呼叫/回應/錯誤物件
存取元素	表達欄位/屬性，單引用（內嵌值）或多引用（href 指向獨立元素）
獨立元素	被多引用存取元素指向，帶 soap:id，置於 Header/Body 或 Package=true 元素下

關鍵機制

多引用與身分保持：透過 soap:href + soap:id 保持物件參考身分
空值處理：xsd:null="true" 標註
型別替換：xsd:type 指定實際執行個體型別
陣列編碼：支援多維、部分傳輸、稀疏陣列（soap:offset、soap:position）

錯誤處理：Fault 元素

<soap:Fault>
  <faultcode>200</faultcode>
  <faultstring>Unrecognized 'causality' header</faultstring>
  <runcode>No</runcode>
</soap:Fault>

faultcode：標準碼或應用定義 QName
faultstring：人類可讀描述
runcode：Yes/No/Maybe，指示操作是否已執行
detail：應用層例外物件

HTTP 擴充框架與 M-POST

SOAP 可選擇性支援 HTTP Extension Framework，將 SOAPMethodName 定義為強制標頭：

M-POST /foobar HTTP/1.1
Man: "urn:schemas-xmlsoap-org:soap.v1; ns=42"
42-SOAPMethodName: urn:bobnsid:IFoo#DoIt

未識別 SOAP 的伺服器必須回傳 501 或 510 錯誤。

結語

SOAP 是一個「剛好使用 HTTP 作傳輸」的型別化序列化格式，緊密配合 XML Schema，實現 COM、CORBA、Java、Perl、Python、PHP 等跨平台互通。建議開發者實驗 SOAP，或使用現成的 SOAP 啟用系統（如 DevelopMentor 列表）。以腳本語言建立基本 Client/Server 往往不超過一小時，視 HTTP/XML 熟悉度與平台成熟度而定。