SOAP協議初級指南
|
SOAP(Simple Object Access Protocal) 技術有助于實現大量異構程序和平臺之間的互操作性，從而使存在的應用能夠被廣泛的用戶所訪問。SOAP是把成熟的基于HTTP的WEB技術與XML的靈活性和可擴展性組合在了一起。
這篇文章帶你全面回顧對象遠程進程調用（ORPC）技術的歷程，以幫助你理解SOAP技術的基礎，以及它克服存在技術（如CORBA和DCOM）的許多缺陷的方法。隨后講述詳細的SOAP編碼規則，并把焦點放在SOAP是怎樣映射到存在的ORPC概念上的。
引言：
當我在1984年開始把計算作為我的職業的時候，大多數程序員并不關心網絡協議。但是在九十年代網絡變得無所不在，現在如果有誰使用計算機卻不使用某種形式網絡連接是很難以想象的。今天，一般的程序員對建立可擴展的分布式應用表現出更大的興趣，而不再只是關注于用MFC實現個性化的可浮動半透明非矩形的Coolbars了。
程序員通常喜歡用編程模型來思考問題，而很少考慮網絡協議。盡管這樣做通常是很好的，但在這篇文章中我將討論的SOAP是一個沒有明顯的編程模型的網絡協議。這并不意味著SOAP的體系結構從根本上會改變你編程的方式。相反，SOAP的一個主要目標是使存在的應用能被更廣泛的用戶所使用。為了實現這個目的，沒有任何SOAP API或SOAP 對象請求代理（SOAP ORB），SOAP是假設你將使用盡可能多的存在的技術。幾個主要的CORBA廠商已經承諾在他們的ORB產品中支持SOAP協議。微軟也承諾在將來的COM版本中支持SOAP。
DevelopMentor已經開發了參考實現，它使得在任何平臺上的任何Java或Perl程序員都可以使用SOAP。
在SOAP后面的指導理念是“它是第一個沒有發明任何新技術的技術”。SOAP采用了已經廣泛使用的兩個協議：HTTP和XML。HTTP用于實現SOAP的RPC風格的傳輸，而XML是它的編碼模式。采用幾行代碼和一個XML解析器，HTTP服務器（如MS的IIS或Apache）立刻成為了SOAP的ORBs。 因為目前超過一半的Web服務器采用IIS或Apache, SOAP將會從這兩個產品的廣泛而可靠的使用中獲取利益。這并不意味著所有的SOAP請求必須通過Web服務器來路由，傳統的Web 服務器只是分派SOAP請求的一種方式。因此Web服務如IIS或Apache對建立SOAP使能的應用是充分的，但決不是必要的。
正如這篇文章將要描述的，SOAP簡單地用XML來編碼HTTP的傳輸內容。SOAP最常用的應用是作為一個RPC協議。為了理解SOAP怎樣工作，有必要簡要回顧一下RPC協議的歷史。
RPCs的歷史
建立分布式應用的兩個主要通信模型是消息傳送（經常與隊列組合在一起）和請求/響應。消息傳遞系統允許通信任何一方在任何時間發送消息。請求/響應協議把通信模式限制在請求/響應的雙方。基于消息的應用強烈地意識到它們正在與外部的并行進程進行通信，并且需要一個顯式的設計風格。基于請求/響應的應用更象一個單進程的應用，因為發送請求的應用或多或少被阻塞直至收到來自另一個進程的響應。這使得請求/響應通信自然地適合于RPC應用。
盡管消息通信和請求/響應各有他們的優點，他們都是可以用對方來實現的。消息系統可以用較底層的請求/響應協議來建立。如微軟的Message Queue Server (MSMQ)內部采用了DCE RPC來建立大多數的控制邏輯。RPC系統也可以采用較底層的消息系統來建立。MSMQ提供的關聯 ID正是為了這個目的。不管評價如何，大多數的應用仍趨向于使用RPC協議，因為它們廣泛的使用，它們更簡單的設計，以及更自然的到傳統的編程技術的映射。
在八十年代，兩個主要的RPC協議是Sun RPC 和DCE RPC。最流行的Sun RPC應用是大多數UNIX系統所使用的Network File System (NFS)。最流行的DCE RPC應用則是Windows NT?，它采用DCE RPC 協議來實現許多系統服務。這兩個協議被證明適用于很大范圍的應用。但是，在八十年代末期，面向對象技術的風靡使軟件界沉迷于在面向對象語言和基于RPC的通信之間建立一個紐帶。
在九十年代產生的對象RPC (ORPC) 協議正是試圖把面向對象和網絡協議聯系起來。ORPC 和 RPC 協議的主要不同是ORPC代碼化了從通信終端到語言級對象的映射。在每個ORPC請求的頭中都有一個cookie，服務器端的程序能用它來定位在服務器進程中的目標對象。通常這個cookie只是一個對數組的索引，但其它技術也經常被使用，如用符號名作為Hash表的鍵。
目前兩個主要的OPRC協議是DCOM 和 CORBA的 Internet Inter-ORB Protocol (IIOP) 或更一般的General Inter-ORB Protocol (GIOP)。DCOM和IIOP/GIOP的請求格式非常相似。兩個協議都用一個對象端點ID來確定目標對象，用方法標識符來決定調用哪個方法。
這兩個協議主要有兩點不同：主要的一點不同是采用IIOP/GIOP時，接口標識符是隱含的，因為一個給定的CORBA對象只實現一個接口（盡管OMG當前正在進行每個對象有多個接口支持的標準化工作）。DCOM與IIOP/GIOP請求的另一個細微差別是在傳輸體中參數值的格式。在DCOM中，傳輸體用網絡數據表達（NDR）的格式來寫，在IIOP/GIOP中，傳輸體用公共數據表達（CDR）的格式來寫。NDR和 CDR分別處理在各種平臺上的不同的數據表達。但是在這兩種格式之間有一些小的差別，這使它們相互之間并不兼容。
在ORPC與RPC協議之間的另一個重要的不同是通信端點的命名方式。在ORPC協議中，對于ORPC端點的一些可傳遞的表達方式被要求在網絡之間傳遞對象引用。在CORBA/IIOP，這個表達方式被稱為可交互的對象引用（IOR）。IORs包含用緊湊格式表達的尋址信息，使用了它任何CORBA產品都可以決定一個對象端點。在DCOM中，這種表達方式被稱為OBJREF，它組合了分布的引用計算和端點/對象標識。CORBA和DCOM都提供了在網絡上尋找對象端點的高級機制，但最終這些機制都映射回到了IORs或OBJREFs。