|
SOAP(Simple Object Access Protocal) 技術(shù)有助于實(shí)現(xiàn)大量異構(gòu)程序和平臺(tái)之間的互操作性，從而使存在的應(yīng)用能夠被廣泛的用戶所訪問。SOAP是把成熟的基于HTTP的WEB技術(shù)與XML的靈活性和可擴(kuò)展性組合在了一起。 這篇文章帶你全面回顧對(duì)象遠(yuǎn)程進(jìn)程調(diào)用（ORPC）技術(shù)的歷程，以幫助你理解SOAP技術(shù)的基礎(chǔ)，以及它克服存在技術(shù)（如CORBA和DCOM）的許多缺陷的方法。隨后講述詳細(xì)的SOAP編碼規(guī)則，并把焦點(diǎn)放在SOAP是怎樣映射到存在的ORPC概念上的。 引言： 當(dāng)我在1984年開始把計(jì)算作為我的職業(yè)的時(shí)候，大多數(shù)程序員并不關(guān)心網(wǎng)絡(luò)協(xié)議。但是在九十年代網(wǎng)絡(luò)變得無所不在，現(xiàn)在如果有誰使用計(jì)算機(jī)卻不使用某種形式網(wǎng)絡(luò)連接是很難以想象的。今天，一般的程序員對(duì)建立可擴(kuò)展的分布式應(yīng)用表現(xiàn)出更大的興趣，而不再只是關(guān)注于用MFC實(shí)現(xiàn)個(gè)性化的可浮動(dòng)半透明非矩形的Coolbars了。 程序員通常喜歡用編程模型來思考問題，而很少考慮網(wǎng)絡(luò)協(xié)議。盡管這樣做通常是很好的，但在這篇文章中我將討論的SOAP是一個(gè)沒有明顯的編程模型的網(wǎng)絡(luò)協(xié)議。這并不意味著SOAP的體系結(jié)構(gòu)從根本上會(huì)改變你編程的方式。相反，SOAP的一個(gè)主要目標(biāo)是使存在的應(yīng)用能被更廣泛的用戶所使用。為了實(shí)現(xiàn)這個(gè)目的，沒有任何SOAP API或SOAP 對(duì)象請(qǐng)求代理（SOAP ORB），SOAP是假設(shè)你將使用盡可能多的存在的技術(shù)。幾個(gè)主要的CORBA廠商已經(jīng)承諾在他們的ORB產(chǎn)品中支持SOAP協(xié)議。微軟也承諾在將來的COM版本中支持SOAP。 DevelopMentor已經(jīng)開發(fā)了參考實(shí)現(xiàn)，它使得在任何平臺(tái)上的任何Java或Perl程序員都可以使用SOAP。 在SOAP后面的指導(dǎo)理念是“它是第一個(gè)沒有發(fā)明任何新技術(shù)的技術(shù)”。SOAP采用了已經(jīng)廣泛使用的兩個(gè)協(xié)議：HTTP和XML。HTTP用于實(shí)現(xiàn)SOAP的RPC風(fēng)格的傳輸，而XML是它的編碼模式。采用幾行代碼和一個(gè)XML解析器，HTTP服務(wù)器（如MS的IIS或Apache）立刻成為了SOAP的ORBs。 因?yàn)槟壳俺^一半的Web服務(wù)器采用IIS或Apache, SOAP將會(huì)從這兩個(gè)產(chǎn)品的廣泛而可靠的使用中獲取利益。這并不意味著所有的SOAP請(qǐng)求必須通過Web服務(wù)器來路由，傳統(tǒng)的Web 服務(wù)器只是分派SOAP請(qǐng)求的一種方式。因此Web服務(wù)如IIS或Apache對(duì)建立SOAP使能的應(yīng)用是充分的，但決不是必要的。 正如這篇文章將要描述的，SOAP簡單地用XML來編碼HTTP的傳輸內(nèi)容。SOAP最常用的應(yīng)用是作為一個(gè)RPC協(xié)議。為了理解SOAP怎樣工作，有必要簡要回顧一下RPC協(xié)議的歷史。 RPCs的歷史 建立分布式應(yīng)用的兩個(gè)主要通信模型是消息傳送（經(jīng)常與隊(duì)列組合在一起）和請(qǐng)求/響應(yīng)。消息傳遞系統(tǒng)允許通信任何一方在任何時(shí)間發(fā)送消息。請(qǐng)求/響應(yīng)協(xié)議把通信模式限制在請(qǐng)求/響應(yīng)的雙方。基于消息的應(yīng)用強(qiáng)烈地意識(shí)到它們正在與外部的并行進(jìn)程進(jìn)行通信，并且需要一個(gè)顯式的設(shè)計(jì)風(fēng)格?；谡?qǐng)求/響應(yīng)的應(yīng)用更象一個(gè)單進(jìn)程的應(yīng)用，因?yàn)榘l(fā)送請(qǐng)求的應(yīng)用或多或少被阻塞直至收到來自另一個(gè)進(jìn)程的響應(yīng)。這使得請(qǐng)求/響應(yīng)通信自然地適合于RPC應(yīng)用。 盡管消息通信和請(qǐng)求/響應(yīng)各有他們的優(yōu)點(diǎn)，他們都是可以用對(duì)方來實(shí)現(xiàn)的。消息系統(tǒng)可以用較底層的請(qǐng)求/響應(yīng)協(xié)議來建立。如微軟的Message Queue Server (MSMQ)內(nèi)部采用了DCE RPC來建立大多數(shù)的控制邏輯。RPC系統(tǒng)也可以采用較底層的消息系統(tǒng)來建立。MSMQ提供的關(guān)聯(lián) ID正是為了這個(gè)目的。不管評(píng)價(jià)如何，大多數(shù)的應(yīng)用仍趨向于使用RPC協(xié)議，因?yàn)樗鼈儚V泛的使用，它們更簡單的設(shè)計(jì)，以及更自然的到傳統(tǒng)的編程技術(shù)的映射。 在八十年代，兩個(gè)主要的RPC協(xié)議是Sun RPC 和DCE RPC。最流行的Sun RPC應(yīng)用是大多數(shù)UNIX系統(tǒng)所使用的Network File System (NFS)。最流行的DCE RPC應(yīng)用則是Windows NT?，它采用DCE RPC 協(xié)議來實(shí)現(xiàn)許多系統(tǒng)服務(wù)。這兩個(gè)協(xié)議被證明適用于很大范圍的應(yīng)用。但是，在八十年代末期，面向?qū)ο蠹夹g(shù)的風(fēng)靡使軟件界沉迷于在面向?qū)ο笳Z言和基于RPC的通信之間建立一個(gè)紐帶。 在九十年代產(chǎn)生的對(duì)象RPC (ORPC) 協(xié)議正是試圖把面向?qū)ο蠛途W(wǎng)絡(luò)協(xié)議聯(lián)系起來。ORPC 和 RPC 協(xié)議的主要不同是ORPC代碼化了從通信終端到語言級(jí)對(duì)象的映射。在每個(gè)ORPC請(qǐng)求的頭中都有一個(gè)cookie，服務(wù)器端的程序能用它來定位在服務(wù)器進(jìn)程中的目標(biāo)對(duì)象。通常這個(gè)cookie只是一個(gè)對(duì)數(shù)組的索引，但其它技術(shù)也經(jīng)常被使用，如用符號(hào)名作為Hash表的鍵。 目前兩個(gè)主要的OPRC協(xié)議是DCOM 和 CORBA的 Internet Inter-ORB Protocol (IIOP) 或更一般的General Inter-ORB Protocol (GIOP)。DCOM和IIOP/GIOP的請(qǐng)求格式非常相似。兩個(gè)協(xié)議都用一個(gè)對(duì)象端點(diǎn)ID來確定目標(biāo)對(duì)象，用方法標(biāo)識(shí)符來決定調(diào)用哪個(gè)方法。 這兩個(gè)協(xié)議主要有兩點(diǎn)不同：主要的一點(diǎn)不同是采用IIOP/GIOP時(shí)，接口標(biāo)識(shí)符是隱含的，因?yàn)橐粋€(gè)給定的CORBA對(duì)象只實(shí)現(xiàn)一個(gè)接口（盡管OMG當(dāng)前正在進(jìn)行每個(gè)對(duì)象有多個(gè)接口支持的標(biāo)準(zhǔn)化工作）。DCOM與IIOP/GIOP請(qǐng)求的另一個(gè)細(xì)微差別是在傳輸體中參數(shù)值的格式。在DCOM中，傳輸體用網(wǎng)絡(luò)數(shù)據(jù)表達(dá)（NDR）的格式來寫，在IIOP/GIOP中，傳輸體用公共數(shù)據(jù)表達(dá)（CDR）的格式來寫。NDR和 CDR分別處理在各種平臺(tái)上的不同的數(shù)據(jù)表達(dá)。但是在這兩種格式之間有一些小的差別，這使它們相互之間并不兼容。 在ORPC與RPC協(xié)議之間的另一個(gè)重要的不同是通信端點(diǎn)的命名方式。在ORPC協(xié)議中，對(duì)于ORPC端點(diǎn)的一些可傳遞的表達(dá)方式被要求在網(wǎng)絡(luò)之間傳遞對(duì)象引用。在CORBA/IIOP，這個(gè)表達(dá)方式被稱為可交互的對(duì)象引用（IOR）。IORs包含用緊湊格式表達(dá)的尋址信息，使用了它任何CORBA產(chǎn)品都可以決定一個(gè)對(duì)象端點(diǎn)。在DCOM中，這種表達(dá)方式被稱為OBJREF，它組合了分布的引用計(jì)算和端點(diǎn)/對(duì)象標(biāo)識(shí)。CORBA和DCOM都提供了在網(wǎng)絡(luò)上尋找對(duì)象端點(diǎn)的高級(jí)機(jī)制，但最終這些機(jī)制都映射回到了IORs或OBJREFs。 目前的技術(shù)存在的問題？ 盡管DCOM和IIOP都是固定的協(xié)議，業(yè)界還沒有完全轉(zhuǎn)向其中任何一個(gè)協(xié)議。沒有融合的部分原因是文化的問題所致。而且在當(dāng)一些組織試圖標(biāo)準(zhǔn)化一個(gè)或另一個(gè)協(xié)議的時(shí)候，兩個(gè)協(xié)議的技術(shù)適用性就被提出質(zhì)疑。傳統(tǒng)上認(rèn)為DCOM和CORBA都是合理服務(wù)器到服務(wù)器端的通信協(xié)議。但是，二者對(duì)客戶到服務(wù)器端的通信都存在明顯的弱點(diǎn)，尤其是客戶機(jī)被散布在Internet上的時(shí)候。 DCOM 和 CORBA/IIOP都是依賴于單個(gè)廠商的解決方案來最大優(yōu)勢地使用協(xié)議。盡管兩個(gè)協(xié)議都在各種平臺(tái)和產(chǎn)品上被實(shí)現(xiàn)了，但現(xiàn)實(shí)是選定的發(fā)布需要采用單一廠商的實(shí)現(xiàn)。在DCOM的情況下，這意味著每個(gè)機(jī)器要運(yùn)行在Windows NT。（盡管DCOM已經(jīng)被轉(zhuǎn)移到其它平臺(tái)，但它只在Windows?上獲得了廣泛的延伸）。在CORBA情況下，這意味著每個(gè)機(jī)器要運(yùn)行同樣的ORB產(chǎn)品。的確讓兩個(gè)CORBA產(chǎn)品用IIOP相互調(diào)用是有可能的，但是許多高級(jí)的服務(wù)（如安全和事務(wù)）此時(shí)通常不是可交互的。而且，任何專門廠商為同樣的機(jī)器的通信所作的優(yōu)化很難起作用，除非所有的應(yīng)用被建立在同一個(gè)ORB產(chǎn)品上。 DCOM 和CORBA/IIOP都依賴于周密管理的環(huán)境。兩個(gè)任意的計(jì)算機(jī)使得DCOM或IIOP 在環(huán)境之外被成功調(diào)用（calls out of the box）的幾率是很低的。特別是在考慮安全性的時(shí)候尤其是這樣。盡管寫一個(gè)能成功地運(yùn)用DCOM或IIOP的緊縮包（shrink-wrap）應(yīng)用是可能的，但這樣做要比基于socket的應(yīng)用要更多地關(guān)注細(xì)節(jié)。這對(duì)于乏味但必需的配置和安裝管理任務(wù)特別適用。 DCOM 和 CORBA/IIOP都依賴于相當(dāng)高技術(shù)的運(yùn)行環(huán)境。盡管進(jìn)程內(nèi)的COM似乎特別簡單，但COM/DCOM遠(yuǎn)程處理程序絕對(duì)不只是幾天就解決的事情。IIOP 是一個(gè)比DCOM更容易實(shí)現(xiàn)的協(xié)議，但兩個(gè)協(xié)議都有相當(dāng)多的深?yuàn)W的規(guī)則來處理數(shù)據(jù)排列、類型信息和位操作。這使得一般的程序員在沒有領(lǐng)會(huì)ORB產(chǎn)品或OLE32.DLL的情況下去構(gòu)造一個(gè)簡單的CORBA或DCOM調(diào)用也變得很困難。 也許對(duì)DCOM和CORBA/IIOP來說，最令人難以忍受的一點(diǎn)是它們不能在Internet 上發(fā)揮作用。對(duì)DCOM來說，一般用戶的iMac 或廉價(jià)的運(yùn)行Windows 95的PC 兼容機(jī)要想使用你的服務(wù)器執(zhí)行基于領(lǐng)域認(rèn)證幾乎是不可能的。更糟的是，如果防火墻或代理服務(wù)器分隔開了客戶和服務(wù)器的機(jī)器，任何IIOP或DCOM包要通過的可能性是很低的，主要是由于大多數(shù)Internet連接技術(shù)對(duì)HTTP協(xié)議的偏愛所致。盡管一些廠商如Microsoft， Iona和Visigenic都已經(jīng)建立了通道技術(shù)，但這些產(chǎn)品很容易對(duì)配置錯(cuò)誤敏感而且它們是不可交互的。 在一個(gè)服務(wù)器群落中這些問題并不能影響DCOM或IIOP的使用。因?yàn)樵诜?wù)器群落中主機(jī)的數(shù)量很少（一般是成百上千，而不是成千上萬），這就抵消了DCOM基于ping的生命周期管理的成本。在服務(wù)器群落中，所有主機(jī)被一個(gè)公共管理域管理的機(jī)率很大，使得統(tǒng)一的配置變得可能。相對(duì)少量的機(jī)器也能保持商業(yè)ORB產(chǎn)品可控制使用的成本，因?yàn)橹恍枰倭康腛RB許可權(quán)。如果只有IIOP在服務(wù)器群落中被使用，就只需要少量的ORB許可權(quán)。最后，在服務(wù)器群落中所有主機(jī)有直接的IP連接也是可能的，這就消除了與防火墻相關(guān)的DCOM和 IIOP問題。 HTTP作為一個(gè)更好的RPC 在服務(wù)器群落中使用DCOM 和CORBA 是通用的做法，但客戶機(jī)則使用HTTP進(jìn)入服務(wù)器群落。HTTP與RPC的協(xié)議很相似，它簡單、配置廣泛，并且對(duì)防火墻比其它協(xié)議更容易發(fā)揮作用。HTTP請(qǐng)求一般由Web服務(wù)器軟件（如IIS和Apache）來處理，但越來越多的應(yīng)用服務(wù)器產(chǎn)品正在支持HTTP作為除DCOM和IIOP外的又一個(gè)協(xié)議。 象DCOM和IIOP一樣，HTTP層通過TCP/IP進(jìn)行請(qǐng)求/響應(yīng)通信。一個(gè)HTTP的客戶端用TCP連接到HTTP服務(wù)器。在HTTP中使用的標(biāo)準(zhǔn)端口號(hào)是80，但任何其它端口也能被使用。在建立TCP連接后，客戶端可以發(fā)送一個(gè)請(qǐng)求消息到服務(wù)器端。服務(wù)器在處理請(qǐng)求后發(fā)回一個(gè)HTTP響應(yīng)消息到客戶端。請(qǐng)求和響應(yīng)消息都可以包含任意的傳輸體的信息，通常用Content-Length和Content-Type的 HTTP 頭來標(biāo)記。下面是一個(gè)合法的HTTP請(qǐng)求消息： POST /foobar HTTP/1.1 Host: 209.110.197.12 Content-Type: text/plain Content-Length: 12 Hello, World 你可能已經(jīng)注意到HTTP頭只是一般文本。這使得用包檢查程序或基于文本的Internet工具（如telnet）來診斷HTTP問題變得更容易。HTTP基于文本的屬性也使得HTTP更容易適用于在Web開發(fā)中流行的低技術(shù)水平的編程環(huán)境。 HTTP請(qǐng)求的第一行包含三個(gè)組件：HTTP方法，請(qǐng)求-URI，協(xié)議版本。在前面的例子中，這些分別對(duì)應(yīng)于POST, /foobar, 和 HTTP/1.1。Internet工程任務(wù)組(IETF)已經(jīng)標(biāo)準(zhǔn)化了數(shù)量固定的HTTP方法。GET是HTTP用來訪問Web的方法。 POST是建立應(yīng)用程序的最常用的HTTP方法。和GET不一樣，POST允許任意數(shù)據(jù)從客戶端發(fā)送到服務(wù)器端。請(qǐng)求URI (Uniform Resource Identifier)是一個(gè)HTTP服務(wù)器端軟件，它用來識(shí)別請(qǐng)求的目標(biāo)的簡單的標(biāo)識(shí)符（它更象一個(gè)IIOP/GIOP object_key 或一個(gè)DCOM IPID）。關(guān)于URIs更多的信息請(qǐng)參照"URIs, URLs, and URNs"。在這個(gè)例子中協(xié)議的版本是HTTP/1.1， 它表示遵守RFC 2616的規(guī)則。HTTP/1.1比HTTP/1.0多增加了幾個(gè)特性，包括對(duì)大塊數(shù)據(jù)傳輸?shù)闹С忠约皩?duì)在幾個(gè)HTTP請(qǐng)求之間保持TCP連接的支持。 請(qǐng)求的第三行和第四行指定了請(qǐng)求體的尺寸和類型。Content-Length 頭指定了體信息的比特?cái)?shù)。Content-Type類型標(biāo)識(shí)符指定MIME類型為體信息的語法。HTTP (象 DCE一樣) 允許服務(wù)器和客戶端協(xié)商用于編制信息的傳輸語法。大多數(shù)DCE應(yīng)用采用NDR.。大多數(shù)Web應(yīng)用采用text/html 或其它基于文本的語法。 注意在上面樣例中Content-Length頭與請(qǐng)求體之間的空行。不同的HTTP頭被carriage-return/行碼序列劃定界限。這些頭與體之間用另外的carriage-return/行碼序列來劃定界限。請(qǐng)求接著包括原始字節(jié)，這些字節(jié)的語法和長度由Content-Length和Content-Type HTTP 頭來識(shí)別。在這個(gè)例子中，內(nèi)容是十二字節(jié)的普通文本字符串"Hello, World"。 在處理了請(qǐng)求之后，HTTP服務(wù)器被期望發(fā)回一個(gè)HTTP響應(yīng)到客戶端。響應(yīng)必須包括一個(gè)狀態(tài)代碼來表示請(qǐng)求的結(jié)果。響應(yīng)也可以包含任意的體信息。下面是一個(gè)HTTP響應(yīng)消息： 200 OK Content-Type: text/plain Content-Length: 12 dlroW ,olleH 在這個(gè)例子中，服務(wù)器返回狀態(tài)代碼200，它是HTTP中標(biāo)準(zhǔn)的成功代碼。如果服務(wù)器端不能破解請(qǐng)求代碼，它將返回下列的響應(yīng)： 400 Bad Request Content-Length: 0 如果HTTP服務(wù)器決定到目標(biāo)URI的請(qǐng)求應(yīng)該臨時(shí)轉(zhuǎn)向另外的一個(gè)不同的URI，下列響將被返回： 307 Temporarily Moved Location: http://209.110.197.44/foobar Content-Length: 0 這個(gè)響應(yīng)告知客戶，請(qǐng)求將能夠通過重新傳遞它到在Location頭中指定的地址來被滿足。 所有的標(biāo)準(zhǔn)狀態(tài)碼和頭都在RFC 2616中被描述。它們中很少的內(nèi)容與SOAP用戶直接相關(guān)，但有一個(gè)明顯的例外。在HTTP/1.1，底層的TCP連接在多個(gè)請(qǐng)求/響應(yīng)對(duì)之間重用。HTTP Connection頭允許客戶端或服務(wù)器中任何一方關(guān)閉底層的連接。通過增加下列HTTP頭到請(qǐng)求或響應(yīng)中，雙方都會(huì)要求在處理請(qǐng)求后關(guān)閉它們的TCP連接： Connection: close 當(dāng)與HTTP/1.0軟件交互時(shí)，為了保持TCP連接，建議發(fā)送方加入下列HTTP頭到每個(gè)請(qǐng)求或響應(yīng)中： Connection: Keep-Alive 這個(gè)頭使缺省的HTTP/1.0協(xié)議在每次響應(yīng)后重新開始TCP連接的行為無法使用。 HTTP的一個(gè)優(yōu)點(diǎn)是它正被廣泛的使用和接受。圖4表示了一個(gè)簡單的Java程序，它發(fā)送前面表示的請(qǐng)求并從響應(yīng)中解析出結(jié)果字符串。 下面則是一個(gè)簡單的C程序用CGI來讀取來自HTTP請(qǐng)求的字符串并通過HTTP響應(yīng)把它的逆序串返回。 #include ＜stdio.h＞ int main(int argc, char **argv) { char buf[4096]; int cb = read(0, buf, sizeof(buf)); buf[cb] = 0; strrev(buf); printf("200 OK\r\n");p＞ printf("Content-Type: text/plain\r\n"); printf("Content-Length: %d\r\n", cb); printf("\r\n"); printf(buf); return 0; 服務(wù)器的實(shí)現(xiàn)是用Java servlet，以避免CGI的每個(gè)請(qǐng)求一個(gè)進(jìn)程的開銷。 一般 來說CGI是花費(fèi)代價(jià)最小的寫HTTP服務(wù)器端代碼的方法。實(shí)際上，每一個(gè)HTTP服務(wù)器端產(chǎn)品都提供了一個(gè)更有效的機(jī)制來讓你的代碼處理一個(gè)HTTP請(qǐng)求。IIS提供了ASP和ISAPI作為寫HTTP代碼的機(jī)制。Apache允許你用運(yùn)行在Apache后臺(tái)程序中的 C或Perl來寫模塊。大多數(shù)應(yīng)用服務(wù)器軟件允許你寫Java servlet，COM組件，EJB Session beans或基于可攜帶對(duì)象適配器（POA）接口的CORBA servants。 |
|
|
