可靠的 XML Web Service (1)

來源:互聯網
上載者:User
web|xml 可靠的 XML Web Service
Eric Schmidt
Microsoft Corporation,XML Core Services 組,專案經理
2001 年 12 月 11 日

下載此專欄的範例程式碼。

注意:要下載與本文相關的代碼,您需要:
Visual Studio .NET Release Candidate(英文)
SQL Server 2000(英文)
在 PDC 上,我談論了有關可靠的 XML Web Service(Web 服務)的話題,這個話題源於過去一年來的多次交流。在有關建立 XML Web Service 的眾多常見問題中,可靠性問題是開發人員實現分散式 Web 服務所面臨的五個最重要的問題之一。如果分開來講,這個問題並不是太難,因此,本月我準備談一談建立可靠的 XML Web Service 這一棘手的問題。

概述
Global XML Web Services Architecture(GXA [英文])最突出的一面就是可以使用可合成處理協議擴充該體繫結構。這些協議主要通過 SOAP 標頭實現,可以提供包括安全性、加密、路由和可靠性的廣泛服務。當您開始構建基於 GXA 的應用程式時,您將發現 GXA 實質上是一種訊息處理體繫結構,它通過基於標準的編碼技術 (SOAP) 在系統和服務之間提供協同工作能力。到目前為止,大部分實現工作都集中在 SOAP 1.1 和 WSDL 相容服務上,因此 Web 服務實現方案可以與多種語言和作業系統協同工作。

這是一個了不起的概念。任何兩個系統之間都能夠進行交流,只要它們能夠分析 XML 並理解 SOAP 規範的規則。但是,簡單的訊息交換並不能滿足複雜的商務應用程式的需要。真正的應用程式(不管其內部域體繫結構如何)均需要標準化的服務,例如處於 Web 服務訊息處理層上的安全性、授權和可靠性。在 Global XML Web Services Architecture(具體地說就是 SOAP、SOAP 模組和基礎結構協議)的建立和實現背後有一個巨大的動力。隨著今年十月份四項新規範(WS-Routing、WS-Referral、WS-Licensing 和 WS-Security)的發布,我們已經開始著手下一代 XML Web Service 實現工作。儘管發布了這麼多的新規範,但仍有兩個領域尚無公用規範,即交易處理和可靠的訊息處理,這主要是因為這些基礎結構協議依賴於底層 SOAP 模組。

本專欄主要從 GXA 環境的角度討論可靠性和可靠的訊息處理的含義。而且我還要花一些時間探討通過在 .NET 架構中擴充現有 Web 服務類來開發可靠性協議需要做些什麼。本專欄有兩個主要目的:

讓讀者瞭解可靠性概念,為以後各種規範的實施做好準備。請注意,本文不是規範,而只是一篇文章,旨在引發讀者思考下面要討論的問題。
說明 .NET 架構中 Web 服務和 SOAP 類強大的、基於標準的功能。
XML Web Service 的可靠性
我們把問題分開來講。我們前面講過,GXA 服務實現方案屬於訊息處理服務,它們需要在分散式環境中發送和接收基於標準的編碼訊息。在 Web 服務實現方案中發送 SOAP 訊息的主要傳輸協議是 HTTP,它易於實現和管理,但本身不可靠。我們無需深入探討 HTTP 不可靠的具體原因,但只要知道 HTTP 沒有基於標準的服務來保證終點或伺服器能夠接收到請求就足夠了。儘管內建的網路層裝置可以在發生一般災難性故障(例如未找到資源)時產生錯誤,但是卻沒有機制可以確保用戶端能夠以可靠的方式接收請求或響應。

通常是通過簡單的重新發送操作處理 HTTP 故障,但在業務處理環境中這既不利於提高效率也沒有效果。它導致不必要的通訊量,並增加了重複交易的風險。

目前市場上有多種能夠更有效解決此問題的訊息處理技術,包括傳輸協議(如 HTTPR)、企業基礎結構(如 MSMQ 和 MQ Series)以及業務處理協議(如 ebXML)。儘管每種技術針對特定的實現方案各有優點,但都不能以可在所有傳輸協議上跨域應用的可擴充方式解決可靠性問題;而且,在訊息交換和處理方面的功能層次上也不盡相同。

面對所有這些問題,我決定總結一個需求列表,看一看在 Web 服務環境中實現可靠性原型需要做哪些工作。

以下是我自己建立的可靠性層的主要需求列表:

基於標準並應用於訊息協議層
確認發送
有序發送
對稱對話
加快非同步處理
基於標準
該協議必須由現有的基於標準的技術組成。而且,該協議還應該對 SOAP 1.1 規範進行擴充,然後應用到訊息編碼層而不是傳輸層。這樣,訊息才能夠在所有可用的機制(從 HTTP 到某些專用通訊端實現方案)上進行傳輸。

確認發送
為了有章可循,該協議必須採用某種發送確認機制,也就是說,使用該協議發送的訊息應當從處理器接收一個且只有一個關於該訊息狀態的確認資訊。

有序發送
有序發送引入了對話概念,即用戶端和伺服器可以交換訊息和確認(確認也是可唯一標識的對話的一部分)。收到訊息後,將檢查訊息以進行排序,確保處理器收到一組有序的訊息。

對稱對話
建立在對話機制之上的協議,還必須確保訊息和確認的對稱性。必須確保每條訊息只被處理一次,並且只產生一個確認。

加快非同步處理
這是需求列表中最重要的一點,所以留在最後說明。HTTP 是基於同步請求響應模型的,適用於處理任務量小或已耗用時間短的簡單應用程式。Web 服務實現方案有一個不太高明的小秘密,即使用者不需要從處理的角度瞭解服務是如何在後端實現的。也就是說,Web 服務實現方案處理一個請求可能只需要三秒鐘,也可能會花上三個小時。這導致訊息處理體繫結構效率低下,且無法擴縮。我們需要的是一個能夠加快非同步訊息處理體繫結構的處理模型。但是要注意,非同步模型實現方案要比緊耦合的請求響應實現方案複雜得多,因為它需要更多的基礎結構。

我來解釋一下。在使用標準 HTTP 的同步訊息處理模型中,用戶端在向伺服器發送請求後、從伺服器接收到響應之前一直保持停滯狀態。在這段時間內,可能會發生許多災難性事件:

串連可能會因外部原因而斷開,從而丟失請求或響應。
伺服器可能會因離線或過載而逾時。
伺服器處理序可能取決於下行服務,而這種服務的回應時間無法控制。
同步模型


圖 1:同步模型

不管問題是與網路有關還是與應用程式有關,要確保可靠性都需要實現某種附加協議驅動的基礎結構。在本次討論中,我想著重講述訊息是如何在傳輸層上進行處理的。傳輸層是獨立於應用程式的關鍵區段,使用它可以實現可靠性層,並將訊息的最終處理過程分離出來。更具體一點來說,每一條訊息(不管針對哪種應用程式)都需要從網路層上讀取,並分配至適當的應用程式資源。我們可以在這裡添加一個發送可靠性確認和執行持續儲存的附加協議,這樣應用程式資源就可以選擇處理該訊息的時間和方式。而且,這個新協議可以協助我們分離或加快非同步處理模型。下面將解釋如何完成此過程。

在下面的非同步模型中,某一請求被發送至 SOAP 伺服器。伺服器從網路層上讀取該訊息流程,並立即向用戶端返回 HTTP 202 響應。此進程僅就向伺服器發送訊息的時間而言是同步的,這樣可以減少與串連有關的問題。到達伺服器後,訊息將被傳送到可靠性層,在這裡進行檢查以驗證訊息是否到期、重複和有序。然後,訊息被持續儲存(在關聯式資料庫中),並向用戶端發送有關其狀態的確認。最後,訊息將被分配至正確的應用程式功能。

非同步模型


圖 2:非同步模型

在 HTTP 環境中,您可以控制向用戶端發送響應的時間。通過控制向用戶端發送響應的時間,您可以將下行處理影響通訊可靠性的風險降到最低。在 SOAP 中,這是通過單向訊息傳遞實現的。它指示底層 SOAP 處理器立刻向用戶端發送 HTTP 202 響應,通知用戶端已收到訊息,並已成功地將訊息分配給正確的資源進行處理。之後,處理器向用戶端發送有關該訊息狀態的響應。本文稍後將對這種模型的優點進行詳細介紹。

建立可靠性層
明確了上述要求之後,我們來討論如何使用 .NET 架構為 Web 服務實現方案建立可靠性協議。根據上述要求,我建立了一個小型 API,以便提供可用的實現方案。

協議:ericRP
第一個問題是定義如何分解可靠性協議 (ericRP)。以下是該協議的關鍵之處:

該協議是用於教學的原型。
該協議主要是通過擴充 SOAP 訊息處理層在 SOAP 處理層上執行的。
SOAP 標頭用於對處理層所需資訊進行編碼。
該協議要求實現方案具有某種方式的持續儲存,以便記錄訊息。本實現方案使用的是 Microsoft SQL Server 2000。
注意:不管採取哪種方式在 SOAP 環境中實現可靠性層,除了 SOAP 分析器之外,都還需要其他基礎結構。
該協議支援對話概念,也就是說可以對多條訊息進行排序,從而保證有序的發送。
該協議的全部實現方案都由 ericRP 名稱空間限定。
ericRP 基於兩方對話方案,即兩個服務可以通過 XML Web Services 體繫結構(HTTP、SOAP 和 WSDL)進行對話。
用戶端負責訊息的所有更正。(本文後面有詳細論述)
伺服器只負責基於特定標準發送確認。
伺服器不記錄收到的到期訊息。
伺服器不記錄收到的無序訊息。
伺服器不記錄收到的重複訊息。
處理 API
在這個原型中,我建立了六個主要的類和一個小型資料庫。我將類稱為處理 API。Web 服務用戶端和伺服器將使用這些類監控和更正使用 ericRP 可靠性協議的訊息。所有的類都屬於 ericRP 名稱空間:

Client.ConversationManager:由用戶端使用,建立 Web 服務訊息關聯和訊息監控的對話環境。
Client.RPClientTrace:由 Web 服務用戶端使用,這些用戶端的方法對出站訊息執行 ericRP 可靠性協議。
Server.ConversationManager:由 Web 服務伺服器使用,記錄並處理入站訊息。
Server.RPServerTrace:由 Web 服務伺服器使用,這些伺服器的方法對入站訊息執行 ericRP 可靠性協議。
ReliabilityInfo:具有雙重作用。它可以由 Client.ConversationManager 使用,為記錄提供可靠性資訊;也可以由 Web 服務用戶端代理使用,為出站訊息建立必要的 SOAP 標頭資訊。
Acknowledgment:由 Server.ConversationManager 使用,向用戶端發送確認。
ericRP 的工作原理
在查看代碼之前,我想先從使用者的角度說明該協議的工作原理。例如,我有一個簡單的 Web 服務代理類,通過它可以向 Web 服務發送訂單訊息。打算使用 API 的用戶端需要執行以下操作:

首先,建立 Client.ConversationManager 類的執行個體並開始一個新對話。例如:

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 變數在類層級內有效,稍後會用到。我還設定了一些事件處理常式。

下一步,使用訂單代理並配合 ReliabilityInfo 類,發送一條可靠的資訊。先建立 PurchaseOrderProxy 的執行個體,就象通常為 Web 服務用戶端所做的操作一樣。再建立 ReliabiltiyInfo 類的執行個體,將 ConversationManager 傳送給建構函式,然後設定可靠性屬性。需要特別注意的屬性是 MaxRetry、ExpireDate 和 AckURL。MaxRetry 和 ExpireDate 用於限制訊息的活動,防止它無限制地發送;Web 服務將在向用戶端發送接收確認時使用 AckURL。設定完這些屬性後,即可設定代理的 ReliableHeader 屬性並調用所需的方法。

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("非常希望他們得到此訂單!");
}

這是為了說明該功能而編寫的一段用戶端測試程式的螢幕快照。注意,我們一共發送了五條訊息。第三條訊息在到達目的地之前已到期,按照 ericRP 協議,這條訊息將被丟棄,伺服器不對其進行處理。第四條訊息是無序訊息,因為伺服器並沒有收到有效第三條訊息。在重新發送第三條訊息之前,任何後續訊息都是無序的。如果重新查詢 Client.ConversationManager,您將發現第五條訊息也是無序的。



圖 3:用戶端測試程式



相關文章

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 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。