Web服務(wù)內(nèi)幕，第10部分：深入主題：可靠性和事務(wù)

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

Web服務(wù)內(nèi)幕，第10部分：深入主題：可靠性和事務(wù)

James Snell（jasnell@us.ibm.com）

軟件 工程師，IBM Software Group

2001 年 11 月

就本質(zhì)而言，Web 服務(wù)體系結(jié)構(gòu)是應(yīng)用程序通過智能的消息交換相互進(jìn)行集成的 方法。對(duì)于企業(yè)，這意味著關(guān)鍵業(yè)務(wù)信息（比如：訂購單、合同以及報(bào)價(jià)索?。≧FQ））的交換。由 于這種信息的關(guān)鍵性本質(zhì)，企業(yè)必須確保底層消息傳遞體系結(jié)構(gòu)的可靠性。在 Web 服務(wù)內(nèi)幕的這篇 文章中，James Snell 繼續(xù)他的關(guān)于影響在企業(yè)中使用 Web 服務(wù)的問題的討論，側(cè)重于可靠的消息傳遞和事務(wù)。

在 Web 服務(wù)內(nèi)幕的前一篇文章中，我邀請(qǐng)了 Maryann Hondo — IBM 的 Web 服務(wù)安全標(biāo)準(zhǔn)的領(lǐng)導(dǎo)者，來幫助我通覽了一遍各種安全性和保密性問題，這是使用 Web 服務(wù)的企業(yè)開發(fā)者必須考慮的。在這篇文章中，我將花些時(shí)間來探索企業(yè)中對(duì) Web 服務(wù)的其它兩個(gè)關(guān)鍵性要求：可靠性和事務(wù)。該討論將分成三部分：

a. 可靠的消息傳遞的討論

b. 有條件的消息傳遞的討論

c. 稱為相關(guān)性環(huán)境的新的類型的事務(wù)管理機(jī)制的介紹

可靠的消息傳遞

“可靠的消息傳遞”的簡(jiǎn)單定義是確保消息的發(fā)送方和接收方都知道消息是不是確實(shí)被發(fā)送或接收了，此外要確保消息一次發(fā) 送給目標(biāo)接收方，且只能是一次。很簡(jiǎn)單？是的。容易實(shí)現(xiàn)？并不是這樣。

從一開始，可靠的消息傳遞所存在的問題一直是困擾因特網(wǎng)應(yīng)用程序開發(fā)的問題。究其本質(zhì)，因特網(wǎng)本身就是不 可靠的。服務(wù)器在某一時(shí)刻啟動(dòng)并運(yùn)行，但是可能在另一時(shí)刻當(dāng)機(jī)。用來連接發(fā)送方和接收方的 協(xié)議并沒有設(shè)計(jì)成支持可靠的消息傳遞構(gòu)造，諸如：消息標(biāo)識(shí)符和確認(rèn)。消息的接收方必須能夠確 認(rèn)這樣一個(gè)事實(shí)，即實(shí)際上他們已經(jīng)確確實(shí)實(shí)接收到了消息。萬一沒有接收到確認(rèn)并且需要再次發(fā)送消息時(shí)，消息的發(fā)送方必須能夠高速緩存那些消息。今天推動(dòng)因特網(wǎng)的基本技術(shù) 不支持這樣的機(jī)制。因此，迫使開發(fā)者去實(shí)現(xiàn)新的協(xié)議、新的技術(shù)，從而滿足這些需要。

現(xiàn)在，很明顯，可靠的消息傳遞不是新的問題；也不是開發(fā)者現(xiàn)在才努力去解決的問題。源 自眾多技術(shù)供應(yīng)商的許多現(xiàn)有產(chǎn)品以一種或另一種形式實(shí)現(xiàn)可靠的消息傳遞。問題是 — 這是我繼 續(xù)這篇 Web 服務(wù)討論的關(guān)鍵點(diǎn) — 目前還沒有可采納的可靠的消息傳遞的解決方案，可以容易地與其它解決方案進(jìn) 行交互操作。為了解決這個(gè)問題，IBM 所采取的方法為：并不是定義一個(gè)可靠的消息傳遞應(yīng)用，而 是定義另一個(gè)標(biāo)準(zhǔn)化的、與應(yīng)用無關(guān)的可靠的消息傳遞協(xié)議，它基于廣泛存在的超文本傳輸 協(xié)議（HTTP）。

HTTP 不是可靠的協(xié)議，這是很顯而易見的。以下面的方案作為實(shí)例。這些內(nèi)容最初在 7 月 developerWorks 網(wǎng)站上發(fā)表的“HTTPR 概述”中討論過（請(qǐng)參閱參考資料）。

圖 1：同步的、不可靠的消息傳遞

圖 1 展示了典型的 HTTP 請(qǐng)求／響應(yīng)流程?，F(xiàn)在，請(qǐng)考慮一下出現(xiàn) 在第 1 步和第 2 步（由紅色的圓點(diǎn)標(biāo)注）之間的某種類型的通信故障。請(qǐng)求方將只知道出現(xiàn)了連接錯(cuò)誤 ，但不知道請(qǐng)求是否曾傳給了響應(yīng)方、應(yīng)不應(yīng)該回滾請(qǐng)求、響應(yīng)方能不能處理這個(gè)消息或 者響應(yīng)是不是僅僅是在返回給請(qǐng)求方的途中被中斷。對(duì)于那些在線購物的人來說，這恰恰是為什么 會(huì)看到這樣的警告：不要多次按提交按鈕，否則您的信用卡上將會(huì)多次計(jì)費(fèi)的原因。

HTTPR 增強(qiáng)了 HTTP，在 HTTPR 中它添加了必需的元素來消除或者說至少可以減少在請(qǐng)求／響應(yīng)過程中出現(xiàn)任何類 型的故障時(shí)隨之產(chǎn)生的懷疑程度。HTTPR 工作原理超出了本文討論的范圍。相反，我將向 您推薦早些時(shí)候發(fā)布在 developerWorks 網(wǎng)站的“HTTPR 概述”（請(qǐng)參閱參 考資料）以及“HTTPR 規(guī)范”（請(qǐng)參閱參考資料），以獲取關(guān)于 HTTPR 如何發(fā)揮作用的詳細(xì)的技術(shù)信息。而下面的圖 2 說 明了 HTTPR 怎么可以改變上圖所示的請(qǐng)求／響應(yīng)事務(wù)流程，從而實(shí)現(xiàn)可靠的消息傳遞。

圖 2：異步的、可靠的消息傳遞

您可能要問的主要問題是 HTTPR 為什么是“可靠的 HTTP”？為什么將 HTTP 用作可靠消息傳遞協(xié)議的基礎(chǔ)？回答是：這僅僅是因?yàn)?HTTP 已有的廣泛的部署基礎(chǔ)。Web 服務(wù)是因特網(wǎng)技術(shù)漸進(jìn)發(fā)展的結(jié)果。沒有必要去重新開發(fā)不需要重新開發(fā)的東西。將可靠的消息傳遞建立在 HTTP 基礎(chǔ)上，將允許已經(jīng)對(duì) Web 服務(wù)器技術(shù)的投資的公司利用可靠的消息傳遞性能，同時(shí)繼續(xù)利用已有的投資。作為 HTTP 的擴(kuò)展，HTTPR 也能利用 HTTP 安全性、會(huì)話、代理、防火墻支持等設(shè)施。

有條件的消息傳遞

與可靠的消息傳遞概念緊密相關(guān)的是有條件的消息傳遞，它涉及到各種條件的建立，這些條件用于確定怎 樣以及什么時(shí)候傳遞消息。例如，10,000 臺(tái) ThinkPad 膝上電腦的報(bào)價(jià)可能只在收到報(bào)價(jià)后 10 天 內(nèi)有效。另一個(gè)示例可以表述為：只允許某些人查看消息內(nèi)所包含的信息，其中所涉及的內(nèi)容可以 鏈接到以前的關(guān)于安全性和保密性的討論。（請(qǐng)參閱參考資料。）

有條件的消息傳遞是基于規(guī)則的可靠的消息傳遞。一般情況下，這些規(guī)則總是在應(yīng)用層實(shí)現(xiàn)。直 到現(xiàn)在，表達(dá)消息條件事實(shí)上還沒有一個(gè)一致的方法，以便們可以應(yīng)用于中間件層。對(duì) Web 服 務(wù)來說，這種概念將作為企業(yè)中啟用 Web 服務(wù)的關(guān)鍵因素出現(xiàn) — 允許公司在定義的約束和條件下動(dòng)態(tài)地集成 業(yè)務(wù)過程。

事務(wù)和相關(guān)性環(huán)境

因特網(wǎng)開發(fā)的一個(gè)典型的長(zhǎng)期存在的爭(zhēng)論是：是否需要兩階段提交方式的 Web 事務(wù)。如果需要，究竟怎樣實(shí)現(xiàn)它。簡(jiǎn)單的、卻相反的回答是：不，不需要。傳統(tǒng)的兩階段提交不適于 Web 服務(wù)，對(duì)于這個(gè)問題的解釋，我贊同 ActiveState's ASPN 站點(diǎn)（由 Walter Perry 主持）上的關(guān)于該問題的精彩討論（請(qǐng)參閱參考資料）。

IBM 的研究小組提出了實(shí)現(xiàn)分布式事務(wù)的另一種途徑。這種實(shí)現(xiàn)途徑稱為相關(guān)性環(huán)境，在最近提交給“企業(yè)分布式對(duì)象計(jì)算會(huì)議”（Enterprise Distributed Object Computing（EDOC）Conference）（9 月初在西雅圖舉行）的論文中討論了。

相關(guān)性環(huán)境是新的類型的事務(wù)環(huán)境，它允許在單個(gè)事務(wù)中交換出現(xiàn)同步和異步分布式消 息傳遞風(fēng)格。這究竟意味著什么？那么，來看一看一個(gè)示例方案，這是在 IBM 研究人員呈交給 EDOC 會(huì) 議的論文中所提出的（請(qǐng)參閱參考資料）。

“Web 站點(diǎn)的訪問者開了一個(gè)新的帳戶，在此之后必須在兩個(gè)不同的分布式舊系統(tǒng)中創(chuàng)建 ：用于帳戶管理的 ERP 數(shù)據(jù)庫和用于客戶支持的 CRM 數(shù)據(jù)庫。以實(shí)體 EJB 實(shí)現(xiàn)到 ERP 數(shù) 據(jù)庫的接口，但是訪問 CRM 數(shù)據(jù)庫必須通過 JMS/MQ 消息傳遞接口。難題在于以單個(gè)分布式事 務(wù)怎樣在 ERP 和 CRM 數(shù)據(jù)庫中完成兩個(gè)帳戶的創(chuàng)建?！?— Stefan Tai 等人 所著的 Dependency-Spheres: A Global Transaction Context for Distributed Objects and Messages。

該論文繼續(xù)指出：目前絕對(duì)沒有能支持這種類型事務(wù)的中間件支持。您可以進(jìn)一步深入，設(shè)想 CRM 和 ERP 應(yīng)用都遠(yuǎn)程地托管基于 SOAP 的 Web 服務(wù)（用 WSDL 描述），一個(gè)使用 EJB 托管在 WebSphere 環(huán)境，另一個(gè)托管在 Microsoft.NET 的環(huán)境?，F(xiàn)在，由于現(xiàn)有的基礎(chǔ)架構(gòu)這種問 題完全不可能解決。

相關(guān)性環(huán)境解決了這個(gè)問題。作為第三方 Web 服務(wù)建立，相關(guān)性環(huán)境可以提供必需的事務(wù)環(huán)境，確保上面示例中的兩個(gè)帳戶的創(chuàng)建操作即使是在分布式的異種環(huán)境中都能進(jìn)行，并且 正確地進(jìn)行。我不打算詳細(xì)地解釋相關(guān)性環(huán)境怎樣工作，關(guān)于這些內(nèi)容，請(qǐng)參閱由 IBM 從 事該領(lǐng)域研究的研究小組成員所撰寫的精彩論文。（請(qǐng)參閱參 考資料。）

這種方法很大程度上依賴于其中的可靠的和有條件的消息傳遞原則，為了確定給定的事務(wù)是成功還是失敗 ，必須監(jiān)控消息傳遞，從而確保能夠恰當(dāng)處理應(yīng)用于消息傳遞和處理的規(guī)則。

現(xiàn)在，必須指出相關(guān)性環(huán)境仍然是一個(gè)研究項(xiàng)目，至少就這一點(diǎn)來說，它并不是在 Web 服務(wù)體 系結(jié)構(gòu)內(nèi)實(shí)現(xiàn)事務(wù)的唯一最有效和最有價(jià)值的方法。但是，對(duì)于怎樣在分布式的 Web 服務(wù)環(huán)境 中實(shí)現(xiàn)事務(wù)這個(gè)難題，它有希望給出一些可靠的回答。

下一步是什么？

下面我所列出的參考資料將給您研究 Web 服務(wù)中可靠的的消息傳遞、有條件的消息傳遞以及事務(wù)支持提供充 足的背景資料。要在 Web 服務(wù)中實(shí)施可靠的消息傳遞，我建議您從 IBM 的 alphaWorks 站點(diǎn)下載 最新版本的 Web Services ToolKit（版本 2.4）。樣本示例中包含 HTTPR 協(xié)議演示。

參考資料