第二代Web服務展望 [轉]

來源:互聯網
上載者:User
web|web服務  
  在互連網發展的早期,企業都使用SMTP、NTTP和FTP用戶端和伺服器與互連網進行串連,傳輸訊息、文字檔、可執行檔和原始碼,當企業開始將公司資訊整合到互連網架構中時,互連網就成了一種基本的工具。當互連網重心由交換資訊的協議轉向資料對象以及它們之間的連結時,互連網的普及程度就大大提高了。
早期Web架構的特徵是HTML-GIF/JPEG、HTTP和URI,它們組合在一起時,其功能是異常強大的,使用這些技術,企業將多種多樣的網上發布系統進行整合,使之成為比任何一種單一的技術更有吸引力的系統。

  一旦各種機構都使用公用的資料格式、HTTP協議和一個單一的地址系統時,Web就不再是許多網站的集合了,而成為了最多樣化和功能強大的資訊系統,各機構團體建立起它們的資訊和其他機構團體資訊之間的連結。

  第一代Web服務與第一代串連非常相似,各種Web服務之間並不是互相整合的,而且其設計目標也不是使第三方能夠方便地以一種統一的方式對它們進行整合。我認為,新一代Web服務將是起源於網上出版和人機互動的更加整合化的Web服務,它將是建立在使Web更能發揮作用的架構的基礎上的,該架構是三位一體的:標準的格式(XML)、標準的應用協議和單一的URI名字空間。

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

  當前的Web服務

  SOAP最初是作為DCOM或CORBA的跨互連網形式出現的,早期的與SOAP類似的一種技術的名稱為“Web代理”━━基於Web的對象代理,它準確地表達了這種技術在DCOM、CORBA、RMI等標準上建立跨應用協議的含義,它也是解決應用之間互通性問題的現有的模型。

  在沒有應用到Web上時,這些技術只取得了有限的成功。有分析家認為問題是微軟和OMG的支援者不合作引起的,但我並不這樣認為,其中有更深層次的問題。對於封閉世界問題而言,RPC確實不錯。在封閉世界中,你知道所有的使用者,可以與它們共用資料模型,可以根據自己的需求與它們進行溝通。在這樣的環境中進行發展是相當容易的:你只需告訴所有的使用者,RPC API將要在某個時間內發生變化,可能中間會有個過渡期,以避免出現問題。通過點到點的整合,就可以整合新的系統。

  另一方面,當使用者群非常龐大時,進行點對點的溝通就不可能了,我們就需要一個不同的策略。我們需要一個預先安排的架構,以在伺服器端和用戶端同時發生變化,還需要有一套明確的機制,與沒有相同API的系統實現互操作。RPC協議在這方面有所欠缺,改變其中的介面異常困難,整合新的服務通常需要進行複雜的軟體粘合。

  我認為這是沒有企業成功地將它們的系統統一在DCOM、CORBA或RMI上的真正原因。現在我們才觸及到問題的癥結所在:SOAP RPC是互連網的DCOM。

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

  原型可升級應用

  當今二種最具延展性、最具有互通性的分布式應用是Web和電子郵件,是什麼使這二種應用具有如此大的延展性和互通性呢?它們依賴於標準化的、可擴充的訊息格式(HTML和MIME)、應用協議(HTTP和SMTP),但我認為最重要的是每一種應用都有一個標準化的、可擴充的全球性地址系統。

  在房地產界有一句笑話,形成房地產價值的三個要素是位置,位置和位置,在XML web服務中也是如此。如果實現得恰當,XML web服務使我們能夠給資料對象指定地址,使它們能夠被共用或修改。

  特別地,WEB的中心概念是URI的單一的統一名字空間,URI能夠允許使Web具有利用價值的大量的Web連結,它們將Web捆綁為一個單一的大規模的應用。

  URI等同於資源。資源是一個概念性的對象,它們的表達被以HTTP訊息的格式在web上發布。這些理念相當簡單,但其功能卻非常強大,而且取得了不俗的成功。URI之間的聯絡非常鬆散,我們甚至能夠利用一張紙或OCR將一個URI從一個系統傳遞給另一個系統。URI是後期綁定的,它們不定義能夠對所指的資訊進行哪些處理。正是其具有的“鬆散”和“後期”特性,使得它們能夠適用於Web這樣規模的網路。

  不幸的是,我們中的大多數都不這樣考慮web服務,我們都將web服務看作是代表軟體組件的端點間的遠端程序呼叫,也就是CORBA、DCOM的思想,Web的思想是根據資源群組織URI。

  新一代web服務將使用單獨的資料對象作為端點,軟體組件間的界線也將是非常小的。

  一個示範性的例子

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

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

  我們可以把http://www.uddi.org/businessEntity看作是一個包含檔案的目錄,或者一個從資料庫中讀取資料的WEB服務。WEB最奇妙的特性之一就是僅僅通過URI,不能分辯出它到底是什麼,這也是“鬆散組合”的作用。

  我們來考慮使用基於HTTP的URI而不使用UUID表示企業實體的意義:

  ·想檢查企業實體的人只能將瀏覽器指向該URI,並查看businessEntity記錄,HTML版的企業實體只適用於以前的瀏覽器,而XML版的企業實體適用於較新的瀏覽器。

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

  ·要將被引用的資訊整合在其他的XML文檔中,可以使用XLink、XPointer或XInclude。

  ·要儲存一個記錄的永久拷貝需要使用wget這樣的命令列工具或在瀏覽器中選擇“儲存為”功能表項目。

  ·XSLT樣式表能夠動態地擷取資源,並在轉換中與其他資源進行組合。

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

  ·中繼資料可以通過使用RDF與businessEntity發生關聯。

  ·任何用戶端應用(無論是否是基於瀏覽器的)可以在沒有特別的SOAP庫的情況下擷取資料。

  ·二個企業褓可以使用從一個企業實體到另一個企業實體的重新導向表示二者的合并。

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

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

  目前的UDDI API有一個被稱作get_businessDetail的方法,在以地址為中心的模式下,該方法就完全成為多餘的了,可以從API中把它刪除了。UDDI有幾種對tModels、商務服務等資料對象進行操作的get_方法,這些資料對象可以被表示為邏輯XML文檔,這些方法也可以被刪除。需要注意的是,我們大大簡化了使用者對UDDI資訊的訪問,同時提高了XML和XML模式在UDDI系統中的重要性。

  企業實體並不是UDDI中唯一的應該根據以URI編址的XML資源而不是SOAP API確定的東西,事實上,所有UDDI資料庫中的資料都可以以這種方式確定。

  總結:資源(資料對象)就象孩子,如果要融入到社會這個大家庭中去,他們每個人就需要有一個名字。

  可擴充性

  如果圍繞URI組織WEB服務,該服務就可以通過連結自動地與其他WEB服務進行整合,一個註冊表中的一個UDDI條目能夠很方便地指向另一個註冊表系統中的UDDI條目。事實上,企業可以在自己的網站上維護公司資訊,在資訊有變化時向UDDI“註冊”這些變化即可。以資源為中心的web服務從本質上說是很容易進行整合的。

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

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

  效能

  WEB服務的效能是一個十分重要的問題,任何從基於GET的URI中擷取的資源都會被牽涉到,在伺服器之前的緩衝伺服器、企業防火牆或用戶端電腦都存在效能問題。緩衝是內建在HTTP中的,SOAP get_businessDetail資訊不能被現有的技術進行緩衝,對REST架構還可以進行其他方面的效能強化。

  其他方法

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

  很明顯的是,授權和存取控制是關健。微軟不可能抹殺它的競爭者在這方面的進步。HTTTP中已經有了授權、認證和加密的特性,UDDI的SOAP RPC協議不支援這些特性。

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

  UDDI中還包括有一個名字為find_business的方法,該方法在原理上與每個網站上的搜尋功能或特定的搜尋引擎並沒有什麼區別。在URI模式中,服務能夠擷取一系列的搜尋參數,返回代表與搜尋參數匹配的businessEntities。

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

  HTTP的角色

  我們通過WEB服務得到的好處利用HTTP也可以得到,我們需要的僅僅是XML符號集,這也是XML的意義所在:更注重資料的交換而不是軟體組件。

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

  下面是一個很激進的觀點:無論什麼樣的問題,我們都可以,也應該將它作為一個資料資源處理問題而不是一個API設計問題來考慮,將web伺服器考慮為一個巨大的資訊倉庫,我們在其中進行資料處理工作。

  在討論UDDI時,我選擇了一個能夠被很簡單地轉換為REST架構的web服務,但我們可以將這一原理應用在所有的web服務中。那麼在訂單提交中如何呢?這更象是事務,訂單也需要被命名。如果我們使用POST或PUT將訂單提交給新的URI,然後整個公司的內部系統都可以查閱該訂單,而無論系統是在什麼地方。使用HTTP,北京分公司僱員使用的台式機上的XSLT樣式表和Perl指令碼代碼能夠處理在位於洛杉磯的大型主機上啟動並執行財務系統上的訂單。訪問HTTP編址的資源不比訪問本地系統上的檔案更困難。

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

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

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

  總結:任何商業問題都可以被看作是資源處理問題,HTTP是一種資料資源處理協議。

  安全

  對資料進行全球統一的編址並不意味著讓所有人都可以訪問你的資料。我們可以通過不公布其URI而很方便地隱藏對象,也可以很方便地對對象使用安全性原則。事實上,REST在很大程度上簡化了安全問題。

  在SOAP RPC模式中,我們使用的對象是不明顯的,它們的名字也隱藏在方法的參數中,因此我們需要為每個web服務使用一種全新的安全性原則。在REST模式中,我們可以對每個資料對象使用4種基本的許可權:GET許可權、PUT許可權、DELETE許可權和POST許可權。我們可以使一部分資源具有或不具有GET、PUT、DELETE和POST四種許可權,這與當前廣泛使用的檔案系統的許可權有點類似,它是有效和成熟的。

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

  維護

  事實上,安全只是可維護性的一種形式。所有網管都會說,任何規模的網路都會發生問題,有時IP沒有問題但DNS就會出問題(DNS伺服器關閉或DNS配置不正確),有時IP和DNS正常但HTTP出了問題(防火牆或Proxy 伺服器配置不正確)。如果在HTTP之上運行WEB服務,那系統出問題的可能性就是二者之和,可能會有多個部分出問題和安全性漏洞。

  一旦WEB服務能夠正常地工作了,則可以通過在瀏覽器中使用服務對它進行測試,甚至是複雜的需要多個步驟才能完成的web服務都能夠通過HTML表格進行測試。從本質上說,對REST web服務的測試與web網站差不多。另一方面,每個SOAP RPC服務都有自己的安全模式、地址模型、資料模型、狀態轉換表和方法集,對這樣的系統進行測試要困難得多。




相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。