ASP.NET Web 服務還是 .NET Remoting:如何選擇(2)

來源:互聯網
上載者:User
 分布式應用程式設計:ASP.NET Web 服務和 .NET Remoting
  ASP.NET Web 服務支援 XML 結構描述類型系統,提供一種簡單的編程模型,使用範圍廣,可以跨平台使用。.NET Remoting 支援運行時類型的系統,提供較複雜的編程模型,使用範圍較窄。這種本質上的差別是決定使用哪種技術的主要因素。但是,還要考慮很多其他設計因素,包括傳輸協議、主機處理序、安全性、效能、狀態管理以及對事務的支援等。
  
  傳輸協議和主機處理序
  儘管 SOAP 規範並不要求用 HTTP 作為傳輸協議,但是用戶端只能通過 HTTP 訪問使用 ASP.NET Web 服務實現的 Web 服務,因為它是 ASP.NET 支援的唯一一種傳輸協議。服務是通過 IIS 調用的,並在 ASP.NET 的輔助進程 aspnet_wp.exe 中執行。
  
  .NET Remoting 使您能夠在任何類型的應用程式(包括 Windows 表單、託管的 Windows 服務、控制台應用程式或 ASP.NET 輔助進程)中靈活地託管遠程對象。正如前面所述,.NET Remoting 提供兩個傳輸通道 - TCP 和 HTTP。這兩個通道都能使用通訊端提供任意發送和接收進程之間的通訊。
  
  它還能將 HTTP 通道與 IIS 和 ASP.NET 輔助進程整合。這一點很重要,原因有以下幾點。首先,它是當用戶端請求到達時自動啟動 .NET Remoting 端點的唯一方法。.NET Remoting 管線不包括啟動遠程伺服器所需的 DCOM 類別型的服務控制管理員 (SCM)。如果從任意進程中提供遠程對象,則需要確保那些進程正在運行。還要確保它們是安全執行緒的,例如,在啟動線程 B 以關閉進程後,線程 A 不能啟用物件。如果從 ASP.NET 提供遠程對象,則可以利用 Aspnet_wp.exe 輔助進程,這樣既可自動啟動又具有安全執行緒的優勢。第二,與 IIS 整合是確保跨進程 .NET Remoting 調用的唯一途徑,如下一節所述。
  
  ASP.NET Web 服務和 .NET Remoting 基礎結構都是可擴充的。您可以過濾入站和出站訊息,從多方面控制類型封送和中繼資料的產生。使用 .NET Remoting,還能實現您自己的格式化程式和通道。
  
  安全性
  由於 ASP.NET Web 服務依賴於 HTTP,因此它們與標準的 Internet 安全性基礎結構相整合。ASP.NET 利用 IIS 的安全性功能,為標準 HTTP 驗證方案(包括基本、簡要、數位憑證,甚至 Microsoft .NET Passport)提供了強有力的支援。(還可以使用 Windows 整合驗證,但只能用於信任域中的用戶端。)使用可用的 HTTP 驗證方案的一個優勢在於,無需在 Web 服務中更改代碼,IIS 是在 ASP.NET Web 服務被調用之前執行驗證的。ASP.NET 還支援基於 .NET Passport 的驗證和其他自訂的驗證方案。ASP.NET 支援基於目標 URL 的存取控制,並通過與 .NET 程式碼存取安全性 (CAS) 基礎結構的整合支援存取控制。SSL 可用於確保通訊的安全。
  
  儘管這些標準傳輸技術對於確保 Web 服務相當有效,但它們只能做到這種程度。在涉及到不同信任域中多個 Web 服務的複雜情況下,還得建立自訂的特殊解決方案。Microsoft 和其他公司正致力於建立一套安全性規範,該規範將基於 SOAP 訊息的可擴充性提供訊息層級的安全性功能。這些規範之一是 XML Web 服務安全性語言(WS-Security [英文]),它為訊息層級的憑據傳輸、訊息完整性和訊息保密定義了架構。
  
  正如上一節所述,一般情況下,.NET Remoting 管線不能確保跨進程調用的安全。使用 ASP.NET 託管於 IIS 中的 .NET Remoting 端點可以利用 ASP.NET Web 服務可用的所有安全性功能,包括對使用 SSL 確保有線通訊的安全性的支援。如果您正在使用託管在進程中的 TCP 通道或 HTTP 通道(而不是 aspnet_wp.exe),則必須自己執行身分識別驗證、授權和保密機制。
  
  另一個要關注的安全性問題是,在不必更改預設安全性策略的情況下,從不完全信任環境中執行代碼的能力。ASP.NET Web 服務用戶端代理可以在這些環境中工作,但 .NET Remoting 代理則不能。要從不完全信任環境中使用 .NET Remoting 代理,需要特殊的序列化許可權。預設情況下,該許可權不會授予從 Intranet 或 Internet 上下載的代碼。如果要在不完全信任環境中使用 .NET Remoting 用戶端,則需要更改從那些地區中載入的代碼的預設安全性策略。當您從運行於沙箱(如下載的 Windows 表單應用程式)中的用戶端串連到系統時,ASP.NET Web 服務是較簡單的選擇,因為不需要更改安全性策略。
  
  狀態管理
  預設情況下,ASP.NET Web 服務模型採用無狀態的服務體繫結構;它並不是本能地與來自同一個使用者的多個調用相關。另外,用戶端每次調用 ASP.NET Web 服務時,都建立一個新的對象以服務於該請求。方法調用完成後,該對象即被破壞。要保持請求間的狀態,可以使用 ASP.NET 頁面所使用的技術(即會話和應用程式屬性包),也可以執行自訂的解決方案。
  
  .NET Remoting 支援許多狀態管理選項,並且可能與來自同一個使用者的多個調用相關或不相關,這取決於您選擇的對象生命週期架構。SingleCall 對象是無狀態的(如用於調用 ASP.NET Web 服務的對象),Singleton 對象共用所有用戶端的狀態,用戶端啟用的對象在每個用戶端的基礎上保持狀態(帶有其產生的所有相關的可升級性和可靠性問題)。
  
  效能
  從原始效能方面來講,使用 TCP 通道和二進位格式化程式時,.NET Remoting 管線能夠提供最快的通訊。在我們進行的比較 ASP.NET Web 服務和 .NET Remoting 的相對效能的幾乎所有的測試中,ASP.NET Web 服務在效能上都超出了使用 HTTP 或 TCP 通道的 SOAP 格式化程式的 .NET Remoting 端點。更有意思的是,使用二進位格式化程式和 HTTP 通道的 ASP.NET 和 .NET Remoting 端點在效能上非常相近。有關詳細資料,請參閱效能比較:.NET Remoting 與 ASP.NET Web 服務。
  
  企業服務
  ASP.NET Web 服務或通過 .NET Remoting 提供的對象可以使用本地事務根據單個資料庫協調工作。如果需要根據多個資源協調工作,它可以使用 .NET 企業服務(也稱為 COM+)公布的事務(由 COM+ 管線管理的 DTC 分散式交易)。但要注意的是,ASP.NET Web 服務和 .NET Remoting 管線都不能傳播公布的事務,因此兩種端點都不可能通過跨進程的調用繼承公布的事務。
  
  這不一定是件壞事。一般來講,公布的事務比本地事務代價要高,而要跨進程傳播公布的事務,則代價會更高。如果您確實需要這種功能,簡單的解決方案是在 .NET 企業服務伺服器應用程式中展開一個從 System.EnterpriseServices.ServicedComponent 中衍生的類(有關詳細資料,請參閱 COM+ Integration: How .NET Enterprise Services Can Help You Build Distributed Applications [英文])。對該類對象的跨進程調用將使用 DCOM 進行處理,以確保正確傳播事務環境。較難的解決方案是使用底層的 API,手動傳播分布的事務。
  
  值得注意的是,傳統的分散式交易模型一般不適用於鬆散耦合的 Web 服務。基於補償事務的模型(即,撤消其他事務所提交工作的事務)更有意義,因為其隔離約束條件並不是很嚴格。在包括 Microsoft 的 Web 服務供應商中有一種普遍的說法,即 Web 服務空間需要的事務模型越靈活,該空間中進行的工作越多。等到定義出 Web 服務事務的標準方法時,您就可以根據情況使用本地或公布的事務實現自己的補償架構了。
  
  選擇體繫結構
  如果您正在設計一個基於 .NET 的分布式應用程式,則需要考慮本文中討論的所有問題,並對系統體繫結構的應有結果得出一些結論。一般來講,這比您想像的要容易些。但總有一些特殊的情況需要其他的方法,以下是您可以進行的某些一般假設,可為您簡化情況。
  
  首先,在預設情況下使用 ASP.NET Web 服務。它們的執行和使用都很簡單,可以為用戶端平台提供儘可能寬的使用範圍,而且可以從預設安全性策略下沙箱中啟動並執行代碼中調用 ASP.NET Web 服務用戶端代理代碼。
  
  如果要使用較傳統的帶有 CLR 類型逼真度的分布式物件模型,不需要與其他平台進行互操作,而且由您控制用戶端和伺服器的配置,請考慮使用 .NET Remoting。如果您選擇 .NET Remoting,最好使 HTTP 通道與 IIS 和 ASP.NET 整合,否則,必須建立自己的進程生命週期管理和安全性基礎結構。假定 .NET Remoting 需要 .NET 用戶端,使用二進位格式化程式而不是 SOAP 格式化程式是很有意義的;互通性將不成問題,而且效能將顯著提高。
  
  最後,如果需要公布的事務,請使用企業服務 (COM+)。如果您執行 ServicedComponents,則出於效能方面的考慮,預設情況下它們將部署在庫應用程式中。如果它們需要在遠端電腦上運行,則將它們部署在伺服器應用程式中。(如果您需要執行不同的進程安全性令牌 [而不是 aspnet_wp.exe 使用的令牌] 的代碼,即使在相同的電腦上,可能也要考慮使用 COM+ 伺服器應用程式。)
  
  以下是三個基於這些理念的公用體繫結構。
  
  
  
  圖 1:簡單的 3 層體繫結構
  
  圖 1 顯示了一個簡單的 3 層體繫結構,它帶有 Web 服務器領域,支援一系列不同的用戶端。所有伺服器端的代碼都在 ASP.NET 輔助進程 aspnet_wp.exe 中執行。這三種不同類型的用戶端可以使用 HTTP 訪問伺服器領域。基於瀏覽器的用戶端調用 ASP.NET Web 頁面;多用戶端(如 Windows 表單應用程式、Microsoft Visual Basic 6 應用程式)和其他 Web 服務使用 ASP.NET Web 服務;根據需要,.NET 多用戶端(如 Windows 表單應用程式)和 Web 服務使用 ASP.NET Web 服務,或使用 HTTP 通道和二進位格式化程式的 .NET Remoting(假定它不在沙箱中)。
  
  圖 2:使用 ASP.NET 的 n 層體繫結構
  
  一些非常大的應用程式使用一套輔助電腦從 Web 服務器的外層分擔工作。這種體繫結構 2 所示。請注意,在這種情況下,第二層也通過 ASP.NET 提供功能。
  
  圖 3:使用企業服務 (COM+) 的 n 層體繫結構
  
  圖 3 顯示此體繫結構的另一種版本,其第二層使用在 COM+ 中部署的 ServicedComponents 提供功能。
  
  顯然,這些並不是 .NET Framework 所支援的所有可能的體繫結構。但是,它為您設計自己的系統提供了適當的基礎。
  
  小結
  雖然 .NET Remoting 基礎結構和 ASP.NET Web 服務都可以進行跨進程通訊,但每種設計適用於不同的使用者。ASP.NET Web 服務的編程模型很簡單,使用範圍很廣。.NET Remoting 的編程模型較複雜,使用範圍較窄。請務必瞭解這兩種技術的工作原理,並選擇適合您應用程式的技術。在任意一種情況下,都要使用 IIS 和 ASP.NET 管理進程生命週期,並提供一般的安全性。
相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.