選擇 .NET 中的通訊選項

  • 發行項

隨著 .NET Framework 3.0 與 Windows Communication Foundation (WCF) 的問世，統一的程式設計模型紛紛出現各種不同的技術。WCF 將做為新版的 Enterprise Services、ASMX Web 服務、WSE、MSMQ，以及 .Net 遠端處理技術使用。以下主題適用於 .NET Framework 2.0。如需 WCF 和 .NET Framework 3.0，請參閱：Windows Communication Foundation。

.NET Framework 提供數種在不同應用程式定義域中與物件進行通訊的方法，每種方法在設計之初便已考量到特定的專業與彈性等級。例如，網際網路的快速興起讓 XML Web Service 成為通訊的新寵兒，因為 XML Web Service 是建立在 HTTP 通訊協定與使用 XML 之 SOAP 格式的通用基礎結構上。這些都是公開的標準，可以立即與現有的 Web 基礎結構搭配運用，而不用擔心碰到其他的 Proxy 或防火牆問題。

由於許多應用程式都需要用到 Web 服務所建立的功能 (ASP.NET 不支援)，因此會有一些應用程式將無法使用 ASP.NET Web 服務。請利用下列小節內容，協助您決定您的應用程式需要哪種類型的分散式應用程式支援。

ASP.NET、Enterprise Services，或 .NET 遠端處理

ASP.NET、Enterprise Services，與 .NET 遠端處理都是處理序間的通訊 (IPC) 實作。ASP.NET 提供由網際網路資訊服務 (IIS) 所裝載的基礎結構，這種結構可妥善處理基本型別、支援某些進階 Web 服務通訊協定 (與網頁服務延伸 (WSE) 一起使用時)，而且是 Web 應用程式開發人員所熟悉的一種結構。Enterprise Services 是一種 Managed 的 COM+ 實作，可提供 COM+ 架構的所有彈性與豐富功能。.NET 遠端處理是一種泛型、可延伸的 IPC 系統，可以自我裝載或是裝載到 IIS 中以開發並部署分散式物件導向應用程式。.NET 遠端處理的架構可允許使用自訂通訊協定與網路格式。

您應該根據三大主要準則來決定要採用的程式設計模型：業務需求、整合需求，以及所熟悉的程式設計模型。此外，下列準則 (依優先順序列出) 可協助您選擇最適當的分散式應用程式技術類型：

  1. 安全性需求

    在三種程式設計模型中，Enterprise Services 擁有最豐富的安全性功能，而且能夠用於大部分的情況。ASP.NET 透過 IIS 來提供驗證功能並透過 SSL 來提供加密功能，在保護以網際網路為範圍的應用程式上也很有用處。.NET 遠端處理的安全性隨著最新推出的 .NET Framework 而提升不少。在舊版的 .NET 遠端處理中，如果您需要加密呼叫或是驗證用戶端，就必須使用由 IIS 裝載，以 HTTP 為基礎的應用程式來執行 (不管是否為 ASP.NET 應用程式或遠端處理應用程式皆然)。在最新版本中，TcpChannel 與 HttpChannel 支援 SSPI 加密與 Windows 整合驗證。IpcChannel 同時支援具名管線上的 Windows 驗證與存取控制清單 (ACL) 的直接設定。由於我們不建議您使用網際網路上的遠端物件，目前只有少數情況需要用到 HttpChannel。如果您必須透過網際網路進行通訊，建議您使用 ASP.NET 來建立 XML Web Service。

    8119f66k.note(zh-tw,VS.100).gif注意：
    為了安全起見，我們強烈建議您透過安全通道來公開遠端處理端點。請絕對不要將不安全的遠端處理端點顯示到網際網路上。

  2. 互通

    如果您必須在不同作業系統之間互通，則應使用 ASP.NET 建立的 XML Web Service。ASP.NET 檔案可讓您在定義 SOAP 通訊的圖案和樣式時，擁有比 .NET 遠端處理更大的彈性。這些彈性能讓您更輕鬆地在不同平台與用戶端之間交互操作。.NET 遠端處理的設計用意，並不是要在 .NET 以外平台上進行交互操作的。

    .NET Framework 遠端處理不是針對與 Web 服務互通所設計的。如需 在 Web 服務與遠端處理之間做選擇的詳細資訊，請參閱效能最佳做法概觀中的＜如何選擇 Web 服務、遠端處理和 Enterprise Services＞，以及選擇 Web 服務、Enterprise Services 和 .NET Remoting 的規範指南 (本頁面可能為英文)。

  3. 速度

    如果速度的確是最主要的因素，則 Enterprise Services 將可為分散式應用程式提供最佳效能。當應用程式進行到真實處理階段時，.NET 遠端處理與 ASP.NET 檔案之間的效能差異將會很小。如果您使用 .NET 遠端處理，則搭配 BinaryFormatter 的 TcpChannel 將以最佳效能在所有電腦中勝出。在相同電腦上，您應該使用搭配 BinaryFormatter 的 IpcChannel。

  4. 延展性

    將應用程式裝載到 IIS 中可提供您所需的延展性。自我裝載的 .NET 遠端處理會要求您建置自己的範圍調整基礎結構。如果您考慮採用 IIS 搭配 .NET 遠端處理來獲得延展性，您應該考慮使用 Web 服務並改用 ASP.NET。

  5. Common Language Runtime 功能的用途

    Enterprise Services 與 .NET 遠端處理兩者都很懂得善加利用 .NET 用戶端，因此您可以在應用程式中藉由使用 ASP.NET 來使用 XML Web Service 所無法使用的下列各項 .NET 功能：

    • 介面。

    • CallContext.

    • 屬性。

    • 索引子。

    • C++。

    • 用戶端與伺服器應用程式之間的型別精確度。

    如果這些功能為關鍵功能，則在可能情況下先選擇 Enterprise Services，再選擇 .NET 遠端處理。

  6. 物件導向應用程式設計

    Enterprise Services 與 .NET 遠端處理物件兩者都是物件，而且可以當成物件來加以處理。因此，您可以使用下列 ASP.NET 無法使用的應用程式物件導向功能：

    • 遠端處理物件的物件參考。

    • 數個物件啟用選項。

    • 物件導向狀態管理。

    • 分散式物件存留期管理。

    如果這些功能為關鍵功能，則在可能情況下先選擇 Enterprise Services，再選擇 .NET 遠端處理。

  7. 自動傳輸或 Wire 格式

    如果您需要支援自訂傳輸 (例如，使用者資料包通訊協定 (UDP)) 或自訂 Wire 格式 (例如，CSV)，則 .NET 遠端處理是唯一一項符合這些需求的可外掛式架構。

  8. 跨應用程式定義域通訊

    如果您需要支援在相同處理序中，不同應用程式定義域的物件之間通訊，則您必須使用 .NET 遠端處理。

下列各節將針對使用 ASP.NET、System.Net 命名空間、Enterprise Services，以及 .NET 遠端處理所建立的各種 XML Web Service 之間的一些差異提供摘要說明。

XML Web Service

如果您使用 Web 應用程式模型與 ASP.NET HTTP 執行階段 (包含 Microsoft Visual Studio .NET 中的強支援) 來建置動態伺服器網頁 (ASP) 應用程式，則由 ASP.NET 建立的 XML Web Service 就會運作得非常順暢。有了 XML Web Service 基礎結構，您可以為其他應用程式輕鬆建立要使用的元件，或是透過 Web 架構應用程式最適用的通訊協定、格式，與資料類型，來運用其他應用程式所建立的元件。此結構不支援電腦之間的完整型別精確度，而且只能傳遞某些類型的引數。如需詳細資訊，請參閱，使用 ASP.NET 和 XML Web Service 用戶端建立的 XML Web Service。

System.Net 命名空間

您可以使用 System.Net 命名空間中的類別，建立通訊端層級的完整通訊結構。您也可以使用 System.Net 類別來實作通訊協定與序列化格式，以便外掛至遠端處理架構中。如需詳細資訊，請參閱 Network Programming.

Enterprise Services

Enterprise Services 以 .NET 遠端處理基礎結構為基礎，可提供 COM+ 分散式物件模型的所有豐富功能與彈性，包含對非常分散的交易支援。

.NET 遠端處理

.NET 遠端處理可為包括 XML Web Service 在內的許多通訊案例提供工具。使用 .NET 遠端處理，您可以：

  • 發行或存取任何型別之應用程式定義域中的服務，不管該定義域為主控台應用程式、Windows Form、IIS、XML Web Service，或是 Windows 服務皆然。

  • 在二進位格式通訊中保留完整的 Managed 程式碼型別系統精確度，包括對泛型型別的支援。

    8119f66k.note(zh-tw,VS.100).gif注意：
    XML Web Service 所使用的 SOAP 格式無法保留所有型別詳細資料。

  • 以傳址方式傳遞物件，並傳回到特定應用程式定義域中的特定物件。

  • 直接控制啟動特性與物件存留期。

  • 實作並使用協力廠商的通道或通訊協定來延伸通訊，以符合您的特殊需求。

  • 直接參與通訊處理序，以建立所需的功能。

另請參閱

其他資源

.NET 遠端處理
.NET Framework 遠端處理概觀
遠端處理範例
進階遠端處理
Windows Communication Foundation