第二代Web服務(wù)展望

申請免費(fèi)試用、咨詢電話：400-8352-114

第二代Web服務(wù)展望

在互聯(lián)網(wǎng)發(fā)展的早期，企業(yè)都使用SMTP、NTTP和FTP客戶端和服務(wù)器與互聯(lián)網(wǎng)進(jìn)行連接，傳輸消息、文本文件、可執(zhí)行文件和源代碼，當(dāng)企業(yè)開始將企業(yè)信息集成到互聯(lián)網(wǎng)架構(gòu)中時(shí)，互聯(lián)網(wǎng)就成了一種基本的工具。當(dāng)互聯(lián)網(wǎng)重心由交換信息的協(xié)議轉(zhuǎn)向數(shù)據(jù)對象以及它們之間的鏈接時(shí)，互聯(lián)網(wǎng)的普及程度就大大提高了。

早期Web架構(gòu)的特征是HTML-GIF/JPEG、HTTP和URI，它們組合在一起時(shí)，其功能是異常強(qiáng)大的，使用這些技術(shù)，企業(yè)將多種多樣的網(wǎng)上發(fā)布系統(tǒng)進(jìn)行集成，使之成為比任何一種單一的技術(shù)更有吸引力的系統(tǒng)。

一旦各種機(jī)構(gòu)都使用公共的數(shù)據(jù)格式、HTTP協(xié)議和一個(gè)單一的地址系統(tǒng)時(shí)，Web就不再是許多網(wǎng)站的集合了，而成為了最多樣化和功能強(qiáng)大的信息系統(tǒng)，各機(jī)構(gòu)團(tuán)體建立起它們的信息和其他機(jī)構(gòu)團(tuán)體信息之間的鏈接。

第一代Web服務(wù)與第一代連接非常相似，各種Web服務(wù)之間并不是互相集成的，而且其設(shè)計(jì)目標(biāo)也不是使第三方能夠方便地以一種統(tǒng)一的方式對它們進(jìn)行集成。我認(rèn)為，新一代Web服務(wù)將是起源于網(wǎng)上出版和人機(jī)交互的更加集成化的Web服務(wù)，它將是建立在使Web更能發(fā)揮作用的架構(gòu)的基礎(chǔ)上的，該架構(gòu)是三位一體的：標(biāo)準(zhǔn)的格式（XML）、標(biāo)準(zhǔn)的應(yīng)用協(xié)議和單一的URI名字空間。

新一代的Web服務(wù)將與REST這種當(dāng)前Web的架構(gòu)模式息息相關(guān)，它的意思是“表示狀態(tài)轉(zhuǎn)移”。它說明了Web能夠擁有URI、HTTP、HTML、JavaScript和其他許多特性的原因，它包含有多個(gè)方面的內(nèi)容，我不敢說自己已經(jīng)完全掌握了它，在本篇文章中，我們將著重討論XML用戶和開發(fā)人員最感興趣的部分：

當(dāng)前的Web服務(wù)

SOAP最初是作為DCOM或CORBA的跨互聯(lián)網(wǎng)形式出現(xiàn)的，早期的與SOAP類似的一種技術(shù)的名稱為“Web代理”━━基于Web的對象代理，它準(zhǔn)確地表達(dá)了這種技術(shù)在DCOM、CORBA、RMI等標(biāo)準(zhǔn)上建立跨應(yīng)用協(xié)議的含義，它也是解決應(yīng)用之間互操作性問題的現(xiàn)有的模型。

在沒有應(yīng)用到Web上時(shí)，這些技術(shù)只取得了有限的成功。有分析家認(rèn)為問題是微軟和OMG的支持者不合作引起的，但我并不這樣認(rèn)為，其中有更深層次的問題。對于封閉世界問題而言，RPC確實(shí)不錯(cuò)。在封閉世界中，你知道所有的用戶，可以與它們共享數(shù)據(jù)模型，可以根據(jù)自己的需求與它們進(jìn)行溝通。在這樣的環(huán)境中進(jìn)行發(fā)展是相當(dāng)容易的：你只需告訴所有的用戶，RPC API將要在某個(gè)時(shí)間內(nèi)發(fā)生變化，可能中間會有個(gè)過渡期，以避免出現(xiàn)問題。通過點(diǎn)到點(diǎn)的集成，就可以集成新的系統(tǒng)。

另一方面，當(dāng)用戶群非常龐大時(shí)，進(jìn)行點(diǎn)對點(diǎn)的溝通就不可能了，我們就需要一個(gè)不同的策略。我們需要一個(gè)預(yù)先安排的框架，以在服務(wù)器端和客戶端同時(shí)發(fā)生變化，還需要有一套明確的機(jī)制，與沒有相同API的系統(tǒng)實(shí)現(xiàn)互操作。RPC協(xié)議在這方面有所欠缺，改變其中的界面異常困難，集成新的服務(wù)通常需要進(jìn)行復(fù)雜的軟件粘合。

我認(rèn)為這是沒有企業(yè)成功地將它們的系統(tǒng)統(tǒng)一在DCOM、CORBA或RMI上的真正原因?，F(xiàn)在我們才觸及到問題的癥結(jié)所在：SOAP RPC是互聯(lián)網(wǎng)的DCOM。

RPC中還存在許多能夠解決的問題。但我認(rèn)為其中最大也是最難解決的問題是需要有一個(gè)使客戶端、服務(wù)器端和中間件端能夠獨(dú)立地進(jìn)行升級的模型。

原型可升級應(yīng)用

當(dāng)今二種最具可伸縮性、最具有互操作性的分布式應(yīng)用是Web和電子郵件，是什么使這二種應(yīng)用具有如此大的可伸縮性和互操作性呢？它們依賴于標(biāo)準(zhǔn)化的、可擴(kuò)展的消息格式（HTML和MIME）、應(yīng)用協(xié)議（HTTP和SMTP），但我認(rèn)為最重要的是每一種應(yīng)用都有一個(gè)標(biāo)準(zhǔn)化的、可擴(kuò)展的全球性地址系統(tǒng)。

在房地產(chǎn)界有一句笑話，形成房地產(chǎn)價(jià)值的三個(gè)要素是位置，位置和位置，在XML web服務(wù)中也是如此。如果實(shí)現(xiàn)得恰當(dāng)，XML web服務(wù)使我們能夠給數(shù)據(jù)對象指定地址，使它們能夠被共享或修改。

特別地，WEB的中心概念是URI的單一的統(tǒng)一名字空間，URI能夠允許使Web具有利用價(jià)值的大量的Web鏈接，它們將Web捆綁為一個(gè)單一的大規(guī)模的應(yīng)用。

URI等同于資源。資源是一個(gè)概念性的對象，它們的表達(dá)被以HTTP消息的格式在web上發(fā)布。這些理念相當(dāng)簡單，但其功能卻非常強(qiáng)大，而且取得了不俗的成功。URI之間的聯(lián)系非常松散，我們甚至能夠利用一張紙或OCR將一個(gè)URI從一個(gè)系統(tǒng)傳遞給另一個(gè)系統(tǒng)。URI是后期綁定的，它們不定義能夠?qū)λ傅男畔⑦M(jìn)行哪些處理。正是其具有的“松散”和“后期”特性，使得它們能夠適用于Web這樣規(guī)模的網(wǎng)絡(luò)。

不幸的是，我們中的大多數(shù)都不這樣考慮web服務(wù)，我們都將web服務(wù)看作是代表軟件組件的端點(diǎn)間的遠(yuǎn)程過程調(diào)用，也就是CORBA、DCOM的思想，Web的思想是根據(jù)資源組織URI。

新一代web服務(wù)將使用單獨(dú)的數(shù)據(jù)對象作為端點(diǎn)，軟件組件間的界線也將是非常小的。

一個(gè)示范性的例子

UDDI是能夠被作為以資源為中心的功能更強(qiáng)大的WEB服務(wù)的一個(gè)例子，在這里我們不討論UDDI在WEB服務(wù)中哲學(xué)意義上的角色，只討論如何從中獲取信息或向其中輸入信息的具體問題，這些觀點(diǎn)適用于已經(jīng)存在的大部分的WEB服務(wù)，例如股票行情、飛機(jī)票預(yù)訂等。

UDDI中有一個(gè)代表一個(gè)企業(yè)的businessEntity概念，企業(yè)是由UUID確定的，在以Web為中心的模式中，企業(yè)是由URI確定的，最簡單的方式是把businessEntity作為一個(gè)可以設(shè)定地址的XML文檔，例如，http://www.uddi.org/businessEntity/ibm.com或http://www.uddi.org/getbusinessEntity?ibm.com。這二種方式之間的差別相當(dāng)小，而且與技術(shù)的關(guān)系不大，因此我們無需為此擔(dān)心。

我們可以把http://www.uddi.org/businessEntity看作是一個(gè)包含文件的目錄，或者一個(gè)從數(shù)據(jù)庫中讀取數(shù)據(jù)的WEB服務(wù)。WEB最奇妙的特性之一就是僅僅通過URI，不能分辯出它到底是什么，這也是“松散組合”的作用。

我們來考慮使用基于HTTP的URI而不使用UUID表示企業(yè)實(shí)體的意義：

·想檢查企業(yè)實(shí)體的人只能將瀏覽器指向該URI，并查看businessEntity記錄，HTML版的企業(yè)實(shí)體只適用于以前的瀏覽器，而XML版的企業(yè)實(shí)體適用于較新的瀏覽器。

·要在另一種WEB服務(wù)或文檔中引用一個(gè)businessEntity，則只能使用它的URI。

·要將被引用的信息集成在其他的XML文檔中，可以使用XLink、XPointer或XInclude。

·要保存一個(gè)記錄的永久拷貝需要使用wget這樣的命令行工具或在瀏覽器中選擇“保存為”菜單項(xiàng)。

·XSLT樣式表能夠動態(tài)地獲取資源，并在轉(zhuǎn)換中與其他資源進(jìn)行組合。

·可以使用標(biāo)準(zhǔn)的HTTP授權(quán)和訪問控制機(jī)制控制對businessEntity的訪問。

·元數(shù)據(jù)可以通過使用RDF與businessEntity發(fā)生關(guān)聯(lián)。

·任何客戶端應(yīng)用（無論是否是基于瀏覽器的）可以在沒有特別的SOAP庫的情況下獲取數(shù)據(jù)。

·二個(gè)企業(yè)褓可以使用從一個(gè)企業(yè)實(shí)體到另一個(gè)企業(yè)實(shí)體的重定向表示二者的合并。

·象Excel、XMetaL、Word和Emacs這樣的編輯和分析工具能夠利用HTTP直接從URI中導(dǎo)入XML文檔，并利用WebDAV進(jìn)行回寫。

·UUID或其他形式的與位置無關(guān)的地址仍然可以被指定為附加的抽象層。

目前的UDDI API有一個(gè)被稱作get_businessDetail的方法，在以地址為中心的模式下，該方法就完全成為多余的了，可以從API中把它刪除了。UDDI有幾種對tModels、商業(yè)服務(wù)等數(shù)據(jù)對象進(jìn)行操作的get_方法，這些數(shù)據(jù)對象可以被表示為邏輯XML文檔，這些方法也可以被刪除。需要注意的是，我們大大簡化了用戶對UDDI信息的訪問，同時(shí)提高了XML和XML模式在UDDI系統(tǒng)中的重要性。

企業(yè)實(shí)體并不是UDDI中唯一的應(yīng)該根據(jù)以URI編址的XML資源而不是SOAP API確定的東西，事實(shí)上，所有UDDI數(shù)據(jù)庫中的數(shù)據(jù)都可以以這種方式確定。

總結(jié)：資源（數(shù)據(jù)對象）就象孩子，如果要融入到社會這個(gè)大家庭中去，他們每個(gè)人就需要有一個(gè)名字。

可擴(kuò)展性

如果圍繞URI組織WEB服務(wù)，該服務(wù)就可以通過鏈接自動地與其他WEB服務(wù)進(jìn)行集成，一個(gè)注冊表中的一個(gè)UDDI條目能夠很方便地指向另一個(gè)注冊表系統(tǒng)中的UDDI條目。事實(shí)上，企業(yè)可以在自己的站點(diǎn)上維護(hù)企業(yè)信息，在信息有變化時(shí)向UDDI“注冊”這些變化即可。以資源為中心的web服務(wù)從本質(zhì)上說是很容易進(jìn)行集成的。

在一個(gè)UDDI注冊表中的元素只可以在它們相互之間進(jìn)行查閱（也有極少數(shù)的例外），它們不能查閱到在Web上其他地方的對象（例如其他UDDI注冊表中的元素）。以URI為中心的解決方案則以與電話號碼系統(tǒng)組織電話那樣的方式對數(shù)據(jù)域進(jìn)行統(tǒng)一的組織。

由于businessEntity文檔都是XML文檔，因此能夠相對比較方便地添加元素、屬性或其他名字空間。XML是一種可擴(kuò)展的數(shù)據(jù)表達(dá)方式，通過添加特定的HTTP頭部甚至新的HTTP方法（在極少數(shù)的情況下）很方便地?cái)U(kuò)展該協(xié)議。

性能

WEB服務(wù)的性能是一個(gè)十分重要的問題，任何從基于GET的URI中獲取的資源都會被牽涉到，在服務(wù)器之前的緩沖服務(wù)器、企業(yè)防火墻或客戶端計(jì)算機(jī)都存在性能問題。緩沖是內(nèi)置在HTTP中的，SOAP get_businessDetail信息不能被現(xiàn)有的技術(shù)進(jìn)行緩沖，對REST架構(gòu)還可以進(jìn)行其他方面的性能強(qiáng)化。

其他方法

UDDI中還有其他與businessEntities有關(guān)的方法，其中的一個(gè)是delete_business。HTTP已經(jīng)有了DELETE方法，因此delete_business在REST模式中已經(jīng)是多余的了，我們可以不使用UDDI SOAP-RPC的刪除方法，而使用HTTP中的刪除方法，這樣有利于與“知道”HTTP中刪除方法的Windows 2000中的資源管理器等工具兼容。從理論上說，企業(yè)可以通過點(diǎn)擊“刪除”按鈕刪除一部分的記錄。

很明顯的是，授權(quán)和訪問控制是關(guān)健。微軟不可能抹殺它的競爭對手在這方面的進(jìn)步。HTTTP中已經(jīng)有了授權(quán)、認(rèn)證和加密的特性，UDDI的SOAP RPC協(xié)議不支持這些特性。

UDDI中還有一個(gè)save_business方法，這是為了上載新的業(yè)務(wù)，在HTTP中與之相對應(yīng)的是PUT或POST。使用HTTP方法而不使用SOAP方法的一個(gè)好處是可以在HTML表格中執(zhí)行POST方法。

UDDI中還包括有一個(gè)名字為find_business的方法，該方法在原理上與每個(gè)網(wǎng)站上的搜索功能或特定的搜索引擎并沒有什么區(qū)別。在URI模式中，服務(wù)能夠獲取一系列的搜索參數(shù)，返回代表與搜索參數(shù)匹配的businessEntities。

使用GET、PUT、DELETE、POST這四個(gè)基本的方法，我們可以做到使用幾十個(gè)UDDI方法才能實(shí)現(xiàn)的功能。REST于WEB服務(wù)的關(guān)系就象RISC技術(shù)與CPU的關(guān)系，但二者之間的關(guān)系還是有相當(dāng)大的區(qū)別的，其代價(jià)和帶來的好處是不同的。

HTTP的角色

我們通過WEB服務(wù)得到的好處利用HTTP也可以得到，我們需要的僅僅是XML符號集，這也是XML的意義所在：更注重?cái)?shù)據(jù)的交換而不是軟件組件。

UDDI中的所有東西都可以用HTTP對XML資源的操作表示，因此，HTTP與URI成為Web中最核心的技術(shù)之一并不是偶然的，它的設(shè)計(jì)目標(biāo)是作為以特性為中心的REST架構(gòu)的主要部分。

下面是一個(gè)很激進(jìn)的觀點(diǎn)：無論什么樣的問題，我們都可以，也應(yīng)該將它作為一個(gè)數(shù)據(jù)資源處理問題而不是一個(gè)API設(shè)計(jì)問題來考慮，將web服務(wù)器考慮為一個(gè)巨大的信息倉庫，我們在其中進(jìn)行數(shù)據(jù)處理工作。

在討論UDDI時(shí)，我選擇了一個(gè)能夠被很簡單地轉(zhuǎn)換為REST架構(gòu)的web服務(wù)，但我們可以將這一原理應(yīng)用在所有的web服務(wù)中。那么在訂單提交中如何呢？這更象是事務(wù)，訂單也需要被命名。如果我們使用POST或PUT將訂單提交給新的URI，然后整個(gè)公司的內(nèi)部系統(tǒng)都可以查閱該訂單，而無論系統(tǒng)是在什么地方。使用HTTP，北京分公司雇員使用的臺式機(jī)上的XSLT樣式表和Perl腳本代碼能夠處理在位于洛杉磯的大型主機(jī)上運(yùn)行的財(cái)務(wù)系統(tǒng)上的訂單。訪問HTTP編址的資源不比訪問本地系統(tǒng)上的文件更困難。

即使是帶有復(fù)雜的工作流的WEB服務(wù)也可以以URI為中心的方式進(jìn)行組織。現(xiàn)在我們來看一個(gè)飛機(jī)票預(yù)訂系統(tǒng)。在傳統(tǒng)的HTML系統(tǒng)中，有各種不同的代表邏輯交易的網(wǎng)頁存在。首先，我們需要捍拒合適的航班，得到一個(gè)表示許多合適航班的URI。然后從中選擇一個(gè)航班，得到一個(gè)表示我們選擇的URI。然后再決定是否提交訂單，提交后會得到返回預(yù)訂號的網(wǎng)頁。一般情況下，該網(wǎng)頁的URI會保留一段合理的時(shí)間，以便我們記下預(yù)訂的號碼。我們可以以這種方式來考慮所有的業(yè)務(wù)。

HTTP甚至可以應(yīng)用在P2P、異步、可靠的分布式計(jì)算中，如果讀者對這些問題有興趣，可以進(jìn)一步地參閱其他的資料。

基于XML的web服務(wù)能夠通過相同的步驟完成。不會在每個(gè)步驟中返回HTML表格，該web服務(wù)將返回符合航空業(yè)標(biāo)準(zhǔn)的XML文檔，這些文檔可以用在完全不同的飛機(jī)票預(yù)訂系統(tǒng)中，運(yùn)行完全相同的過程。

總結(jié)：任何商業(yè)問題都可以被看作是資源處理問題，HTTP是一種數(shù)據(jù)資源處理協(xié)議。

安全

對數(shù)據(jù)進(jìn)行全球統(tǒng)一的編址并不意味著讓所有人都可以訪問你的數(shù)據(jù)。我們可以通過不公布其URI而很方便地隱藏對象，也可以很方便地對對象使用安全策略。事實(shí)上，REST在很大程度上簡化了安全問題。

在SOAP RPC模式中，我們使用的對象是不明顯的，它們的名字也隱藏在方法的參數(shù)中，因此我們需要為每個(gè)web服務(wù)使用一種全新的安全策略。在REST模式中，我們可以對每個(gè)數(shù)據(jù)對象使用4種基本的權(quán)限：GET權(quán)限、PUT權(quán)限、DELETE權(quán)限和POST權(quán)限。我們可以使一部分資源具有或不具有GET、PUT、DELETE和POST四種權(quán)限，這與當(dāng)前廣泛使用的文件系統(tǒng)的權(quán)限有點(diǎn)類似，它是有效和成熟的。

以資源為中心的web服務(wù)可以很好地與防火墻進(jìn)行合作。防火墻管理員能夠很容易地通過阻止不使用GET方法的HTTP請求而使一種web服務(wù)只能被讀取。

維護(hù)

事實(shí)上，安全只是可維護(hù)性的一種形式。所有網(wǎng)管都會說，任何規(guī)模的網(wǎng)絡(luò)都會發(fā)生問題，有時(shí)IP沒有問題但DNS就會出問題（DNS服務(wù)器關(guān)閉或DNS配置不正確），有時(shí)IP和DNS正常但HTTP出了問題（防火墻或代理服務(wù)器配置不正確）。如果在HTTP之上運(yùn)行WEB服務(wù)，那系統(tǒng)出問題的可能性就是二者之和，可能會有多個(gè)部分出問題和安全漏洞。

一旦WEB服務(wù)能夠正常地工作了，則可以通過在瀏覽器中使用服務(wù)對它進(jìn)行測試，甚至是復(fù)雜的需要多個(gè)步驟才能完成的web服務(wù)都能夠通過HTML表格進(jìn)行測試。從本質(zhì)上說，對REST web服務(wù)的測試與web網(wǎng)站差不多。另一方面，每個(gè)SOAP RPC服務(wù)都有自己的安全模式、地址模型、數(shù)據(jù)模型、狀態(tài)轉(zhuǎn)換表和方法集，對這樣的系統(tǒng)進(jìn)行測試要困難得多。