SOAP協議初級指南(1)

 

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。cookie

  在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應用。spa

  儘管消息通訊和請求/響應各有他們的優勢,他們都是能夠用對方來實現的。消息系統能夠用較底層的請求/響應協議來創建。如微軟的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。

相關文章
相關標籤/搜索