可靠的 XML Web Service （1）

2024-09-05 20:55:53

字體：大中小

供稿：網(wǎng)友

國內(nèi)最大的酷站演示中心!
可靠的 xml web service
eric schmidt
microsoft corporation，xml core services 組，項(xiàng)目經(jīng)理
2001 年 12 月 11 日

下載此專欄的示例代碼。

注意：要下載與本文相關(guān)的代碼，您需要：
visual studio .net release candidate（英文）
sql server 2000（英文）
在 pdc 上，我談?wù)摿擞嘘P(guān)可靠的 xml web service（web 服務(wù)）的話題，這個(gè)話題源于過去一年來的多次交流。在有關(guān)建立 xml web service 的眾多常見問題中，可靠性問題是開發(fā)人員實(shí)現(xiàn)分散式 web 服務(wù)所面臨的五個(gè)最重要的問題之一。如果分開來講，這個(gè)問題并不是太難，因此，本月我準(zhǔn)備談一談建立可靠的 xml web service 這一棘手的問題。

概述
global xml web services architecture（gxa [英文]）最突出的一面就是可以使用可合成處理協(xié)議擴(kuò)展該體系結(jié)構(gòu)。這些協(xié)議主要通過 soap 標(biāo)頭實(shí)現(xiàn)，可以提供包括安全性、加密、路由和可靠性的廣泛服務(wù)。當(dāng)您開始構(gòu)建基于 gxa 的應(yīng)用程序時(shí)，您將發(fā)現(xiàn) gxa 實(shí)質(zhì)上是一種消息處理體系結(jié)構(gòu)，它通過基于標(biāo)準(zhǔn)的編碼技術(shù) (soap) 在系統(tǒng)和服務(wù)之間提供協(xié)同工作能力。到目前為止，大部分實(shí)現(xiàn)工作都集中在 soap 1.1 和 wsdl 兼容服務(wù)上，因此 web 服務(wù)實(shí)現(xiàn)方案可以與多種語言和操作系統(tǒng)協(xié)同工作。

這是一個(gè)了不起的概念。任何兩個(gè)系統(tǒng)之間都能夠進(jìn)行交流，只要它們能夠分析 xml 并理解 soap 規(guī)范的規(guī)則。但是，簡單的消息交換并不能滿足復(fù)雜的業(yè)務(wù)應(yīng)用程序的需要。真正的應(yīng)用程序（不管其內(nèi)部域體系結(jié)構(gòu)如何）均需要標(biāo)準(zhǔn)化的服務(wù)，例如處于 web 服務(wù)消息處理層上的安全性、授權(quán)和可靠性。在 global xml web services architecture（具體地說就是 soap、soap 模塊和基礎(chǔ)結(jié)構(gòu)協(xié)議）的創(chuàng)建和實(shí)現(xiàn)背后有一個(gè)巨大的動力。隨著今年十月份四項(xiàng)新規(guī)范（ws-routing、ws-referral、ws-licensing 和 ws-security）的發(fā)布，我們已經(jīng)開始著手下一代 xml web service 實(shí)現(xiàn)工作。盡管發(fā)布了這么多的新規(guī)范，但仍有兩個(gè)領(lǐng)域尚無公共規(guī)范，即事務(wù)處理和可靠的消息處理，這主要是因?yàn)檫@些基礎(chǔ)結(jié)構(gòu)協(xié)議依賴于底層 soap 模塊。

本專欄主要從 gxa 環(huán)境的角度討論可靠性和可靠的消息處理的含義。而且我還要花一些時(shí)間探討通過在 .net 框架中擴(kuò)展現(xiàn)有 web 服務(wù)類來開發(fā)可靠性協(xié)議需要做些什么。本專欄有兩個(gè)主要目的：

讓讀者了解可靠性概念，為以后各種規(guī)范的實(shí)施做好準(zhǔn)備。請注意，本文不是規(guī)范，而只是一篇文章，旨在引發(fā)讀者思考下面要討論的問題。
說明 .net 框架中 web 服務(wù)和 soap 類強(qiáng)大的、基于標(biāo)準(zhǔn)的功能。
xml web service 的可靠性
我們把問題分開來講。我們前面講過，gxa 服務(wù)實(shí)現(xiàn)方案屬于消息處理服務(wù)，它們需要在分散式環(huán)境中發(fā)送和接收基于標(biāo)準(zhǔn)的編碼消息。在 web 服務(wù)實(shí)現(xiàn)方案中發(fā)送 soap 消息的主要傳輸協(xié)議是 http，它易于實(shí)現(xiàn)和管理，但本身不可靠。我們無需深入探討 http 不可靠的具體原因，但只要知道 http 沒有基于標(biāo)準(zhǔn)的服務(wù)來保證終點(diǎn)或服務(wù)器能夠接收到請求就足夠了。盡管內(nèi)置的網(wǎng)絡(luò)層設(shè)備可以在發(fā)生一般災(zāi)難性故障（例如未找到資源）時(shí)產(chǎn)生錯(cuò)誤，但是卻沒有機(jī)制可以確保客戶端能夠以可靠的方式接收請求或響應(yīng)。

通常是通過簡單的重新發(fā)送操作處理 http 故障，但在業(yè)務(wù)處理環(huán)境中這既不利于提高效率也沒有效果。它導(dǎo)致不必要的通信量，并增加了重復(fù)交易的風(fēng)險(xiǎn)。

目前市場上有多種能夠更有效解決此問題的消息處理技術(shù)，包括傳輸協(xié)議（如 httpr）、企業(yè)基礎(chǔ)結(jié)構(gòu)（如 msmq 和 mq series）以及業(yè)務(wù)處理協(xié)議（如 ebxml）。盡管每種技術(shù)針對特定的實(shí)現(xiàn)方案各有優(yōu)點(diǎn)，但都不能以可在所有傳輸協(xié)議上跨域應(yīng)用的可擴(kuò)展方式解決可靠性問題；而且，在消息交換和處理方面的功能層次上也不盡相同。

面對所有這些問題，我決定總結(jié)一個(gè)需求列表，看一看在 web 服務(wù)環(huán)境中實(shí)現(xiàn)可靠性原型需要做哪些工作。

以下是我自己創(chuàng)建的可靠性層的主要需求列表：

基于標(biāo)準(zhǔn)并應(yīng)用于消息協(xié)議層
確認(rèn)發(fā)送
有序發(fā)送
對稱對話
加快異步處理
基于標(biāo)準(zhǔn)
該協(xié)議必須由現(xiàn)有的基于標(biāo)準(zhǔn)的技術(shù)組成。而且，該協(xié)議還應(yīng)該對 soap 1.1 規(guī)范進(jìn)行擴(kuò)展，然后應(yīng)用到消息編碼層而不是傳輸層。這樣，消息才能夠在所有可用的機(jī)制（從 http 到某些專用套接字實(shí)現(xiàn)方案）上進(jìn)行傳輸。

確認(rèn)發(fā)送
為了有章可循，該協(xié)議必須采用某種發(fā)送確認(rèn)機(jī)制，也就是說，使用該協(xié)議發(fā)送的消息應(yīng)當(dāng)從處理器接收一個(gè)且只有一個(gè)關(guān)于該消息狀態(tài)的確認(rèn)信息。

有序發(fā)送
有序發(fā)送引入了對話概念，即客戶端和服務(wù)器可以交換消息和確認(rèn)（確認(rèn)也是可唯一標(biāo)識的對話的一部分）。收到消息后，將檢查消息以進(jìn)行排序，確保處理器收到一組有序的消息。

對稱對話
建立在對話機(jī)制之上的協(xié)議，還必須確保消息和確認(rèn)的對稱性。必須確保每條消息只被處理一次，并且只生成一個(gè)確認(rèn)。

加快異步處理
這是需求列表中最重要的一點(diǎn)，所以留在最后說明。http 是基于同步請求響應(yīng)模型的，適用于處理任務(wù)量小或運(yùn)行時(shí)間短的簡單應(yīng)用程序。web 服務(wù)實(shí)現(xiàn)方案有一個(gè)不太高明的小秘密，即用戶不需要從處理的角度了解服務(wù)是如何在后端實(shí)現(xiàn)的。也就是說，web 服務(wù)實(shí)現(xiàn)方案處理一個(gè)請求可能只需要三秒鐘，也可能會花上三個(gè)小時(shí)。這導(dǎo)致消息處理體系結(jié)構(gòu)效率低下，且無法擴(kuò)縮。我們需要的是一個(gè)能夠加快異步消息處理體系結(jié)構(gòu)的處理模型。但是要注意，異步模型實(shí)現(xiàn)方案要比緊耦合的請求響應(yīng)實(shí)現(xiàn)方案復(fù)雜得多，因?yàn)樗枰嗟幕A(chǔ)結(jié)構(gòu)。

我來解釋一下。在使用標(biāo)準(zhǔn) http 的同步消息處理模型中，客戶端在向服務(wù)器發(fā)送請求后、從服務(wù)器接收到響應(yīng)之前一直保持停滯狀態(tài)。在這段時(shí)間內(nèi)，可能會發(fā)生許多災(zāi)難性事件：

連接可能會因外部原因而斷開，從而丟失請求或響應(yīng)。
服務(wù)器可能會因脫機(jī)或過載而超時(shí)。
服務(wù)器進(jìn)程可能取決于下行服務(wù)，而這種服務(wù)的響應(yīng)時(shí)間無法控制。
同步模型

圖 1：同步模型

不管問題是與網(wǎng)絡(luò)有關(guān)還是與應(yīng)用程序有關(guān)，要確保可靠性都需要實(shí)現(xiàn)某種附加協(xié)議驅(qū)動的基礎(chǔ)結(jié)構(gòu)。在本次討論中，我想著重講述消息是如何在傳輸層上進(jìn)行處理的。傳輸層是獨(dú)立于應(yīng)用程序的關(guān)鍵部分，使用它可以實(shí)現(xiàn)可靠性層，并將消息的最終處理過程分離出來。更具體一點(diǎn)來說，每一條消息（不管針對哪種應(yīng)用程序）都需要從網(wǎng)絡(luò)層上讀取，并分配至適當(dāng)?shù)膽?yīng)用程序資源。我們可以在這里添加一個(gè)發(fā)送可靠性確認(rèn)和執(zhí)行持續(xù)存儲的附加協(xié)議，這樣應(yīng)用程序資源就可以選擇處理該消息的時(shí)間和方式。而且，這個(gè)新協(xié)議可以幫助我們分離或加快異步處理模型。下面將解釋如何完成此過程。

在下面的異步模型中，某一請求被發(fā)送至 soap 服務(wù)器。服務(wù)器從網(wǎng)絡(luò)層上讀取該消息流，并立即向客戶端返回 http 202 響應(yīng)。此進(jìn)程僅就向服務(wù)器發(fā)送消息的時(shí)間而言是同步的，這樣可以減少與連接有關(guān)的問題。到達(dá)服務(wù)器后，消息將被傳送到可靠性層，在這里進(jìn)行檢查以驗(yàn)證消息是否過期、重復(fù)和有序。然后，消息被持續(xù)存儲（在關(guān)系數(shù)據(jù)庫中），并向客戶端發(fā)送有關(guān)其狀態(tài)的確認(rèn)。最后，消息將被分配至正確的應(yīng)用程序功能。

異步模型

圖 2：異步模型

在 http 環(huán)境中，您可以控制向客戶端發(fā)送響應(yīng)的時(shí)間。通過控制向客戶端發(fā)送響應(yīng)的時(shí)間，您可以將下行處理影響通信可靠性的風(fēng)險(xiǎn)降到最低。在 soap 中，這是通過單向消息傳遞實(shí)現(xiàn)的。它指示底層 soap 處理器立刻向客戶端發(fā)送 http 202 響應(yīng)，通知客戶端已收到消息，并已成功地將消息分配給正確的資源進(jìn)行處理。之后，處理器向客戶端發(fā)送有關(guān)該消息狀態(tài)的響應(yīng)。本文稍后將對這種模型的優(yōu)點(diǎn)進(jìn)行詳細(xì)介紹。

建立可靠性層
明確了上述要求之后，我們來討論如何使用 .net 框架為 web 服務(wù)實(shí)現(xiàn)方案建立可靠性協(xié)議。根據(jù)上述要求，我建立了一個(gè)小型 api，以便提供可用的實(shí)現(xiàn)方案。

協(xié)議：ericrp
第一個(gè)問題是定義如何分解可靠性協(xié)議 (ericrp)。以下是該協(xié)議的關(guān)鍵之處：

該協(xié)議是用于教學(xué)的原型。
該協(xié)議主要是通過擴(kuò)展 soap 消息處理層在 soap 處理層上執(zhí)行的。
soap 標(biāo)頭用于對處理層所需信息進(jìn)行編碼。
該協(xié)議要求實(shí)現(xiàn)方案具有某種方式的持續(xù)存儲，以便記錄消息。本實(shí)現(xiàn)方案使用的是 microsoft sql server 2000。
注意：不管采取哪種方式在 soap 環(huán)境中實(shí)現(xiàn)可靠性層，除了 soap 分析器之外，都還需要其他基礎(chǔ)結(jié)構(gòu)。
該協(xié)議支持對話概念，也就是說可以對多條消息進(jìn)行排序，從而保證有序的發(fā)送。
該協(xié)議的全部實(shí)現(xiàn)方案都由 ericrp 名稱空間限定。
ericrp 基于兩方對話方案，即兩個(gè)服務(wù)可以通過 xml web services 體系結(jié)構(gòu)（http、soap 和 wsdl）進(jìn)行對話。
客戶端負(fù)責(zé)消息的所有更正。（本文后面有詳細(xì)論述）
服務(wù)器只負(fù)責(zé)基于特定標(biāo)準(zhǔn)發(fā)送確認(rèn)。
服務(wù)器不記錄收到的過期消息。
服務(wù)器不記錄收到的無序消息。
服務(wù)器不記錄收到的重復(fù)消息。
處理 api
在這個(gè)原型中，我建立了六個(gè)主要的類和一個(gè)小型數(shù)據(jù)庫。我將類稱為處理 api。web 服務(wù)客戶端和服務(wù)器將使用這些類監(jiān)控和更正使用 ericrp 可靠性協(xié)議的消息。所有的類都屬于 ericrp 名稱空間：

client.conversationmanager：由客戶端使用，創(chuàng)建 web 服務(wù)消息關(guān)聯(lián)和消息監(jiān)控的對話環(huán)境。
client.rpclienttrace：由 web 服務(wù)客戶端使用，這些客戶端的方法對出站消息執(zhí)行 ericrp 可靠性協(xié)議。
server.conversationmanager：由 web 服務(wù)服務(wù)器使用，記錄并處理入站消息。
server.rpservertrace：由 web 服務(wù)服務(wù)器使用，這些服務(wù)器的方法對入站消息執(zhí)行 ericrp 可靠性協(xié)議。
reliabilityinfo：具有雙重作用。它可以由 client.conversationmanager 使用，為記錄提供可靠性信息；也可以由 web 服務(wù)客戶端代理使用，為出站消息創(chuàng)建必要的 soap 標(biāo)頭信息。
acknowledgment：由 server.conversationmanager 使用，向客戶端發(fā)送確認(rèn)。
ericrp 的工作原理
在查看代碼之前，我想先從用戶的角度說明該協(xié)議的工作原理。例如，我有一個(gè)簡單的 web 服務(wù)代理類，通過它可以向 web 服務(wù)發(fā)送訂單消息。打算使用 api 的客戶端需要執(zhí)行以下操作：

首先，創(chuàng)建 client.conversationmanager 類的實(shí)例并開始一個(gè)新對話。例如：

private void begin()
{
rpclient = new ericrp.client.conversationmanager();

rpclient.messagesent += _
   new ericrp.client.conversationmanager.messagesenteventhandler(process);

rpclient.conversationstarted += new _
   ericrp.client.conversationmanager.conversationstartedhandler(constarted);

rpclient.beginconversation();
}

rpclient 變量在類級別內(nèi)有效，稍后會用到。我還設(shè)置了一些事件處理程序。

下一步，使用訂單代理并配合 reliabilityinfo 類，發(fā)送一條可靠的信息。先創(chuàng)建 purchaseorderproxy 的實(shí)例，就象通常為 web 服務(wù)客戶端所做的操作一樣。再創(chuàng)建 reliabiltiyinfo 類的實(shí)例，將 conversationmanager 傳送給構(gòu)造函數(shù)，然后設(shè)置可靠性屬性。需要特別注意的屬性是 maxretry、expiredate 和 ackurl。maxretry 和 expiredate 用于限制消息的活動，防止它無限制地發(fā)送；web 服務(wù)將在向客戶端發(fā)送接收確認(rèn)時(shí)使用 ackurl。設(shè)置完這些屬性后，即可設(shè)置代理的 reliableheader 屬性并調(diào)用所需的方法。

private void sendmessage()
{
clientproxies.purchaseorderproxy po = new clientproxies.purchaseorderproxy();

   ericrp.reliabilityinfo rinfo = new ericrp.reliabilityinfo(rpclient);
   rinfo.status = reliabilityinfo.messagestatus.new;
   rinfo.senddate = system.datetime.now;
   rinfo.expiredate = system.datetime.now.addhours(4);
   rinfo.maxretry = 5;
   rinfo.ackurl = "http://localhost:8082/ericrpack/poack.asmx";

   po.reliableheader = rinfo;
   po.submitmessage("非常希望他們得到此訂單！");
}

這是為了說明該功能而編寫的一段客戶端測試程序的屏幕快照。注意，我們一共發(fā)送了五條消息。第三條消息在到達(dá)目的地之前已過期，按照 ericrp 協(xié)議，這條消息將被丟棄，服務(wù)器不對其進(jìn)行處理。第四條消息是無序消息，因?yàn)榉?wù)器并沒有收到有效的第三條消息。在重新發(fā)送第三條消息之前，任何后續(xù)消息都是無序的。如果重新查詢 client.conversationmanager，您將發(fā)現(xiàn)第五條消息也是無序的。