簡介
如今，N 層應(yīng)用程序已經(jīng)成為構(gòu)建企業(yè)軟件的標(biāo)準(zhǔn)。對于大多數(shù)人來說，N 層應(yīng)用程序就是被分成多個獨立的邏輯部分的應(yīng)用程序。最常見的選擇是分為三個部分：表示、業(yè)務(wù)邏輯和數(shù)據(jù)，當(dāng)然還可能存在其他的劃分方法。N 層應(yīng)用程序最初是為了解決與傳統(tǒng)的客戶端/服務(wù)器應(yīng)用程序相關(guān)的問題而出現(xiàn)的，但是，隨著 Web 時代的到來，這一體系結(jié)構(gòu)開始成為新開發(fā)項目的主流。
Microsoft Windows? DNA 技術(shù)已成為 N 層應(yīng)用程序的非常成功的基礎(chǔ)。Microsoft .NET 框架也為構(gòu)建 N 層應(yīng)用程序提供了堅實的平臺。然而，。NET 所帶來的變化使結(jié)構(gòu)設(shè)計人員應(yīng)當(dāng)重新考慮他們在 Windows DNA 領(lǐng)域中所學(xué)的有關(guān)設(shè)計 N 層應(yīng)用程序的某些知識。更重要的是，對內(nèi)置于 .NET 框架的 XML Web services 的基本支持允許開發(fā)人員構(gòu)建突破傳統(tǒng) N 層方法的新應(yīng)用程序。要了解如何更好地構(gòu)建 .NET 應(yīng)用程序的體系結(jié)構(gòu)，您需要了解這一新領(lǐng)域中發(fā)生了哪些變化，以及如何充分利用這些變化。
本文將對這些問題進行討論。首先回顧一下在使用 Windows DNA 構(gòu)建 N 層應(yīng)用程序中學(xué)到的關(guān)鍵體系結(jié)構(gòu)知識。然后，再按同一順序?qū)⑦@些知識應(yīng)用到使用 .NET 框架構(gòu)建應(yīng)用程序的過程中，從而對它們進行檢驗。最后一部分對使用 XML Web services 的應(yīng)用程序的體系結(jié)構(gòu)提供了一些建議。
Windows DNA 環(huán)境
將應(yīng)用程序恐解成多個邏輯部分是很有鈾的。將一個大軟件分成幾個小的部分會更利于軟件的構(gòu)建、重復(fù)利用和修改，對適應(yīng)不同的技術(shù)或不同典業(yè)務(wù)組織也很有幫助。同時，還有一些綜合因素需要考慮。雖然模塊化和重復(fù)使用性很有效，但它們可能會導(dǎo)致贏用程序不能象使用其他方法那樣安全、易管理和快速。本節(jié)將回顧一些從使用 Windows DNA牸際豕菇?N 層應(yīng)用程序的普遍經(jīng)驗中所獲得的基1咎逑到峁怪丁?
編寫業(yè)務(wù)邏輯
Windows DNA 應(yīng)用程序通常使用以下三種實現(xiàn)方式中的一種或多種方式來實現(xiàn)其業(yè)務(wù)邏輯：
●ASP 頁
●COM 組峻，可能使用 COM+ 提供的其他服務(wù)
●在 DBMS 中運行的存儲過程
一般來講，在 ASP 頁中編寫過多的業(yè)務(wù)邏輯并不是一個好辦法。因為必須使用簡單的語言，例如 Microsoft Visual Basic? Script (VBScript)，而且每次執(zhí)行時都要解釋代碼，這會對性能造成影響。而且 ASP 頁中的代碼不好維護，主要是因為業(yè)務(wù)邏輯通常與創(chuàng)建用戶界面的表示代碼混合在一起。
鑒于這種情況，建議在編寫中間層業(yè)務(wù)邏輯時，將業(yè)務(wù)邏輯當(dāng)作 COM 對象來實現(xiàn)。這種方法比編寫純粹的 ASP 應(yīng)用程序要稍微復(fù)雜一點，但是可以使用全功能語言來生成編譯好的可執(zhí)行文件，因此其結(jié)果要快得多。將業(yè)務(wù)邏輯包裝在 COM 對象中還可以將此代碼與包含在 ASP 頁中的表示代碼完全分隔開來，從而使應(yīng)用程序更易于維護。
從 COM 到 COM+，其體系結(jié)構(gòu)相差無幾。但是，正如許多 Windows DNA 體系結(jié)構(gòu)設(shè)計人員所了解的，除非真正需要，否則不應(yīng)使用 COM+ 提供的核心服務(wù)，如事務(wù)、實時 (JIT) 激活、基于角色的安全性和線程服務(wù)等。使用其他開發(fā)平臺提供的 COM+ 或類似服務(wù)自然會導(dǎo)致應(yīng)用程序速度更慢、更復(fù)雜。只有在以下情況下使用 COM+ 才有意義：
●需要跨越不同資源管理器(如 Microsoft SQL Server? 和 Oracle)的分布式事務(wù)。
●應(yīng)用程序可以有效地利用基于角色的安全性。
●可以增強 Microsoft Visual Basic? 6.0 的線程操作。
●JIT 激活能夠提高性能;瀏覽器客戶端很少出現(xiàn)這種情況，因為 ASP 頁是通過 JIT 有效激活的。
●COM+ 的配置優(yōu)勢大大簡化了應(yīng)用程序的部署。
編寫業(yè)務(wù)邏輯的第三種方式是，創(chuàng)建一些作為存儲過程在數(shù)據(jù)庫管理系統(tǒng) (DBMS) 中運行的代碼。盡管使用存儲過程的主要原因是將數(shù)據(jù)庫架構(gòu)的詳細信息與業(yè)務(wù)邏輯分隔開以簡化代碼的管理和提高安全性，但代碼與數(shù)據(jù)如此接近也有助于優(yōu)化性能。那些必須獨立于 DBMS 的應(yīng)用程序(例如由獨立的軟件供應(yīng)商創(chuàng)建的應(yīng)用程序)通常要避免使用這種方法，因為它會將應(yīng)用程序鎖定到某個特定的數(shù)據(jù)庫系統(tǒng)中。存儲過程的編寫和調(diào)試可能會比 COM 對象的編寫和調(diào)試難，而且此方法會減少重復(fù)使用代碼的機會，這是因為 COM 對象通常比存儲過程更易于重復(fù)使用。但是大多數(shù)自定義應(yīng)用程序仍然連接到最初創(chuàng)建它們的 DBMS 上，因此使用存儲過程的性能優(yōu)勢還是很大的。鑒于這種情況，那些必須盡可能運行良好的 Windows DNA 應(yīng)用程序通常對部分或全部的業(yè)務(wù)邏輯都使用存儲過程。
構(gòu)建客戶端
Windows DNA 既支持用 Visual Basic 等語言編寫的本地 Windows 客戶端，也支持瀏覽器客戶端。瀏覽器客戶端的局限性較大，尤其同時將 Microsoft Internet Explorer 和 Netscape 作為瀏覽器時。因此，應(yīng)用程序通常同時擁有瀏覽器客戶端和本地 Windows 客戶端。瀏覽器客戶端提供的界面很有限，但用它可以方便地訪問 Internet，而 Windows 客戶端能提供全功能的界面。使用可下載的 Microsoft ActiveX? 控件可以創(chuàng)建更復(fù)雜的瀏覽器界面，但必須確保瀏覽器是 Internet Explorer，并且用戶愿意信任應(yīng)用程序的創(chuàng)建者。
管理瀏覽器應(yīng)用程序中的狀態(tài)
ASP 應(yīng)用程序可以使用幾個不同的機制來維護服務(wù)器上客戶端請求之間的信息。但是 Windows DNA 中有一條嚴格的規(guī)則，如果應(yīng)用程序在兩臺或多臺機器之間平衡負載，則絕對不能使用 ASP Session 對象存儲每個客戶端的狀態(tài)。ASP 的 Session 對象被鎖定在一臺機器上，因此不能用于負載平衡的應(yīng)用程序。
ASP Session 對象和 ASP Application 對象還有另一個限制。使用它們中的任何一個來存儲 ADO 記錄集都會大大降低可伸縮性，因為它限制了應(yīng)用程序開發(fā)多線程的能力。因此，在這兩個對象的任何一個中存儲記錄集都不是好辦法。
分布式通信
在 Windows DNA 中，選擇運行在不同機器上的組件的通信方式非常簡單：DCOM 可以說是唯一的選擇。單純從體系結(jié)構(gòu)上來看，DCOM 是 COM 的簡單擴展。但實際上，DCOM 還有許多其他含義，其中包括：
●由于實際上是其自有協(xié)議，因而使用 DCOM 與遠程 COM+ 對象進行通信非常直接。
●只要配置正確，DCOM 將是非常安全的協(xié)議。但是要實現(xiàn)這種配置并不容易，因此該協(xié)議不太容易使用。盡管如此，DCOM 自身仍能提供很好的分布式身份驗證、數(shù)據(jù)完整性和數(shù)據(jù)保密性，特別是在 Windows 2000 域內(nèi)。
●由于 DCOM 需要打開任意端口，因此不適合與防火墻配合使用。所以，對于必須通過 Internet 進行通信的應(yīng)用程序，一般不能使用 DCOM.
訪問存儲數(shù)據(jù)
可以將使用 ADO 構(gòu)建的數(shù)據(jù)訪問體系結(jié)構(gòu)分為兩類：輕型和重型。輕型 ADO 客戶端盡可能簡短地保持數(shù)據(jù)庫連接，并使用存儲過程寫入數(shù)據(jù)庫。輕型客戶端使用以下三種方法之一檢索數(shù)據(jù)：
●通過使用只讀的、僅向前游標(biāo)填充記錄集;
●通過存儲過程輸出參數(shù);
●使用數(shù)據(jù)流(在 ADO 的較新版本中)。
重型客戶端則會較長時間地保持數(shù)據(jù)庫連接。這類應(yīng)用程序依賴于開放式連接，以及那些連接所允許的有狀態(tài)的服務(wù)器端游標(biāo)，以：
●使記錄集能夠直接訪問其他用戶或應(yīng)用程序所做的更改;
●啟用保守式鎖定;
●盡可能減少復(fù)制到 ADO 客戶端的數(shù)據(jù)量，以減少網(wǎng)絡(luò)通信量。與輕型客戶端不同，使用服務(wù)器端游標(biāo)的客戶端可以將查詢結(jié)果保留在數(shù)據(jù)庫內(nèi)，直到真正需要這些數(shù)據(jù)時再取出。此外，這種方法向記錄集復(fù)制的元數(shù)據(jù)較少，而把更多的數(shù)據(jù)保留在數(shù)據(jù)庫中。
輕型應(yīng)用程序最具伸縮性，因為它們最有效地使用了數(shù)據(jù)庫連接這一稀有資源。相比之下，重型應(yīng)用程序必須保持長期有效的數(shù)據(jù)庫連接，因為這是有狀態(tài)的服務(wù)器端游標(biāo)所要求的。這就大大地限制了應(yīng)用程序的可伸縮性，尤其不適用于 Internet 服務(wù)器應(yīng)用程序。盡管使用 ADO 開發(fā)重型應(yīng)用程序可能更簡單，但通常這并不是最佳選擇。
ADO 也不是特別適用于處理 XML 文檔等分層數(shù)據(jù)。ADO 完成此項工作的功能用法復(fù)雜，且不易理解。同樣，ADO 僅為訪問 SQL Server 2000 的 XML 功能提供有限支持，因此，Windows DNA 應(yīng)用程序通常都避免使用 ADO 處理分層數(shù)據(jù)。
將數(shù)據(jù)傳遞到客戶端
對于所有 N 層應(yīng)用程序而言，將數(shù)據(jù)從中間層有效地移動到客戶端都是一個關(guān)鍵的環(huán)節(jié)。當(dāng)使用 DCOM 與 Windows 客戶端通信時，Windows DNA 應(yīng)用程序可以使用 ADO 斷開連接的記錄集。當(dāng)確保瀏覽器為 Internet Explorer 時，此選項也可用于瀏覽器客戶端。而將數(shù)據(jù)發(fā)送到任意瀏覽器則比較困難。一種方法是顯式地將數(shù)據(jù)轉(zhuǎn)換為 XML，然后將數(shù)據(jù)和所有必要的腳本代碼發(fā)送到瀏覽器。
.net 環(huán)境
.NET 支持傳統(tǒng)的 N 層應(yīng)用程序、Web Services 應(yīng)用程序以及將二者的元素結(jié)合在一起的應(yīng)用程序。本節(jié)首先介紹 .NET 如何影響 N 層應(yīng)用程序，然后介紹構(gòu)建 Web services 應(yīng)用程序過程中的幾個主要的體系結(jié)構(gòu)問題。
將 N 層應(yīng)用程序與 .NET 綁定在一起
上一節(jié)中介紹的某些問題同樣適用于 Windows DNA 應(yīng)用程序和使用 .NET 框架構(gòu)建的應(yīng)用程序。例如，只有當(dāng)滿足前面所列的一個或多個條件時，才能使用 COM+(在 .NET 框架中稱為企業(yè)服務(wù))。同樣，將業(yè)務(wù)邏輯構(gòu)建為存儲過程在很多 N 層應(yīng)用程序中都可以獲得更好的性能。
同時，。NET 框架中到處都是新技術(shù)和現(xiàn)有技術(shù)的新版本。這些增強功能為 N 層應(yīng)用程序的優(yōu)化體系結(jié)構(gòu)帶來了多種變化。本節(jié)將按照前面介紹的分類，介紹 .NET 框架是如何改變體系結(jié)構(gòu)設(shè)計人員在創(chuàng)建 N 層應(yīng)用程序時所做的決定的。
編寫業(yè)務(wù)邏輯
與在 Windows DNA 中創(chuàng)建 N 層業(yè)務(wù)邏輯的三種可選方法(ASP 頁、COM 組件和存儲過程)不同，。NET 框架只提供了兩種方法：程序集和存儲過程。對于瀏覽器應(yīng)用程序，可以使用 Microsoft ASP.NET .aspx 頁來創(chuàng)建程序集。與 ASP 不同，在這種情況下完全使用 ASP.NET 編寫業(yè)務(wù)邏輯通常是一個比較好的方法。
其中一個原因就是 ASP.NET 的內(nèi)含代碼選項。在傳統(tǒng)的 ASP 頁中，以一種可維護的方式混合業(yè)務(wù)代碼和表示代碼并不是一件容易的事，而 .aspx 頁使用內(nèi)含代碼能夠完全將這兩種代碼分開。Windows DNA 應(yīng)用程序可能需要同時使用 ASP 頁和 COM 對象才能實現(xiàn)可維護性，而使用 .NET 框架構(gòu)建的應(yīng)用程序則只需使用 ASP.NET.此外，。aspx 頁中包含的業(yè)務(wù)邏輯可以用任何基于 .NET 的語言編寫，而不僅限于傳統(tǒng) ASP 頁所支持的簡單的腳本語言。而且，ASP.NET 是編譯頁面而不是解釋頁面，因此 ASP.NET 應(yīng)用程序速度可以非�？�。雖然使用 Windows DNA 構(gòu)建的應(yīng)用程序可以使用 ASP 頁和 COM 對象來達到足夠高的性能，但 .NET 只需使用 ASP.NET 便可構(gòu)建具有同樣優(yōu)良性能的應(yīng)用程序。最后，業(yè)務(wù)邏輯使用 ASP.NET 緩存來減少對包含常用數(shù)據(jù)的數(shù)據(jù)庫的訪問，這樣可以大大提高性能。
但是，需要指出的是，對于包含在 .aspx 頁中的代碼，即使是使用內(nèi)含代碼，其重復(fù)使用也比標(biāo)準(zhǔn)的程序集困難。例如，從 Windows 窗體客戶端訪問 .aspx 頁中的代碼會遇到很多問題。
構(gòu)建客戶端
使用 .NET 框架可減少對 Windows 客戶端的需求，通常只需要一個瀏覽器客戶端即可。其中一個原因在于，ASP.NET Web 控件允許構(gòu)建和/或購買可重復(fù)使用的瀏覽器圖形用戶界面 (GUI) 元素，從而能夠更方便地構(gòu)建更有用的瀏覽器客戶端。而且可以將基于 .NET 框架的組件下載到 Internet Explorer 客戶端，然后使用部分信任來運行這些組件(而不使用 ActiveX 控件所要求的全是全非信任模式)，這有助于構(gòu)建更好的用戶界面。
管理瀏覽器應(yīng)用程序中的狀態(tài)
由于 ASP Session 對象被綁定到一臺機器上，因此它并未發(fā)揮出應(yīng)有的作用，而使用 .NET 框架就避免了這種限制。與 ASP 不同，ASP.NET Session 對象可以被兩臺或多臺機器共享，從而可以使用 Session 對象來維護負載平衡的 Web 服務(wù)器領(lǐng)域中的狀態(tài)，使其更加有用。而且，由于 Session 對象的內(nèi)容可以選擇存儲在 SQL Server 數(shù)據(jù)庫中，這種機制可用于出現(xiàn)故障時必須一直保持每個客戶端的狀態(tài)的應(yīng)用程序中。
影響 ASP.NET 應(yīng)用程序體系結(jié)構(gòu)的另一個重要更改在于，數(shù)據(jù)集可以存儲在 Session 和 Application 對象中而無需包含線程，這一點與 ASP 不同。也就是說，在 Windows DNA 中嚴格規(guī)定的不能將記錄集存儲在這些對象中的規(guī)則不適用于 .NET 框架中的數(shù)據(jù)集。這就使得查詢結(jié)果的存儲更加簡單也更加自然。
分布式通信
與 Windows DNA 相比，.NET 框架為應(yīng)用程序的分布式部件之間的通信提供了更多選擇，包括：
●。NET Remoting，提供 TCP 通道和 HTTP 通道;
●ASP.NET 支持在 .asmx 頁中實現(xiàn)的、可通過 SOAP 調(diào)用的 XML Web services;
●與遠程 COM 對象通信所需的 DCOM.
選項越多，意味著體系結(jié)構(gòu)的選擇也越多，這也意味著做選擇時有更多需要考慮的因素。使用 .NET 框架創(chuàng)建分布式應(yīng)用程序時要了解的體系結(jié)構(gòu)問題包括：
●直接與遠程 COM+ 對象進行通信要求使用 DCOM，而不能使用 .NET Remoting.由于 DCOM 的建立和使用都相當(dāng)復(fù)雜，因此應(yīng)盡量避免這種通信。在某些情況下，有必要通過托管代碼處理現(xiàn)有的 COM+ 對象，盡管這樣做所要求的 COM 互操作性會降低性能。
●。NET Remoting TCP 通道沒有提供內(nèi)置的安全性。與 DCOM 不同，它不提供嚴格的身份驗證、數(shù)據(jù)完整性或數(shù)據(jù)保密服務(wù)。但它并非一無是處，TCP 通道比 DCOM 更容易配置。
●DCOM 不能很好地與防火墻配合使用，。NET Remoting HTTP 通道與之不同，它是專門為在 Internet 上進行有效通信而設(shè)計的。而且，由于可以使用 SSL，此選項能夠為數(shù)據(jù)提供安全的路徑。通常，對于 Intranet 通信而言，TCP 通道是較好的選擇;而對于 Internet 通信，則更適合使用 HTTP 通道或 ASP.NET SOAP 支持。
●。NET Remoting HTTP 通道和用于 XML Web services 的 ASP.NET 支持都能實現(xiàn) SOAP.但這兩種實現(xiàn)卻截然不同，各有其特定的目的。。NET Remoting 注重保持公共語言運行時的確切語義，因此當(dāng)遠程系統(tǒng)也運行 .NET 框架時，它是最佳選擇。ASP.NET 則注重提供絕對標(biāo)準(zhǔn)的 XML Web services，因此當(dāng)遠程系統(tǒng)是基于 .NET 的平臺或任何其他平臺時，它是最佳選擇。而且 ASP.NET 比 .NET Remoting HTTP 通道的速度快。但 HTTP 通道也有優(yōu)點，它允許通過引用和真正的異步回調(diào)來傳遞參數(shù)，這是 ASP.NET 中的 SOAP 支持所不具備的功能。
訪問存儲數(shù)據(jù)
ADO 能夠方便地構(gòu)建重型客戶端，但客戶端的伸縮性較差，ADO.NET 與 ADO 不同，它更適用于構(gòu)建輕型客戶端。ADO.NET 客戶端使用僅向前的只讀游標(biāo)讀取數(shù)據(jù)。它不支持有狀態(tài)的服務(wù)器端游標(biāo)，因此其編程模式鼓勵短時間的連接。直接讀取和處理數(shù)據(jù)的客戶端可以使用 ADO.NET 的 DataReader 對象，它不為返回的數(shù)據(jù)提供緩存�；蛘�，可以將數(shù)據(jù)讀入 DataSet 對象中，將其作為從 SQL 查詢和其他源中返回的數(shù)據(jù)的緩存。但是，與 ADO 記錄集不同，數(shù)據(jù)集不能顯式地維護與數(shù)據(jù)庫的開放連接。
如前面所述，ADO 生成的重型方法還存在一些其他問題。這些問題可以在 ADO.NET 中解決，如下所示：
●對于將數(shù)據(jù)存儲在數(shù)據(jù)集并要求訪問由其他用戶或應(yīng)用程序所做的更改的 ADO.NET 客戶端，需要包含顯式代碼才能進行這些更改。該代碼通常還需要為每個所進行的檢查打開一個數(shù)據(jù)庫連接。
●盡管 ADO.NET 并不直接支持保守式鎖定，但通過使用 ADO.NET 事務(wù)或在存儲過程中實現(xiàn)所需的功能，客戶端仍然可以獲得同樣的效果。
●與 ADO 不同，ADO.NET 不允許將部分查詢結(jié)果保留在數(shù)據(jù)庫中(可以使用服務(wù)器端游標(biāo)從中進行訪問)。雖然 ADO.NET 確實比 ADO 檢索的元數(shù)據(jù)要少，但應(yīng)用程序仍應(yīng)設(shè)計為能夠?qū)⑺械牟樵兘Y(jié)果從數(shù)據(jù)庫傳遞到 ADO.NET 客戶端。
ADO.NET 中影響體系結(jié)構(gòu)選擇的另一項更改是其對處理分層數(shù)據(jù)(特別是 XML 文檔)的支持增強了。將 ADO.NET 數(shù)據(jù)集轉(zhuǎn)換成 XML 非常簡單，就象訪問 SQL Server 2000 的 XML 功能一樣。因此，在 Windows DNA 中可能被強制裝入關(guān)系模型中的分層數(shù)據(jù)現(xiàn)在可以以其原始形式提供訪問。
將數(shù)據(jù)傳遞到客戶端
將數(shù)據(jù)有效地傳遞到客戶端對于在 .net 框架上構(gòu)建的 N 層應(yīng)用程序和使用 Windows DNA 構(gòu)建的應(yīng)用程序同樣重要。一項重要的更改在于，ADO.NET 數(shù)據(jù)集可自動序列化成 XML，從而使得各層之間的數(shù)據(jù)傳遞更加簡單。雖然在 Windows DNA 中也可以使用這種方法，但 .NET 使通過 XML 的信息交換變得更加簡單、直接。
XML Web Services 體系結(jié)構(gòu)
在構(gòu)建分布式應(yīng)用程序的過程中，可以通過多種方法來使用 XML Web services 的 SOAP、Web Services 說明語言 (WSDL) 以及其他技術(shù)。例如：
●使用 SOAP 而不是僅僅使用 HTTP 連接到 N 層應(yīng)用程序的 Web 客戶端。連接建立后，該客戶端可以是能夠進行 SOAP 調(diào)用的任意設(shè)備。之后，客戶端可以為其用戶提供更多的功能，因為它能夠直接調(diào)用遠程服務(wù)器中的方法。
●將可能是在基于 .NET 框架的平臺上構(gòu)建的 N 層應(yīng)用程序與在其他平臺(例如 Java 應(yīng)用程序服務(wù)器)上構(gòu)建的另一個應(yīng)用程序連接起來。
●連接兩個大型應(yīng)用程序，或者連接一個企業(yè)資源規(guī)劃 (ERP) 系統(tǒng)與另一個 ERP 系統(tǒng)或任何其他應(yīng)用程序。正如這些示例所示，XML Web services 不僅僅適用于 N 層應(yīng)用程序，其應(yīng)用范圍十分廣闊。
不管如何使用，XML Web services 都會帶來許多新的體系結(jié)構(gòu)問題。XML Web services 與 N 層應(yīng)用程序通常使用的更為傳統(tǒng)的中間件技術(shù)之間的最主要的差別或許在于，XML Web services 提供的是“松散耦合”。遺憾的是，這個詞對于不同的用戶有著不同的含義。在本文中，它是指具有以下特點的通信應(yīng)用程序：
●應(yīng)用程序在很大程度上相互獨立，并且通常由不同的組織控制。
●并不完全可靠。不能保證每個通信應(yīng)用程序在所有時間都可用。
●其交互操作可以是同步的，也可以是異步的。Web services 客戶端可能阻塞對某個請求的響應(yīng)的等待，也可以在發(fā)出請求后去做其他事，稍后再來檢查響應(yīng)。
●這些基本特點為使用 XML Web services 的應(yīng)用程序提供了很多體系結(jié)構(gòu)方面的原則。雖然有些問題可能會在以后的工作中得到解決，如 Microsoft 的 Global XML Web Services Architecture (GXA) specifications(英文)，但是目前，創(chuàng)建有效的 XML Web services 應(yīng)用程序的用戶必須要了解這些問題。其中包括：
●安全性可能會比較復(fù)雜。預(yù)先規(guī)劃端對端身份驗證和有效授權(quán)十分重要。端對端的數(shù)據(jù)完整性和數(shù)據(jù)保密性對某些應(yīng)用程序也很重要�？赡苡斜匾诓煌陌踩珯C制之間進行映射，當(dāng)然最好盡量避免這種情況�；ゲ僮餍钥赡軙蔀閱栴}。由于規(guī)范還相對不成熟，不同供應(yīng)商的 SOAP 實現(xiàn)還不能始終很好地協(xié)作。
●修改現(xiàn)有應(yīng)用程序以便可以通過 XML Web services 進行訪問時，可能會出現(xiàn)問題。當(dāng)把從未打算要在一起使用的程序連接在一起時，總會出現(xiàn)速度、可伸縮性和安全性等問題�，F(xiàn)有應(yīng)用程序通常不是作為服務(wù)器而構(gòu)建的，因此處理一些很小的請求就會輕易搞垮它們。減少請求數(shù)量，而增加每個請求中包含的數(shù)據(jù)可能會提高應(yīng)用程序的性能。此外，現(xiàn)有應(yīng)用程序通常不能處理預(yù)料之外的負載，例如向 Internet 公開軟件時可能產(chǎn)生的負載。如果可能，使用某種排隊機制以在請求被響應(yīng)之前將請求存儲起來，這可能會有所幫助。
●調(diào)節(jié)故障非常重要。尤其是只需要一次語義的請求，通常需要格外小心。例如，請求可能會超時，從而觸發(fā)重試，但原來的請求可能只是因為某種原因被延遲而已。如果針對單個調(diào)用執(zhí)行兩次遠程 Web service 會出現(xiàn)問題，則必須創(chuàng)建某種機制來解決這個問題。
●不可能提供依賴于分布式鎖定(跨越組織邊界保持)的端對端事務(wù)。大多數(shù)組織不允許“外來”應(yīng)用程序鎖定數(shù)據(jù)，因此不可能實現(xiàn)兩階段提交樣式的事務(wù)。而只能考慮為任何必要的回滾使用補償事務(wù)。
●由于收到的數(shù)據(jù)可能跨越應(yīng)用程序和組織邊界，Web services 通信的每一端可能都需要仔細檢查該數(shù)據(jù)。雖然應(yīng)用程序的創(chuàng)建者可能十分信任由他們自己的應(yīng)用程序的其他部分所生成的數(shù)據(jù)的準(zhǔn)確性，但他們不能對其他應(yīng)用程序抱以同樣的信任。收到的信息甚至可能包含惡意代碼，因此必須仔細檢查。
●SOAP 及其攜帶的 XML 定義的數(shù)據(jù)非常多。在一個調(diào)用中傳遞太多數(shù)據(jù)可能會搞垮低帶寬的網(wǎng)絡(luò)。反過來，在一個調(diào)用中傳遞的數(shù)據(jù)太少又會搞垮處理這些請求的應(yīng)用程序。盡管這很困難，但找到正確的平衡點還是很重要的。
小結(jié)
體系結(jié)構(gòu)是關(guān)鍵。為應(yīng)用程序(尤其是分布于多個系統(tǒng)的應(yīng)用程序)選擇正確的結(jié)構(gòu)是至關(guān)重要的。如果選擇了錯誤的體系結(jié)構(gòu)，不管開發(fā)人員多么優(yōu)秀，通常都無法在實現(xiàn)過程中修復(fù)。錯誤的決定會導(dǎo)致性能降低、安全性降低以及應(yīng)用程序需要更新時可用的選項較少。
Windows DNA 為 N 層應(yīng)用程序奠定了一個堅實的基礎(chǔ)，Windows 開發(fā)人員可以根據(jù)他們從 DNA 領(lǐng)域所學(xué)到的知識來構(gòu)建應(yīng)用程序，把其中的大部分應(yīng)用到新的 .NET 環(huán)境中。不過，了解本文所建議的更改將有助于創(chuàng)建更快、更安全、功能更強的應(yīng)用程序。對于 N 層應(yīng)用程序以及采用 Web services 新技術(shù)的應(yīng)用程序來說，。NET 可提供的功能很多。
本文轉(zhuǎn)載自CSDN BLOG,原文地址:http://blog.csdn.net/iwascat/archive/2007/01/23/1490902.aspx