簡易物件存取協定
Simple Object Access Protocol (SOAP)
作者: 恆逸資訊 胡百敬
什麼是簡易物件存取協定(SOAP)，簡而言之就是利用現存的網際網路架構讓應用程式之間可以彼此溝通，而不會被防火牆阻礙。在分散式的架構下，使用 XML 的環境中，SOAP提供兩個電腦系統之間交換的架構與資料型別。
在過去五年來透過網際網路存取已經變成是較進步社會的基礎需求。在其上執行著各式各樣的通訊協定。但是直至目前為止最廣泛被接受的通訊協定依然是Hypertext Transfer Protocol(HTTP)，它是瀏覽器與Web伺服器之間溝通時使用，對於文字、圖形以及其他資訊的傳輸很有效率與彈性，而且它簡單易懂。
你我所撰寫的應用程式利用網際網路在遠端互動已經變得越來越重要。現今在網際網路上提供eService已經是大勢所趨。舉個例子來說，你可能在某一家網路公司所提供的行事曆上註冊，當快遞公司要送貨品給你時，它的系統會自動與提供行事曆的網路公司合作，查閱你的在家的時間，自動排定送貨的行程。或著是你想寫一個入門網站，但覺得某個網站所提供的交通資訊或是天氣預報系統很好，你想直接讓你的使用者透過系統之間的合作，可以在你的網站線上查詢別的網站上這些資料。而那些提供服務的網站也可以查詢的次數向你收費。
以上這些動作都需要系統自動完成合作，不再有人工參與。且彼此的系統是各自以他所熟悉的技術完成，這代表著系統不會遵循特殊的架構。有可能我的系統是Win32，使用的是COM+﹔而你的是UNIX作業系統，利用CORBA提供服務。
讓兩個系統透過網際網路溝通，僅僅用HTTP通訊協定本身提供的功能是不夠的，雖然HTTP本身的彈性很大，但它基本的設計並不適合呼叫遠端的程式物件。這種互動在區域網路內一般是使用Remote Procedure Call(RPC)，也就是使用者端傳出一些參數，並由伺服端回傳一些結果。
現今已有許多分散式物件通訊協定(distributed object protocols) 提供遠端程式間的溝通。例如微軟的Distribured Component Object Model(DCOM)、Object Management Group的Internet Inter-ORB Protocol(IIOP)等等。所有這些服務都提供相同的服務，也就是讓使用者端可以觸發RPC到伺服端應用程式，並接到回傳結果。 在企業內部網路(Intranet)上使用分散式物件傳輸協定有很好的效果。但在公眾的網際網路上使用這些協定就有很多問題。任何連上網際網路的伺服器基本上都可以被任何網際網路的使用者存取，這導致需要較嚴謹的安全考量。為了安全，大部分的企業都在它們內部與外部網路之間加裝防火牆以防止網際網路上的大眾存取企業內部的伺服器。這些防火牆，例如微軟的Proxy伺服器，可以經由條件設定以阻止一些想進企業內部來的公眾網路需求，這可以大幅提昇內部系統的安全。
雖然防火牆是提供接上網際網路安全的基礎機制，但它卻會降低分散式物件通訊協定的使用效能。為了要解決這個問題，有識之士紛紛提出了各自的解決方案。在 1998 年，UserLand 公司的執行總裁 Dave Winner 提出透過 XML 讓 RPC 的通訊方式透過 HTTP 協定在網際網路上執行。
這個想法經由微軟公司加以改良，提出了實際可行的Simple Object Access Protocol(SOAP)通訊協定。現今正在W3C審議中，已經有IBM等大廠表態支持。不久的未來即將可能成為在網際網路上提供電子服務的標準協定。
SOAP是一個像DCOM或其他分散式物件通訊協定的協定，讓使用者端與伺服端的RPCs可以溝通。但與其他類似協定不一樣的地方是，它支援防火牆的使用。同樣重要地，SOAP不是只設計用來針對某種物件技術的協定，它不像一些時下的分散式物件通訊協定會被綁死在某一種特定的物件規格上，這個協定將可以被任何的物件使用。所以它將是兩大物件陣營COM 和 CORBA 最好的溝通橋樑，讓彼此的物件程式可以跨平台透過網際網路呼叫。
簡易物件存取協定如其名稱所言，要求定義要"簡易"，所以它只訂出物件溝通基礎規範，如
讓物件透過網際網路提出需求的方式標準化，以 HTTP 當傳輸的方式，以 XML 描述溝通的內容
建立可延伸的傳遞物件呼叫格式的承載 但它不定義一些一般分散式物件系統需要定義的
分散式系統資源回收(garbage collection)
雙向的 HTTP 溝通
物件參照
物件初始化
以上這些不明確定義的規格都交由各系統廠商自行實作。
使用防火牆所造成的問題以及 SOAP 所提供的解決方案
要了解為何防火牆會造成分散式物件通訊協定的問題必須先了解到防火牆是如何分辨協定之間的不同。在TCP/IP的架構下，每一個被廣泛使用的協定都被賦予一個特殊的埠號(port number)而每一個使用該協定的需求封包都帶著這個埠號。例如HTTP協定的埠號是80、FTP是21等等。大部分的防火牆可以用來防止某個特殊協定的方式就是針對埠號拒絕某種協定的通訊。通常防火牆是被設定成允許埠號80的運作的-如果該公司不拒絕使用HTTP的話。
但大部分的防火牆會擋住其他的埠，因為它們假定利用其他的埠對公司內部網路的運作都是有危險的。 但這也正是造成分散式物件通訊協定無法運行的原因。不像HTTP、FTP等其他著名的通訊協定，分散式物件通訊協定通常沒有使用一個著名的大家都知道的埠號來溝通。相反地，這些通訊協定通常動態地被賦予埠號，埠號碼在被需求時任意產生。如果沒有防火牆擋在使用者端與伺服端之間，這種方式將可以很有效地運作。但若加了防火牆，則該通訊協定會因為防火牆不允許兩端任意使用任何埠號來溝通而中斷。
當下存在很多種解決方式，例如某些防火牆可以被設定成允許某個範圍的埠號碼可以進行溝通。若該分散式物件通訊協定也可以被設定成只用這個範圍的埠號碼，則這個方案便可行，使用者端與伺服端之間可以進行溝通。但比較注重安全的網路管理者將不會贊成開放任意一組埠號碼而導致這個方案並不完美。另一個選擇是採用COM網際網路服務，這讓傳統的DCOM封包在TCP上透過埠號80來傳遞。這在某些方面很有用，但這項技術只有微軟的Internet Information Server和DCOM在使用，而不是一項完整的解決方案，所以我們需要一個更普遍一般性的解決方案。
因為幾乎所有的防火牆都允許透過埠號80來溝通，所以透過埠號80來溝通的分散式物件通訊協定將是一個較好的方案。但這並不是說說那麼容易，因為埠號80已經被設定給HTTP協定。所以SOAP這個分散式物件通訊協定是架在HTTP協定之上的。HTTP通訊協定相當簡單，僅僅以少數基礎的動詞所組成，如GET、PUT、POST等等，而這些動詞在瀏覽器與伺服器之間傳遞。而每一個動詞之後跟著一些資訊，而這些資訊通常以簡易的字串方式傳遞。
SOAP不能改變任何的現狀，也不能要求增加HTTP現有的動詞。替代方案是SOAP將使用Extensible Markup Language(XML)來定義需求與回應訊息的格式，並允許使用正常的HTTP POST命令來傳遞這些訊息。所有的SOAP通訊都使用80埠，這也代表著在網際網路上SOAP可以透過任何的Web伺服器來溝通-防火牆將不再是一個問題。 SOAP主要的設計目的之一就是保證它可以有效地使用既有的網際網路架構-也就是HTTP、防火牆、代理伺服器(proxy)以及其他種種。例如SOAP可以使用Secure Sockets Layer(SSL)通訊協定以加密維護安全，使用到HTTP的連線管以機制，等等更多更多的部分。SOAP讓分散式物件通訊協定透過網際網路的溝通像使用瀏覽器來存取網頁一樣方便。
在現今這個世界上已經有許多的許多分散是物件通訊協定，但還沒有一個可以不被改變就用在現今的網際網路上。藉由提供一個架在HTTP之上，簡單、且有彈性的機制來傳送需求與回應，SOAP讓當下觸發遠端函數不需要有任何改變。讓應用程式可以透過網際網路存取不是一件小事。且它並未被綁死在任何一個單一的物件模型，這項新的技術擁有可以用在許多不同情況的潛力。基於以上的論述，SOAP對於今日的通訊協定是一項值得增加的投資。
……