淺談 SOAP

http://www.ibm.com/developerworks/tw/library/x-sisoap/

級別: 入門

段智華

2001 年 8 月 01 日

本文對 SOAP 作了一個初步介紹，示範幾個簡單範例；接著比較 CORBA，DCOM/COM 與 SOAP 的連絡與區別；然後簡單起分析 SOAP 簡單的理解為 RPC+HTTP+XML 時的執行機制；最後展現 SOAP 的前景。

一︰為什麼需要 SOAP？

隨著電腦技術的不斷發展，現代企業面臨的環境越來越複雜，其訊息系統大多數為多平台、多系統的複雜系統。這就要求今天的企業解決方案具有廣泛的相容能力， 可以支援不同的系統平台、資料格式和多種連線方式，要求在Internet 環境下，實作系統是鬆散耦合的、跨平台的，與語言無關的，與特定介面無關的，而且要提供對Web 應用程式的可靠存取。

隨 著異種計算環境的不斷增加，各種系統間的互通性就愈顯得必要，要求系統能夠緊密地進行通信和共享資料，從而在 Internet 環境下，消除巨大的訊息孤島，實作訊息共享、進行資料交換，達到訊息的一致性。Web services 希望實作不同的系統之間能夠用"軟體-軟體對話"的方式相互呼叫，打破了軟體應用、網站和各種設備之間的格格不入的狀態，實作"基於WEB緊密整合"的目 標。

今年四月份的時候，W3C聯盟召開了第一次 Web 服務專題研討會，目的為探索 W3C 應向哪個方向發展才能實作新興的 Web 服務架構的標準化，期間提出了一個"Web 服務架構"的構想，如下圖，從圖中可以看出，SOAP在WEB服務架構中作為用於 XML 訊息傳遞的一種非常普遍的協定，發揮著十分重要的作用。

回到頂端

二︰什麼是SOAP？

SOAP（Simple Object Access Protocol ）簡單物件存取協定是在分散或分散式的環境中交換訊息的簡單的協定，是一個基於XML的協定，它包括四個部分︰SOAP Envelop，Envelop定義了一個描述訊息中的內容是什麼，是誰傳送的，誰應當接受並處理它以及如何處理它們的框架；SOAP編碼規則 （encoding rules），用於表示應用程式需要使用的資料類型的實體; SOAP RPC表示(RPC representation)，表示遠端過程呼叫和回應的協定；SOAP繫結（binding），使用底層協定交換訊息。

雖然這四個部分都作為SOAP的一部分，作為一個整體定義的，但他們在功能上是相交的、彼此獨立的。特別的，信封和編碼規則是被定義在不同的XML命名空間(namespace)中，這樣使得定義更加簡單。

SOAP 的兩個主要設計目標是簡單性和可擴充性。這就意味著有一些傳統訊息系統或分散式物件系統中的某些性質將不是SOAP規範的一部分。比如︰分散式垃圾收集 (Distributed garbage collection)、批次傳送訊息(Boxcarring or batching of messages)、物件參照 (Objects-by-reference（which requires distributed garbage collection）)、物件啟動 (Activation（which requires objects-by-reference）)。

SOAP訊息舉例︰

1．第一個例子闡明了SOAP中一個簡單的通信訊息，包括了兩個不是SOAP定義而是應用程式定義的元素︰標頭區塊元素alertcontrol 和主體區塊元素alert。標頭區塊元素包括兩個參數︰priority 和expires。主體區塊元素包括的是實際傳送的訊息。

Example 1

2． SOAP通信與底層的不同協定和不同的交換格式有關，下面的例子SOAP使用HTTP作為底層通信協定，從而可以很好的使用 request/response機制來傳送訊息。 SOAP/HTTP請求包括一個GetLastTradePrice的區塊元素，該請求攜帶一個字串參數和ticker符號，在SOAP回應中傳回一個浮 點數。XML命名空間欄位用來區分SOAP標誌字元和應用程式特定的標誌字元。

Example 2

3. 例3 展示的是StockQuote SOAP服務訊息，是對例2的請求作出的一條回應訊息。

Example 3

回到頂端

三︰SOAP 與 CORBA，COM/DCOM 的區別？

在SOAP剛剛提出來的時候，許多人就提出了疑問︰SOAP與CORBA和DCOM的區別何在？

1. CORBA（Common Object Request Broker
   Architecture）公用物件請求代理架構是由OMG組織制訂的一種標準的物件導向應用程式體系規範。由物件請求代理ORB、物件服務、公用設施、 網域介面和應用介面這幾個部分群組成。其核心部分是物件請求代理ORB（Object Request Broker）。ORB提供了一種機制，透過這種機制，物件可以透明的發出請求和接收回應。分布的、可以互操作的物件可以利用ORB建立可以互操作的應 用。ORB可看作是在物件之間建立客戶/服務關係的一種中介軟體。基於ORB，客戶可以透明的呼叫服務物件提供的方法，該服務物件可以與客戶執行在同一台 機器上，也可以執行在其它機器上透過網路與客戶進行交互。ORB截取客戶傳送的請求，並負責在該軟體匯流排上找到實作該請求的服務物件，然後完成參數、方 法呼叫，並傳回最終結果。CORBA 1.1 由物件管理組織在 1991 年發佈。定義了介面定義語言（IDL）和應用程式介面（API），從而透過實作物件請求代理（ORB）來啟動客戶/伺服器的交互。CORBA 2.0 於 1994 年的 12 月發佈定義了如何跨越不同的 ORB 提供者而進行通訊。
2. COM/DCOM(Component Object Model / Distributed Component Object
   Model )是微軟公司提出的分散式元件物件模型標準，支援在區域網路、廣網域網甚至Internet上不同電腦的物件之間的通訊。DCOM基於COM的應用程式、 元件、工具等的基礎之上，處理網路協定的低層次的細節問題，而不必關心太多的網路協定細節，從而使使用者能夠集中精力解決使用者所要求的問題。DCOM位 於應用程式的元件之間，將元件以不可見的方式膠合在一起組成具有完整功能的應用程式。
3. SOAP 與CORBA，DCOM/COM的比較。
   

   3.1 首先指出的是SOAP不會取代CORBA，COM/DCOM，三者的概念有所區別。COM/DCOM是個元件模型標準，CORBA是分散式應用的服務標 準。CORBA和DCOM為分散式應用程式建立服務，服務物件來執行客戶端呼叫的服務。而SOAP是基於XML和HTTP的分散式物件的通信協定，是 COM/DCOM和CORBA物件進行通訊的協定。實際上，利用SOAP的互通性和CORBA強大的執行能力，兩者可以很好的結合在一起。 OMG （Object Management Group responsible for the CORBA specification）正在關注這方面的發展。

   3.2. CORBA應用程式和DCOM應用程式不能實作互操作，兩者不能在一起協同合作。因為在ORPC(Object RPC)協定中，用ObjRef代表了一個正在執行物件的參照；在CORBA/IIOP(Internet Inter-Orb Protocol)中，用交換可互操作物件參照IOR（Interoperable Object Reference）代表一個伺服器的物件參照。不幸的是，IOR 與 ObjRef不能夠關聯起來。然而，使用SOAP可以實作在垂直應用層面上CORBA ，DCOM技術的水平整合，能夠更好的整合CORBA，DCOM為一個整體。

   3.3 SOAP並沒有定義訊息的語義，服務品質，基於INTERNET的交易處理。而是採用 XML 進行訊息編碼，正確的處理需要伺服器和客戶端本身來執行，理解和執行彼此使用的訊息格式（ONE-TO-ONE，REQUEST/REPLY， BROADCAST，ETC），應用程式本身在語義解析中扮演著十分重要的角色。而CORBA，DCOM表示了傳送訊息的語義，對參數和傳回值使用二進位 編碼。可對諸如參數名稱或類型的任何元訊息都不編碼，但使中介很難處理訊息。又因為每個系統使用不同的二進位編碼，系統間的互操作的很難實作。

   3.4 儘管CORBA可以在不同的平臺上執行，DCOM可以在微軟的各種平臺上執行，但是基於CORBA和DCOM的解決方案必須依賴於單一的應用程式。比如 說，假如執行的是DCOM伺服器程式，所有的分散式的客戶端不得不執行於微軟的作業平臺上。CORBA 雖然可以執行於不同的平台，但CORBA的互通性並沒有在更高層的服務上進行擴充，如安全性和交易處理，在這種情況下，許多提供的服務沒有得到很好的最佳 化。DCOM和CORBA適合於伺服器--伺服器間的通訊，但是對於客戶端--伺服器的通訊十分脆弱，尤其當客戶程式分布在INTERNET上更是如此。

   3.5 SOAP不像DCOM一樣試圖定義分散式系統的所有元素，SOAP沒有提供分散式類別庫，類型安全檢查，版本控制等等，SOAP比它處於一個更低的層次， 有點類似於IIOP在CORBA的作用，DCOM卻提供了一些額外的協定功能，是IIOP 或者SOAP所不具備的。然而，許多. DCOM的額外功能只有在伺服器__伺服器間通信時才會用到，對於客戶端__伺服器之間的通信則是多餘的。

回到頂端

四︰SOAP=RPC+HTTP+XML

SOAP簡單的理解，就是這樣的一個開放協定SOAP=RPC+HTTP+XML︰採用HTTP作為底層通訊協定；RPC作為一致性的呼叫途徑，ＸＭＬ作 為資料傳送的格式，容許服務提供者和服務客戶經過防火牆在INTERNET進行通訊交互。RPC的描敘可能不大準確，因為SOAP一開始構思就是要實作平 台與環境的無關性和獨立性，每一個透過網路的遠端呼叫都可以透過SOAP Envelop起來，包括DCE（Distributed Computing Environment ）　RPC CALLS，COM/DCOM CALLS, CORBA CALLS, JAVA CALLS，etc。

SOAP 使用 HTTP 傳送 XML，儘管HTTP 不是有效率的通訊協定，而且 XML 還需要額外的文件解析（parse），兩者使得交易的速度大大低於其它方案。但是XML 是一個開放、健全、有語義的訊息機制，而 HTTP 是一個廣泛又能避免許多關於防火牆的問題，從而使SOAP得到了廣泛的應用。但是如果效率對你來說很重要，那麼你應該多考慮其它的方式，而不要用 SOAP。

為了更好的理解SOAP,HTTP,XML如何工作的，不妨先考慮一下COM/DCOM的執行機制，DCOM處理網路 協定的低層次的細節問題，如PROXY/STUB間的通訊，生命週期的管理，物件的識別。在客戶端與伺服器端進行交互的時候，DCOM採用NDR （Network Data Representation）作為資料表示，它是低層次的與平台無關的資料表現形式。

DCOM是 有效的，靈活的，但也是很複雜的。而SOAP的一個主要優點就在於它的簡單性，SOAP使用HTTP作為網路通訊協定，接受和傳送資料參數時採用XML作 為資料格式，從而代替了DCOM中的NDR格式，SOAP和 DCOM執行過程是類似的，如下圖，但是用XML取代 NDR作為編碼表現形式，提供了更高層次上的抽象，與平台和環境無關。

Figure 5

客戶端傳送請求時，不管客戶端是什麼平台的，首先把請求轉換成XML格式，SOAP閘道可自動執行這個轉換。為了保證傳送時參數，方法名，傳回值的唯一性，SOAP協定使用了一個私有標籤表，從而服務端的SOAP閘道可以正確的解析，這有點類似於COM/DCOM

中 的STUB。轉化成XML格式後，SOAP終端設備名（遠端呼叫方法名）及其它的一些協定識別訊息被封裝成HTTP請求，然後傳送給伺服器。如果應用程式 要求，伺服器傳回一個HTTP回應訊息給客戶端。與通常對HTML頁面的HTTP GET請求不同的是，此請求設定了一些HTTP HEADER，識別著一個SOAP服務活動，和HTTP套件一起傳送。例如︰對於一個詢問股票價格的應用程式，伺服器端具有元件提供某股票目前的價格，元 件是COM或CORBA在伺服器上建立的。客戶端傳送一個SOAP請求給伺服器詢問股票價格。伺服器依賴於伺服器上的SOAP閘道，使用內嵌的HTML物 件呼叫合適的方法， 然後把得到的價格透過SOAP回應傳給客戶端。

回到頂端

五．SOAP 的前景

W3C於2000年5月8日發表了Simple Object Access Protocol (SOAP) 1.1版本，具體規範發佈在下列網站上（ http://www.w3.org/TR/SOAP/ ）。又與今年7月9號推出了SOAP Version 1.2版本的建議草案，具體規範發佈在下列網站上（ http://www.w3.org/TR/soap12/ ）。編寫SOAP Version 1.1版本的工作小組的成員包括︰ DevelopMentor, International Business Machines Corporation, Lotus Development Corporation, Microsoft, UserLand Software 。

SOAP 的推出是令人興奮的。可以相信，隨著網路服務的的不斷發展，它將極大的改變我們的思考模式和開發模式。現在，已有許多大公司著手支援SOAP的開發，去年 IBM公司 和 Microsoft公司 都發行了實作 SOAP 的第一批版本。 IBM 公司啟動了Apache SOAP 專案計劃，微軟最近又推出了SOAPtoolkit2.0的正式版，主要包括如下的一些特性︰SOAP的高層介面和低層介面，訊息物件介面，完全支援 WSDL 1.1標準，支援使用者自訂類型對應，並且提供了豐富和完整的開發文件以及應用實體。而且，兩家公司正在互通性方面努力研究。可以樂觀的估計，不用多久， SOAP 互通性的時代就將來臨。

與SOAP相關的一些標準︰

1. HTTP 1.0 or greater（ http://www.w3.org/Protocols/HTTP/ietf-http-ext ）
2. the core W3C XML recommendation（ http://www.w3.org/TR/1998/REC-xml-19980210 ）
3. W3C XML namespace recommendation（ http://www.w3.org/TR/REC-xml-names ）.
4. XML Schema（ http://www.w3.org/TR/xmlschema-1/ ）

目前支援SOAP的一些公司產品︰

Organization	Product
Rogue Wave	Nouveau ORB
Iona	Orbix 2000
ObjectSpace	Voyager
Digital Creations	Zope, the Python Application Server
UserLand	Frontier groupware product
Microsoft	Windows DNA 2000

SOAP是一個協定，與程式設計語言無關。實際上，許多語言已經開始支援SOAP，如︰java,c/c++,vb,c#,perl,php.下面列出了在Java/C++/Perl/ADA/Python環境下SOAP的執行工具︰

• Java : Apache SOAP, DevelopMentor's implementation, IdooXoap from ZVON
• Python : PythonWare (client side only)
• C++ : IdooXoap from ZVON
• Perl : SOAP::Lite
• ADA : An ADA implementation
• Microsoft Visual Studio: The Microsoft SOAP toolkit.

回到頂端

參考資料

• http://www.ibm.com/developerworks/tw/ （IBM公司）
  
  
• http://msdn.microsoft.com/ （微軟公司）
  
  
• http://www.w3.org/TR/soap12/ （W3C聯盟）
  
  
• http://www.soaprpc.com/
  
  
• http://www.webservices.org
  
  
• http://www.soapwebservices.com
  
  
• http://www.xml.org.tw （台灣xml聯盟）
  

鑒於SOAP是目前的新技術，國內資料貧乏，主要參考了國外的一些資料及IBM和MICROSOFT的相關資料，文章偏頗之處，請多指教﹗

回到頂端

關於作者

	段智華: 進階軟體工程師，對工作流程系統有深入研究，曾參與基於XML的SU-PDM2.0產品資料管理系統的開發。目前在上海市易方公司從事SOAP/XML的研究。可透過E-mail: duanzhihua@263.net 與作者連絡。

Web Services介紹

Web Services介紹

資策會數位教育研究所講師 鄧文焯

　


這一年多來，不管是從報章雜誌、網路文章、電視、收音機，甚至路邊兩個人的對話，你都可能看到、聽到網路服務、Web服務，或者Web Services這幾個字眼。究竟這是個甚麼東西，為甚麼會弄得沸沸揚揚到處都出現呢？這篇短文就將為你簡單的說明甚麼是Web Services以及關於Web Services的幾個重要標準。

甚麼是Web Services
這個問題問十個人可能會的到十個以上的答案，希望以下的說明不會讓你答案版本數字再多加一。
“Web Services是一種軟體元件，它透過Web 通訊協定及資料格式的開放式標準(例如 HTTP、XML 及 SOAP等)來為其他的應用程式提供服務。”
這句話簡單的表達了Web Services的意義，這裡面有兩個重點，一是它是一個提供服務的元件。二是它以Web的開放標準為基礎。
根據以上的認識，我們可以看出Web Services的價值。
作為提供服務的元件，它可用來建構分散式架構系統，實現分散式架構動態整合、平衡負擔、單元升級等優點。
以Web的開放標準為基礎，在已經廣被使用的Web網路架構上來運作，採用開放式標準讓Web Services具有良好互通性，在不同平台上用不同程式語言建置的系統也可以輕易整合，克服目前分散式系統各自使用不同機制造成整合困難的情形。
舉一個最常被提到的例子來說明Web Services在實際應用上帶來的可能性。假設我們要建立一個旅遊網站，網站提供的服務包括了旅遊資訊查詢、機票和飯店的預訂和付款、天氣狀況查詢等等，將來只要找到提供這些服務的Web Services，然後將它們整合到網站中即可，不需要再花費時間和資源自己去維護一個包含了旅遊資訊、天氣資訊的資料庫，不需要再自行建立和各飯店、航空公司的資料聯繫和訂位付款機制等等。這個網站就像是建立在Web上整合了這些Web Services元件的一個應用程式系統。更重要的是，透過Web Services的使用，不必擔心這些服務是使用甚麼平台、甚麼技術來建立，而將來如果有更好的服務或服務提供者時，也可以輕易的將服務更換或更新。對系統的開發者來講，可以快速輕鬆的將系統建構完成，將心思專注在規劃更好、更完善的系統上。對服務的提供者而言，只要能設計出一個好的服務，它的潛在使用者市場將不再受到使用者平台的限制而有無限的可能。單就這類應用所呈現的美好遠景，應該可以解釋為甚麼會到處聽到有人在談論Web Services了。

Web Services的重要標準
前面說過Web Services是以Web的開放標準為基礎，其中最基本的是HTTP和XML。但建構完整的Web Services運作還需要更多基礎，以下這些都是以XML為基本語法建立的重要標準。
UDDI (Universal Description Discovery and Integration) : 提供註冊與搜尋Web Service資訊的一個標準。
WSDL (Web Service Description Language): 描述一個Web Services的運作方式，以及指示用戶端與它可能的互動方式。
SOAP (Simple Object Access Protocol): 在網路上交換結構化和型別資訊的一種簡易通訊協定。

這裡不準備說明這些標準的細節，只用下面這張圖來呈現這些標準在Web Services運作中扮演的角色。

在這張圖中，縱向上由左到右表示出Web Services在提供者和使用者之間運作的幾個主要步驟。橫向上則是每個步驟使用到的標準。這張圖具有很清楚的說明性，一看便可瞭解Web Services的基本運作和上面這些標準的關係。比較需要說明的是，尋找服務時同時使用到了UDDI和SOAP，原因是這裡UDDI的目錄服務也是透過Web Service來提供的。

這裡不準備說明這些標準的細節，只用下面這張圖來呈現這些標準在Web Services運作中扮演的角色。

在這張圖中，縱向上由左到右表示出Web Services在提供者和使用者之間運作的幾個主要步驟。橫向上則是每個步驟使用到的標準。這張圖具有很清楚的說明性，一看便可瞭解Web Services的基本運作和上面這些標準的關係。比較需要說明的是，尋找服務時同時使用到了UDDI和SOAP，原因是這裡UDDI的目錄服務也是透過Web Service來提供的。


結語
作為一個新起的技術，Web Services還在持續發展中，包括安全、管理等方面的規範仍不斷被研究討論和推出，至於，它是不是真的能成功的發展起來，被普遍的接受使用？是不是可以實現它所給予的美好遠景？不知道！不過可以確定的是，在未來幾年中，它仍將是一個熱門的主題，你還是無法避免在路邊聽到有人提到它。