第二代Web服務展望

申請免費試用、咨詢電話：400-8352-114

第二代Web服務展望

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

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

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

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

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

當前的Web服務

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

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

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

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

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

原型可升級應用

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

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

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

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

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

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

一個示范性的例子

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

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

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

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

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

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

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

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

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

·可以使用標準的HTTP授權和訪問控制機制控制對businessEntity的訪問。

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

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

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

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

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

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

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

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

可擴展性

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

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

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

性能

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

其他方法

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

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

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

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

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

HTTP的角色

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

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

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

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

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

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

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

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

安全

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

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

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

維護

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

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