第 4 章 — 偶爾連接的智能客戶端

智能客戶端體系結構與設計指南

David Hill, Brenton Webster, Edward A. Jezierski, Srinath Vasireddy and Mohammad Al-Sabt, Microsoft Corporation; Blaine Wastell, Ascentium Corporation; Jonathan Rasmusson and Paul Gale, ThoughtWorks; and Paul Slater, Wadeware LLC

相關鏈接

Microsoft? patterns & practices 庫 http://www.microsoft.com/resources/practices/default.mspx

Application Architecture for .NET: Designing Applications and Services http://msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp

摘要：本章討論了您在設計和生成偶爾連接到網絡的智能客戶端應用程序時可能面臨到的問題。本章討論了連接性的概念，介紹了兩種實現脫機功能的主要方法，并且討論了您在使應用程序可供脫機使用時需要考慮的一些問題。

本頁內容

	常見的偶爾連接情況
	偶爾連接設計策略
	使用面向服務的方法設計偶爾連接的智能客戶端應用程序
	使用基于任務的方法
	處理依賴性
	小結

我們生活在一個連接程度越來越高的世界里。然而，在許多情況下，我們不能無時無刻都依賴連接。您的用戶可能需要旅行，他們可能會暫時失去無線連接，可能存在延遲或帶寬問題，或者您可能需要拆卸網絡的某些部分進行維護。即使用戶的確具有良好的網絡連接，您的應用程序也可能無法在所有時間都能訪問網絡資源。所請求的服務可能繁忙、停止運行或者只是暫時不可用。

如果應用程序有時無法及時地通過網絡與服務或數據交互，則為偶爾 連接的應用程序。如果您能讓用戶在脫機時使用其應用程序富有成效地工作，并且仍然能夠為其提供連接的應用程序在連接有效時所具有的好處，則可以提高用戶的生產率和工作效率，并且提高應用程序的可用性。

智能客戶端相對于基于 Web 的應用程序所具有的主要好處之一是：當應用程序無法連接到網絡資源時，它們能夠讓用戶繼續工作。偶爾連接的智能客戶端能夠在未連接到網絡資源時工作，然后在以后某個時間在后臺更新網絡資源。更新可能幾乎立即發生，但有時可能發生在數天甚至數周以后。

要給予應用程序完整的偶爾連接功能，您需要提供一種基礎結構，使用戶能夠在沒有連接到網絡資源時工作。該基礎結構應該包括數據緩存，以便可以在客戶端使用所有需要的數據；它還應該包括用戶工作詳細信息的存儲，以便用來在用戶重新聯機時將客戶端與網絡資源同步。應用程序為支持偶爾連接的操作所需要的確切特性和功能取決于它的連接性、操作環境以及用戶在聯機和脫機時所期望的功能。但是，所有智能客戶端應用程序都應該在未連接到網絡時為用戶提供某種體驗，即使功能極其有限。在設計和生成應用程序時，應該始終避免因為服務器不可用而在客戶端生成錯誤消息。

本章考察您在生成具有脫機功能的應用程序時所面臨的問題。它將討論設計脫機應用程序的不同策略，詳細討論設計注意事項，分析如何組織應用程序以使用任務，并且考察應用程序應該如何處理數據。

常見的偶爾連接情況

偶爾連接的智能客戶端在許多常見的情況下都極其有用。許多脫機情況涉及到用戶顯式斷開網絡連接并且在沒有網絡連接的情況下工作，例如：

其他脫機情況涉及到間歇性或低質量的連接，例如：

應該將偶爾連接的智能客戶端設計為最大限度地利用可用連接，確保應用程序和數據盡可能保持最新，并且不會對應用程序的性能造成不利影響。

返回頁首

偶爾連接設計策略

在設計偶爾連接的智能客戶端應用程序的體系結構時，有兩種概括性的方法：以數據為中心 和面向服務。

使用以數據為中心的策略的應用程序具有一個在客戶端上本地安裝的關系數據庫管理系統 (RDBMS)，并且使用該數據庫系統的內置功能將本地數據更改傳回服務器，處理同步過程，并檢測和解決任何數據沖突。

使用面向服務方法的應用程序將信息存儲在消息中，并且當客戶端脫機時將這些消息排列到隊列中。在重新建立連接以后，排隊的消息將被發送到服務器進行處理。

圖 4.1 顯示了以數據為中心的方法和面向服務的方法。

圖 4.1 偶爾連接應用程序設計的面向服務的方法和以數據為中心的方法

本節將詳細分析這兩種方法并解釋何時應該使用每種方法。

以數據為中心的方法

當您使用以數據為中心的方法時，通常情況下，服務器發布數據，而客戶端創建它所需要的數據的預訂，以便它可以在脫機之前將相應的數據復制到本地數據存儲。當客戶端脫機時，它將通過對本地數據存儲的調用來對本地數據進行更改。當客戶端重新聯機后，數據存儲會將對客戶端上的數據所做的更改傳回服務器。對服務器上數據所做的更改也可能被傳回客戶端。在合并階段遇到的任何沖突都將按照業務分析師定義的自定義規則，由在服務器或客戶端上指定的沖突解決規則處理。

在客戶端和服務器之間合并更改的過程稱為合并復制。更改可能在客戶端和服務器以自治方式發生，因此不使用 ACID（原子、一致、獨立、持久）事務。相反，當執行合并時，系統中的所有預訂者都將使用發布者擁有的數據值。

以數據為中心的方法主要優點是所有更改跟蹤代碼都包含在關系數據庫中。通常，這包括數據庫的列級和行級的沖突檢測代碼、數據驗證代碼以及約束。這意味著您無須編寫自己的更改跟蹤代碼或沖突檢測與解決代碼，盡管您的確需要知道合并-復制方案以便針對數據沖突和數據更新來優化您的應用程序。

在以數據為中心的模型中，數據庫系統負責處理同步；因此，您無須自己來實現所有數據同步功能。用戶定義哪些表要求數據同步，而數據庫系統使基礎結構可以跟蹤更改并且檢測和解決沖突。您可以通過使用 COM 對象或 Transact SQL (TSQL) 存儲過程的自定義沖突解決程序來擴展該基礎結構，以便提供自定義沖突解決或避免機制。而且，因為在整個系統中只有一個數據儲存庫，所以當同步完成時，能夠保證在服務器和客戶端之間執行數據會聚。

但是，以數據為中心的方法有一些缺點。在客戶端上需要本地數據庫意味著該方法在下列情況下可能不適合：

Microsoft 提供了能夠在 Windows? 客戶端、Windows Server? 和 Pocket PC 平臺上運行的數據庫軟件，但它沒有為 SmartPhone 設備提供數據庫軟件。

而且，服務器上的數據庫與客戶端上的數據庫之間的緊耦合性意味著對服務器上數據庫架構進行的更改對客戶端具有直接影響。這可能使管理對客戶端或服務器進行的數據庫架構更改變得很困難。

對于大量客戶端而言，需要提供一種可管理且可伸縮的方法來部署獨特的數據集。合并復制支持動態篩選，這使得管理員能夠定義這些脫機數據集并且以可伸縮的方式部署它們。您應該利用數據庫提供的篩選機制來減少在客戶端和服務器之間發送的數據量，并降低沖突的可能性。

使用本地數據庫在本地存儲和操作數據有許多好處。您可以使用數據庫將本地更改傳回服務器并幫助處理同步問題。

您應該在下列情況下使用以數據為中心的方法：

面向服務的方法

對于面向服務的方法而言，客戶端可以與需要的任何服務交互。而且，客戶端將致力于服務請求本身，而不是對本地保存的數據進行直接更改。服務請求可能在客戶端或服務器上導致狀態更改，但此類更改是服務請求的副產品。

面向服務策略的一個優點是在客戶端上不需要本地關系數據庫。這意味著可以將該方法應用于許多不同的客戶端類型，包括那些具有少量處理能力的客戶端，如移動電話。

當您的應用程序必須在 Internet 和 Extranet 環境中工作時，面向服務的方法尤其適合。如果您的客戶端在防火墻外部工作并且與企業服務交互，則通過使用面向服務的策略，您可以避免由于某種原因而必須在防火墻中打開特定的端口，例如為了啟用直接數據庫或 Microsoft 消息隊列 (MSMQ) 訪問。

松耦合意味著您可以在客戶端上使用與服務器上不同的數據架構，并且在客戶端傳輸數據。實際上，客戶端和服務器不需要知道對方。您還可以獨立地更新客戶端和服務器組件。

該方法的主要缺點是您需要編寫更多的基礎結構代碼，以便存儲和轉發消息以及檢測應用程序何時聯機或脫機。這可以使您在設計中具有更多的靈活性，但通常意味著在創建脫機客戶端時需要完成更多的工作。

注 智能客戶端脫機應用程序塊 (Smart Client Offline Application Block) 為您提供了支持脫機客戶端的面向服務策略的代碼。您可以使用該塊來檢測應用程序何時聯機或脫機，并且存儲消息以及將消息轉發給服務器進行處理。有關該應用程序塊的概述，請參閱 Smart Client Offline Application Block，網址為：http://msdn.microsoft.com/library/en-us/dnpag/html/offline.asp。

面向服務的方法最適合于需要與許多不同服務交互的智能客戶端。因為消息的有效負載被封裝，所以傳輸層可以改變，而不會影響消息的內容。例如，原來要發往某個 Web 服務的消息可以同樣容易地發往消耗消息隊列消息的服務。消息與傳輸無關這一事實還使應用程序可以根據需要自定義安全性實現。

您應該在下列情況下使用面向服務的方法：

盡管以數據為中心的方法和面向服務的方法都是有效的體系結構方法，但許多智能客戶端應用程序無法在客戶端上支持完整的關系數據庫實例。在這種情況下，您應該采用面向服務的方法，并且確保您擁有適當的基礎結構，以便處理諸如數據緩存以及沖突檢測和解決等問題。

因此，本章的其余部分將集中討論智能客戶端開發人員在實現面向服務的方法時需要考慮的問題。

返回頁首

使用面向服務的方法設計偶爾連接的智能客戶端應用程序

當您使用面向服務的方法設計偶爾連接的智能客戶端時，需要解決許多問題。這些問題包括：

本節將詳細討論這些問題。

優選異步通訊

應用程序在與位于網絡上的數據和服務交互時，使用下列兩種通訊方法之一：

如果您要設計新的智能客戶端應用程序，則應該確保它在與位于網絡上的數據和服務交互時主要使用異步通訊。被設計為期待請求和響應之間存在延遲的應用程序非常適合于偶爾連接的用途，前提是該應用程序在等待響應的過程中能夠提供重要且有用的功能，并且在響應延遲時不會妨礙用戶繼續完成他或她的工作。

當該應用程序未連接到網絡資源時，您可以在本地存儲請求，并且在應用程序重新連接時將這些請求發送到遠程服務。無論是脫機還是聯機，因為應用程序并不期待請求立即得到響應，所以都不會禁止用戶繼續使用該應用程序，用戶可以繼續工作。

使用同步通訊的應用程序（即使是在后臺線程上）不太適合于偶爾連接的用途。因此，您應該在智能客戶端中盡可能減少對同步通訊的使用。如果您要將使用同步通訊的應用程序重新設計為智能客戶端，則應該確保它采用異步程度更高的通訊模型，以便它能夠脫機工作。但是，在許多情況下，您可以在異步基礎結構之上實現類似于同步的通訊（稱為同步-異步模型），以便將應用程序設計更改保持到最低限度。

將應用程序設計為使用異步通訊可以為您帶來超越偶爾連接用途的好處。大多數設計為使用異步通訊的應用程序都比那些使用同步通訊的應用程序更加靈活。例如，可以在異步應用程序正在執行任務的過程中將其關閉，并且當它重新啟動時不會影響請求或響應的處理。

在大多數情況下，您不需要在應用程序中同時實現同步和異步行為以便在聯機和脫機時使用。異步行為同時適合于聯機和脫機使用；當應用程序聯機時，請求會以接近于實時的速度進行處理。

盡可能減少復雜的網絡交互

偶爾連接的智能客戶端應該盡可能減少或消除與位于網絡上的數據和服務的交互。當您的應用程序脫機時，它可能必須存儲請求并在應用程序重新連接時發送這些請求，或者它可能需要針對響應等待一會兒。無論采取哪種方式，應用程序都不會立即知道請求是否即將成功或已經成功。

要使應用程序能夠在脫機時繼續工作，您必須就網絡請求的成功或本地數據的更改進行某些假設。跟蹤這些假設以及服務請求和數據更改之間的依賴性可能非常復雜。要減輕這一負擔，您應該盡可能地圍繞簡單的網絡交互來設計您的智能客戶端應用程序。

通常，不返回任何數據的請求（“發后不理”請求）對于偶爾連接的應用程序來說不會成為問題；應用程序可以存儲該請求并在重新連接時轉發該請求。當應用程序脫機時，它不知道調用是否已經成功；因此，該應用程序必須假設調用已成功。這一假設可能影響后續處理。

如果請求返回應用程序繼續工作所需要的數據，則應用程序必須使用暫定值或虛擬值，或者在沒有相應數據的情況下工作。在此情況下，您需要將應用程序設計為跟蹤暫定數據和已確認的數據，并且將用戶界面設計為使用戶知道暫定或掛起的數據。這使用戶或應用程序能夠基于數據的有效性進行明智的決策，并防止以后出現與數據沖突和損壞有關的問題。

如果用戶已經在脫機狀態下完成了一些不連續的工作單元，則應用程序應該允許各個工作單元單獨成功或失敗。例如，在允許用戶輸入訂單信息的應用程序中，應用程序可以讓用戶根據需要輸入任意多的訂單，但該應用程序必須確保一個訂單不必依賴于其他訂單的成功。

當應用程序對于每個工作單元只能產生一個服務請求時，確保各個工作單元之間不存在依賴性是相對容易的。這使應用程序可以跟蹤掛起的請求，并且可以在聯機后處理這些請求。但是，在某些情況下，用戶任務更為復雜，必須產生多個服務請求才能完成它們。在這些情況下，應用程序必須確保每個請求都與其他請求一致，以便保持數據一致性。

添加數據緩存功能

您的應用程序需要確保在它脫機時，客戶端能夠提供用戶繼續工作所需的所有數據。在某些情況下，您的應用程序應該出于性能原因在客戶端緩存數據，但很多時候，您的應用程序必須緩存額外的數據以滿足偶爾連接的用途。例如，您可能沒有為聯機使用的應用程序緩存不穩定的數據，但要使同一應用程序能夠脫機工作，則需要在本地計算機上緩存這些數據。客戶端和服務器端都必須進行相應的設計以考慮數據不穩定性，以便它們可以適當地處理更新和沖突。

當應用程序脫機時，您可能選擇不從應用程序數據緩存中刪除過時的數據，而是使用這些過時的數據以使用戶能夠繼續工作。在其他情況下，應用程序可能需要自動從緩存中刪除這些數據，以防止用戶使用它并在以后產生問題。在后一種情況下，在通過同步過程獲取新數據之前，應用程序可能停止提供所需的功能。

根據應用程序風格和功能的不同，緩存中數據的刷新可能以多種方式發生。對于某些應用程序，可以按照下列策略自動刷新緩存的數據：當緩存的數據到期時刷新；按照某個時間表定期刷新；當應用程序執行同步操作時刷新；或者當服務器更改了數據并將相應的更改通知應用程序時刷新。其他應用程序可能允許用戶手動選擇要緩存的數據，從而使用戶能夠在脫機狀態下分析或使用這些數據。

其他數據緩存注意事項同樣適用，如安全性約束和數據處理約束。這些問題并非只能在支持脫機操作的應用程序中遇到，第 2 章：處理數據中對它們進行了更為完整的介紹。

處理對引用數據的更改

引用數據是很少發生更改的數據。通常，應用程序包含大量這樣的數據。例如，在客戶記錄中，客戶名稱很少更改。可以容易地將這種類型的數據緩存在客戶端上，但有時您的引用數據將發生更改，而您必須具有某種將這些更改傳播到智能客戶端的機制。

您具有兩種傳播這些數據的選項：推模型和拉模型。

在推模型中，服務器搶先通知客戶端并試圖將數據推出。在以數據為中心的方法中，這由復制客戶端數據存儲中被刷新的數據的服務器數據組成。在面向服務的方法中，這可能是包含已更新數據的消息。（這要求客戶端實現可供服務器連接到的終結點。）

在拉模型中，客戶端與服務器聯系以檢查是否存在更新。客戶端可以通過定期檢查服務器做到這一點，也可以通過分析帶有聲明引用數據何時到期的原始數據的元數據來做到這一點。客戶端甚至可能趁早從服務器拉數據（例如，價格表），并且僅當它變為有效時才使用它。

在某些情況下，您可能選擇采用這樣一種模型，即由服務器通知客戶端更新可用（例如，通過在客戶端連接時發送警報），然后客戶端從服務器拉數據。

管理連接

當您設計偶爾連接的智能客戶端時，應該從以下兩個方面考慮應用程序的工作環境：可用的連接性，以及應用程序隨著該連接性的更改而需要具有的行為。

應該將某些應用程序設計為能夠在沒有連接的情況下長時間地（數天，甚至數周）工作。而對于其他應用程序，則應該將其設計為總是期待連接，但能夠優雅地處理連接臨時斷開連接的情況。某些應用程序在脫機時應該只提供功能子集，而其他應用程序則應該提供大部分功能以供脫機使用。

盡管許多偶爾連接方案都涉及到用戶從網絡顯式斷開連接，并在沒有連接的情況下工作，但有時應用程序在未顯式從網絡斷開連接的情況下脫機。可以將應用程序設計為能夠處理其中一種方案或能夠處理這兩種方案。

手動連接管理

可以將應用程序設計為能夠在用戶決定脫機工作時正常工作。應用程序必須在本地計算機上存儲用戶可能需要的所有數據。在此情況下，用戶在與應用程序交互時知道它處于脫機狀態，而應用程序不會試圖執行網絡操作，直到它被明確告知聯機并執行同步操作為止。

您還可以包括相應的支持，以便用戶能夠在使用連接成本較高的連接或低帶寬連接（如商業無線熱點、移動電話連接或撥號連接）時通知應用程序。在此情況下，可以將應用程序設計為對請求進行批處理，以便在建立連接時，能夠最大限度地利用它。

自動連接管理

可以將應用程序設計為能夠動態適應意外發生的連接性更改。這些更改可能包括下列情況：

您可以通過使用 wininet.dll 來檢測智能客戶端應用程序是否具有連接。該 DLL 與 Microsoft Internet Explorer 用于確定用戶是否連接到 Internet 的 DLL 相同。下面的代碼示例顯示了如何調用 wininet.dll。

   [DllImport("wininet.dll")] 
   private extern static bool InternetGetConnectedState( out int  
connectionDescription, int reservedValue ) ; 
   public bool IsConnected() { 
     int connectionDescription = 0; 
     return InternetGetConnectedState(out connectionDescription, 0); 
} 

設計存儲轉發機制

如果您將應用程序設計為使用面向服務的體系結構，則必須提供存儲轉發機制。通過存儲轉發，可以創建、存儲消息并最終將其轉發到它們各自的目的地。最常見的存儲轉發實現是消息隊列。這就是面向消息的中間件產品（如 Microsoft 消息隊列）的工作方式。當創建新的消息時，它們將被放入消息隊列，并被轉發到它們的目標地址。盡管還有其他存儲轉發替代機制（如 FTP 或在客戶端與服務器之間復制文件），但本指南將專門討論最常見的實現：消息隊列。

智能客戶端需要一種在脫機時保留消息的方法。如果您的應用程序需要在脫機時創建新消息，則您的隊列必須具有一種保留它們以便以后與服務器進行更新的方法。這里，最顯而易見的選擇是將其寫入磁盤。

您的設計需要包括能夠確保將消息成功傳遞到其目的地的功能。您的設計應該考慮下列情況：

存儲轉發機制還需要支持附加功能，如消息加密、優先級化、鎖定和同步。

生成和設計可靠的消息處理體系結構是一項復雜的任務，要求有豐富的經驗和技能。因此，您應該認真地考慮一下商業產品，如 Microsoft 消息隊列。但是，Microsoft 消息隊列要求在客戶端上安裝軟件，這可能并非所有智能客戶端的選擇。

另一個消息隊列管理選擇是使用智能客戶端脫機應用程序塊，它可在 http://msdn.microsoft.com/library/en-us/dnpag/html/offline-CH01.asp 獲得。

該應用程序塊提供了相關的服務和基礎結構，智能客戶端可用來向它們的應用程序提供脫機功能。該應用程序塊使用消息隊列概念支持消息處理的存儲轉發方法。默認情況下，該應用程序塊支持消息隊列集成以及其他一些消息保留機制（內存、獨立存儲和 Microsoft SQL Server? 桌面引擎 [MSDE]）。

管理數據和業務規則沖突

以脫機模式在應用程序中進行的更改必須在某個時刻與服務器同步或協調。這增加了發生沖突或發生應用程序、用戶或管理員必須解決的其他問題的可能性。當確實發生沖突時，您必須確保能夠檢測并解決它們。

與數據沖突不同，發生業務規則沖突的原因不是在兩塊數據之間存在沖突，而是在某個地方違反了業務規則并且需要糾正。數據沖突和業務規則沖突都可能需要由客戶端應用程序或用戶處理。

作為業務規則沖突的示例，假設您有一個訂單管理應用程序，該應用程序緩存了一個產品目錄，以便用戶能夠在脫機時將訂單輸入系統。然后，當該應用程序重新聯機時，這些訂單將被轉發給服務器。如果某個訂單包含一種位于緩存的產品目錄中但在應用程序重新聯機時已經停止生產的產品，則當訂單數據被轉發給服務器時，服務器將檢查訂單詳細信息并且發現該產品已經停止生產。此時，應用程序可以通知用戶該訂單有一個問題。如果所述產品已被替換或廢棄，則系統可以給予用戶切換到不同產品的能力。這種情況不是數據沖突（因為數據沒有與任何內容沖突），但這仍然是不正確的，并且需要糾正。

盡管業務規則異常和數據沖突是不同類型的異常，但大多數情況下，可以使用相同的基本方法和基礎結構來處理它們。本節討論如何在智能客戶端應用程序中處理數據和業務規則沖突。

數據分區和鎖定

任何允許多個用戶訪問共享數據的系統都有產生沖突的可能。當您設計智能客戶端應用程序時，您必須確定它是否將數據分區以及如何執行鎖定，因為這些因素有助于確定在應用程序中發生沖突的可能性有多大。

數據分區

當不同用戶對數據的不同部分具有控制權時，可以使用數據分區。例如，銷售代表可能具有一些只分配給他或她的帳戶。在此情況下，您可以將數據分區，以便只有銷售代表可以更改這些帳戶。以這種方式將數據分區后，可以允許用戶對數據進行任意更改，而不必擔心遇到數據沖突。

將應用程序設計為使用數據分區通常會受到很多限制，因此在許多情況下不是好的解決方案。但是，如果數據分區對于特定應用程序是可行的，則應該認真地予以考慮，因為它有助于減少應用程序所產生的沖突的數量。

保守式鎖定

保守式鎖定意味著系統使用互相排斥的鎖來確保一次只有一個用戶對系統數據進行操作。對數據的所有請求都被序列化。例如，在出發之前，推銷員可能訪問數據庫，并且邏輯地為特定地區的客戶簽出客戶帳戶。這一簽出操作可能要求在辦公室里更新一個電子表格，并且向其他人發送電子郵件以更新帳戶狀態。現在，當該推銷員出差時，其余銷售人員就會明白該推銷員對這些客戶文件具有獨占的訪問權，并且可以隨意進行所需的任何修改。當該推銷員回到辦公室并將新數據與服務器數據進行同步時，應該沒有任何沖突。在同步數據之后，該推銷員將釋放邏輯鎖。

保守式鎖定的主要問題是：如果多個用戶需要同時對相同數據進行操作，則他們必須等待數據變得可用。對于偶爾連接的智能客戶端，數據可能在某個客戶端重新聯機之前一直保持鎖定，而這一時間可能很長。這就使得保守式鎖定在數據完整性方面很好（因為沒有發生沖突的可能性），但在并發性方面卻很差。

實際上，保守式鎖定僅適合于幾種類型的偶爾連接應用程序。例如，在文檔管理系統中，用戶在處理文檔時可能會有意地將文檔簽出一段持續很久的時間。但是，隨著可伸縮性和復雜性的提高，保守式鎖定正在成為一種不太可行的選擇。

開放式鎖定

大多數偶爾連接的智能客戶端應用程序都使用開放式鎖定，它允許多個用戶并發地訪問和操作相同的數據，并且假設各個用戶對數據進行的更改將不會發生沖突。開放式鎖定允許對數據進行高度并發性訪問，其代價是數據完整性將會降低。如果發生沖突，則需要一種能夠處理這些沖突的策略。

在大多數脫機方案中，您需要使用開放式鎖定。因此，您必須預料到會發生數據沖突，并且必須在確實發生數據沖突時對它們進行協調。

跟蹤未確認或暫定的數據

當您的用戶脫機工作時，他們已經更改的任何數據都沒有被確認為服務器上的更改。只有在這些數據已經與服務器進行合并而且沒有任何沖突之后，才能真正地將這些數據視為已確認的數據。對未確認的數據進行跟蹤是很重要的。在已經確認數據之后，可以對其進行標記并適當地使用。

您可能希望在應用程序的用戶界面中以不同的顏色或字體顯示未確認的數據，以便用戶可以知道這些數據是暫定的。通常，在已經確認數據之前，您的應用程序不應該允許在多個任務中使用這些數據。這可以防止未確認的數據溢出到其他需要已確認數據的活動中。使用已確認的數據并不能保證將來不會發生沖突，但應用程序起碼將知道數據曾經被確認過并且隨后已經被某個用戶進行了更改。

處理陳舊數據

即使數據尚未更改，它也可能因為不再是最新數據而變得不再正確。這樣的數據稱為陳舊數據。當您設計智能客戶端應用程序時，您需要確定如何處理陳舊數據以及如何防止您的智能客戶端使用陳舊數據。這對于偶爾連接的智能客戶端而言尤其重要，因為數據在客戶端首次脫機時可能是最新的，但在客戶端重新聯機之前可能變為陳舊數據。此外，在客戶端上為最新的數據在到達服務器時可能成為陳舊數據。例如，推銷員可能在某個星期五使用有效數據為各種項目創建了一份訂單，但是如果他或她沒有在下個星期一之前將該訂單提交給服務器，則這些項目的費用可能已經更改。

注 如果在應用程序重新聯機時，對服務請求進行排隊并且做好發送準備，則該請求排隊的時間越長，它遇到數據沖突或異常的可能性就越大。例如，如果您將某個服務請求（該請求包含許多項目的訂單）排隊，并且在很長一段時間內沒有發送該請求，則您訂購的項目可能停止生產或脫銷。

您可以使用許多技術來處理陳舊數據。您可以使用元數據來說明數據的有效性并且顯示數據的到期時間。這可以防止將陳舊數據傳遞到客戶端。

在服務器上，您可以選擇對來自客戶端的任何數據進行檢查，以確定它是否為陳舊數據，然后再根據情況決定是否允許它與服務器上的數據進行合并。如果該數據是陳舊數據，則可以在將該數據重新提交給服務器之前，確保客戶端更新其引用數據。

對于偶爾連接的應用程序而言，陳舊數據的風險大于始終連接的應用程序。因此，智能客戶端應用程序通常會執行附加的驗證步驟以確保數據是有效的。通過向系統中添加額外的驗證，您還可以確保您的服務對陳舊數據具有更高的容錯性，并且在某些情況下，您或許能夠在服務器上自動處理協調（即，將事務映射到新的帳戶）。

有時候，陳舊消息是無法避免的。處理陳舊數據的方式應該以您要建模的業務的規則為基礎。在某些情況下，陳舊數據是可以接受的。例如，假設為聯機目錄中的特定項目提交了一個訂單。該項目具有一個目錄編號，該編號由于聯機目錄更改已經陳舊。但是，該項目仍然可用且尚未更改，目錄編號更改對系統沒有影響，并且將生成正確的訂單。

另一方面，如果您要在兩個帳戶之間執行財務事務，并且其中一個帳戶尚未關閉，則您無法執行該事務。這里，數據的陳舊性確實很重要。

一個很好的一般性規則是讓業務對象為您處理陳舊數據的情況。您的業務對象可以驗證數據是否是最新的，如果數據是陳舊的，則可以不做任何事情、用等效的最新數據協調陳舊數據、將信息傳回到客戶端以便更新或者使用業務規則自動執行適當的響應。

陳舊數據的協調可能發生在客戶端、服務器或這兩者。在服務器處理協調可以使您的應用程序容易地檢測到沖突。在客戶端處理協調可以免除那些可能需要手動解決任何沖突的用戶或管理員的一些職責。

沒有處理陳舊數據的最佳方式。您的業務規則可能規定，如果客戶端無法解決沖突，則服務器是處理陳舊數據的最佳位置。如果服務器沒有足夠信息以自動處理這種情況，則您需要要求客戶端在與服務器進行同步之前清理它的數據。相反，您可能決定陳舊數據完全適合于您的應用程序，在此情況下您沒有什么好擔心的。

協調沖突

當您分析您所在組織的數據協調要求時，您應該考慮組織的工作方式。在某些情況下，因為不同的用戶負責不同的數據元素，所以有可能發生沖突。在其他情況下，沖突將更為頻繁地發生，您必須確保您具有相應的機制來處理它們。

無論您采取什么樣的預防措施，客戶端都有可能向網絡服務提交將導致違反業務規則或數據沖突的數據。當沖突確實發生時，遠程服務應該盡可能多地提供有關數據沖突的詳細信息。在某些情況下，數據沖突可能不是重大問題，并且可以由應用程序或服務器自動處理。例如，設想有一個客戶關系管理 (CRM) 系統，并且用戶更改了某個客戶的電話號碼。在服務器上更新該更改時，發現另一個用戶也已經更改了該電話號碼。您可能選擇對您的系統進行相應的設計，以便使最新的更改總是優先，或者您可能希望將沖突發送給管理員。如果管理員知道是誰在什么時候進行了這些更改，則他或她就可以做出有關保留哪一個更改的決策。重要的一點在于服務器和應用程序提供足夠的詳細信息以便進行自動處理，或者為用戶或管理員提供足夠的信息以便他或她能夠協調沖突。

數據協調可能是一個復雜且與具體情況有關的問題。每個業務和每個應用程序都具有稍微不同的規則、要求和假設。然而，您具有三個一般性的數據協調選項：

依次考察一下上述每個選項是有用的。

在服務器上自動協調數據

在某些情況下，您可以對您的應用程序進行相應的設計，以便服務器使用業務規則和自動過程來處理沖突，而不會影響客戶端。您可以確保最新的更改總是優先，合并兩個數據元素，或者采用更為復雜的業務邏輯。

在服務器上處理沖突對于可用性很有好處，并且使用戶免于過多地涉及協調過程或忍受該過程帶來的不便。您應該始終通過某種方法使客戶端了解所采取的任何協調操作；例如，通過向客戶端返回協調報告，并且解釋沖突以及它的解決方式。這樣就使客戶端可以保持其本地數據的一致性并且將協調結果通知用戶。

例如，假設應用程序允許用戶為本地緩存的目錄中的項目輸入訂單信息。如果用戶訂購的項目已經停止生產并且由較新但類似的型號取代，則訂單服務可以選擇用新項目替換原來的項目。然后，將向客戶端通知該更改，以便它可以適當地修改它的本地狀態。

在客戶端上自定義協調

在某些情況下，客戶端是執行協調的最佳位置，因為它了解有關原始請求的上下文的更多信息。應用程序或許能夠自動解決沖突。在其他情況下，用戶或管理員必須確定如何解決沖突。

要進行有效的客戶端協調，服務應該向客戶端發送足夠的數據，以使客戶端能夠就如何解決沖突進行明智的決策。應該將沖突的確切詳細信息報告給客戶端，以便該客戶端、用戶或管理員可以確定解決問題的最佳方式。

第三方協調

在某些情況下，您可能希望第三方來協調任何數據沖突。例如，可以要求管理員或超級用戶協調重要的數據沖突。他們可能是具有確定正確操作過程的職權的唯一用戶。在此情況下，需要通知客戶端決策已掛起。客戶端或許能夠通過使用暫定值繼續工作，但通常它必須等待至基礎沖突已經解決為止。當該沖突解決后，將通知客戶端。作為替代方法，客戶端還可以定期輪詢以確定狀態，然后在收到協調值時繼續工作。

與類似于 CRUD 的 Web 服務交互

許多 Web 服務都是使用類似于 Create, Read, Update, Delete (CRUD) 的接口創建的。本節討論幾種用于創建消耗此類服務的偶爾連接應用程序的策略。

Create

在 CRUD Web 服務中，創建記錄應該是一項比較簡單的任務，前提是您能夠正確地管理記錄的創建。最重要的事情是唯一標識所創建的每個記錄。大多數情況下，您可以通過使用唯一標識符作為記錄的主鍵做到這一點。這樣，即使在不同的客戶端上創建了兩個看上去完全相同的記錄，在發生合并復制時也將把這些記錄視為不同的記錄。

注 在某些情況下，您可能不希望將記錄視為唯一的。在這些情況下，您可以在兩個記錄沖突時生成異常。

您可以使用多種方法在脫機客戶端上創建唯一標識符。這些方法包括：

Read

讀取操作沒有數據沖突，因為讀取操作按照定義是只讀的。但是，對于偶爾連接的智能客戶端中的讀取操作而言，仍有可能發生問題。在客戶端脫機之前，您應該在客戶端上緩存所有需要讀取的數據。該數據在客戶端重新聯機之前可能變為陳舊數據，從而導致客戶端上出現不準確的數據，并且在與服務器進行同步時產生問題。有關處理陳舊數據的詳細信息，請參閱本章前面的“處理陳舊數據”。

Update

數據更新最有可能導致數據沖突，因為多個用戶可能更新相同的數據，從而在合并復制發生時導致沖突。您可以使用多種方法將發生沖突的可能性將至最低，并且在沖突確實發生時解決它們。有關詳細信息，請參閱本章前面的“管理數據和業務規則沖突”。

Delete

刪除記錄是非常簡單的，因為記錄只能刪除一次。嘗試刪除同一記錄兩次不會對系統產生任何影響。但是，在設計應用程序和 Web 服務以處理刪除時，您應該記住幾點。首先，您應該在客戶端上將相關記錄標記為暫時刪除，然后在服務器上將刪除請求排隊。這意味著如果服務器由于某種原因無法刪除該記錄，則可以在客戶端上撤消刪除。

與創建記錄時一樣，您還必須通過使用唯一標識符來確保您引用了相關記錄。這可以保證您總是在服務器上刪除了正確的記錄。

返回頁首

使用基于任務的方法

基于任務的方法使用對象將工作單元封裝為用戶任務。Task 對象負責處理用戶完成特定任務所需的狀態、服務和用戶界面交互。當您設計和生成支持脫機操作的智能客戶端應用程序時，基于任務的方法尤其有用，因為它使您可以將脫機行為的細節封裝在單個位置。這使用戶界面可以專門致力于解決與 UI 有關的問題，而不是致力于解決處理邏輯。通常，單個 Task 對象封裝（由用戶）與單個獨立工作單元相關聯的功能。任務的粒度和詳細信息將取決于確切的應用程序方案。任務的一些示例包括：

對于上述每個任務，都將實例化一個 Task 對象并使用它來指導用戶完成該過程，存儲所有需要的狀態，與用戶界面交互，并且與任何需要的服務交互。

當應用程序脫機工作時，它需要將服務請求排隊，并且可能使用暫定值或未確認的值進行本地狀態更改。在同步過程中，應用程序需要執行實際的服務請求，并且可能進行更多的本地狀態更改以確認服務請求的成功。通過將該過程的細節封裝在單個 Task 對象（該對象將服務請求放入隊列中，并且跟蹤暫定的和已確認的狀態更改）中，您可以簡化應用程序的開發，隔離實現更改，并且能夠以標準方式處理所有任務。Task 對象可以通過各種屬性和事件提供有關任務狀態的詳細信息，包括：

基于任務的方法的另一項好處是：它使應用程序可以致力于滿足用戶及其任務的需要，從而可以產生更為直觀的應用程序。

返回頁首

處理依賴性

如果用戶任務涉及到一個以上的服務請求，則需要非常小心地處理該任務，以便用戶可以在脫機時完成整個任務。困難在于服務請求通常是相互依賴的。例如，假設您具有一個允許為客戶預訂假期的應用程序。為了預訂假期，應用程序使用一些服務，按以下順序執行整個任務的各個部分：

上述每個服務都可能由不同的系統（甚至可能由不同的公司）實現。在理想情況下，每個服務請求每次都能成功，以便您的用戶可以成功地預訂汽車、旅館和飛機票，并且應用程序可以發送電子郵件以通知客戶端預訂了假期。但是，并非所有服務請求都是成功的，因此您的應用程序必須能夠解決錯誤條件，并且管理能夠影響它處理整個任務的方式的業務規則。為這種任務編寫代碼極為困難，因為該任務的各個部分（即，對特定服務的各個服務請求）都依賴于該任務的其他部分。

依賴性本身可能依賴于復雜的業務邏輯，這使影響整個任務的邏輯進一步復雜化。例如，您的假期預訂應用程序可能允許在沒有汽車的情況下預訂假期，前提是成功預訂了旅館和航班。各個服務請求之間的依賴性可以是正向 和反向 依賴性：

在服務器處理依賴性

要降低與服務請求之間的依賴性相關聯的復雜性，Web 服務應該為每個用戶任務提供單個服務請求。這就使用戶可以把將要在同步階段處理的任務作為對 Web 服務的單個原子請求來完成。單個原子請求消除了跟蹤服務請求依賴性（這可能使應用程序的客戶端或服務器端實現大大復雜化）的需要。

例如，您可以不像下面這樣將服務接口編寫為三個單獨的步驟：

BookCar() 
BookHotel() 
BookAirlineTickets() 

而是將它們合并為一個步驟：

BookVacation( Car car, Hotel hotel, Tickets airlineTickets ) 

以這種方式合并步驟意味著，就客戶端而言，您現在擁有了一個原子交互而不是三個單獨的交互。在該示例中，BookVacation Web 服務將負責在構成該服務的元素之間執行必要的協調。

在客戶端處理依賴性

您還可以在客戶端上跟蹤服務請求依賴性。該方法提供了相當大的靈活性，并且使客戶端可以控制任意數量服務之間的協調。但是，該方法難以開發和測試。基于任務的方法是在客戶端上跟蹤服務請求依賴性的好方法，并且提供了一種在一個位置封裝所需的全部業務邏輯和錯誤處理的方法，從而簡化了開發和測試。（有關基于任務的方法的詳細信息，請參閱本章前面的“使用基于任務的方法”。）

例如，用于預訂假期的 Task 對象將知道它必須執行三個服務請求。它將實現必要的業務邏輯，以便它可以在遇到錯誤條件時適當地控制服務請求。如果 BookCar 服務調用失敗，它可以通過 BookHotel 和 BookAirlineTickets 服務調用繼續工作。如果 BookAirlineTickets 服務調用失敗，則它將負責通過向每個服務創建一個補償事務服務請求來取消任何旅館或汽車預訂。圖 4.2 闡明了這一基于任務的方法。

圖 4.2 帶有相互依賴性服務的基于任務的方法

使用編排中間件

有時候，應用程序中的依賴性和相應的業務規則十分復雜，需要某種形式的編排中間件（如 Microsoft BizTalk? Server）來協調多個 Web 服務和一個客戶端應用程序之間的交互。編排中間件位于中間層，并且提供了一個表面 Web 服務來與智能客戶端交互。表面 Web 服務向客戶端呈現了一個特定于應用程序的適當接口，通過該接口可以只為每個用戶任務產生單個 Web 請求。當收到服務請求時，編排服務將通過啟動并協調對必要 Web 服務的調用（可能首先對結果進行整合，然后再將其返回到客戶端）來處理該請求。該方法提供了一種用于解決多個 Web 服務之間交互的、可伸縮性更高的方法。BizTalk 還提供了重要的服務，如數據轉換和業務規則引擎，這些服務可在與截然不同的 Web 服務或舊式系統交互時提供極大的幫助，還可以在復雜的業務情況下提供極大的幫助。另外，該方法還提供了重要的可用性和可靠性保證，從而有助于確保多個服務之間的一致性。圖 4.3 闡明了編排中間件的用法。

圖 4.3 用于協調服務依賴性的編排中間件

返回頁首

小結

智能客戶端需要在連接到網絡以及從網絡斷開連接時有效地工作。當您設計智能客戶端時，您需要確保它們可以在這兩種情況下有效地工作，并且能夠在這兩種情況之間無縫地轉換。

有兩種用于設計智能客戶端通訊的概括性的策略：面向服務的策略和以數據為中心的策略。當您已經確定使用哪種策略之后，您需要進行一些基本的設計決策，以便使您的智能客戶端能夠脫機工作。在大多數情況下，應該將客戶端設計為使用異步通訊和簡單的網絡交互。客戶端需要緩存數據以便在脫機時使用，而且您需要一種在客戶端重新聯機后處理數據和業務規則沖突的方法。在許多情況下，脫機客戶端允許用戶執行一些相互依賴的任務。您需要處理這些依賴性，以防其中某個任務到達服務器時發生失敗。您的智能客戶端還可能需要與類似于 CRUD 的 Web 服務交互。

基于任務的方法可以顯著簡化將應用程序脫機的過程。請考慮在您的智能客戶端中實現該方法；該方法還可以為您提供一種（在服務器和在客戶端）處理依賴性的有效方法。

轉到原英文頁面