WCF、Net remoting、Web service概念及區別

　　Windows通訊基礎（Windows Communication Foundation，WCF）是基於Windows平臺下開發和部署服務的軟體開發包（Software Development Kit，SDK）。

　　WCF就是微軟對於分散式處理的 程式設計技術的集大成者，它將DCOM、Remoting、Web Service、WSE、MSMQ整合在一起，從而降低了分散式系統開發者的學習曲線，並統一了開發標準。

　　WCF是建立在.Net Framework 2.0基礎之上的，包含在.NET 3.0/3.5當中。2005中並沒有包含WCF，但是當安裝好了WinFX Runtime Components後，我們就可以在Visual Studio 2005環境下開發和建立WCF的程式了。

　　尊重資料來源。以下來自網頁http://www.cppblog.com/mzty/archive/2007/10/24/35068.html

　　一 WCF

　　概括地說，WCF具有如下的優勢：

　　1、統一性

　　前面已經敘述，WCF是對於ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技術的整合。由於WCF完全是由託管程式碼編寫，因此開發WCF的應用程式與開發其它的.Net應用程式沒有太大的區別，我們仍然可以像建立物件導向的應用程式那樣，利用WCF來建立面向服務的應用程式。

　　2、互操作性

　　由於WCF最基本的通訊機制是SOAP，這就保證了系統之間的互操作性，即使是執行不同的上下文中。這種通訊可以是基於.Net到.Net間的通訊。

　　可以跨程式、跨機器甚至於跨平臺的通訊，只要支援標準的Web Service，例如J2EE應用伺服器（如WebSphere，WebLogic）。應用程式可以執行在Windows作業系統下，也可以執行在其他的作業系統，如Sun Solaris，HP Unix，Linux等等。

　　3、安全與可信賴

　　WS-Security，WS-Trust和WS-SecureConversation均被新增到SOAP訊息中，以用於使用者認證，資料完整性驗證，資料隱私等多種安全因素。

　　在SOAP的header中增加了WS-ReliableMessaging允許可信賴的端對端通訊。而建立在WS-Coordination和WS-AtomicTransaction之上的基於SOAP格式交換的資訊，則支援兩階段的事務提交（two-phase commit transactions）。

　　上述的多種WS-Policy在WCF中都給與了支援。對於Messaging而言，SOAP是Web Service的基本協議，它包含了訊息頭（header）和訊息體(body)。在訊息頭中，定義了WS-Addressing用於定位SOAP訊息的地址資訊，同時還包含了MTOM（訊息傳輸優化機制，Message Transmission Optimization Mechanism）。

　　4、相容性

　　WCF充分的考慮到了與舊有系統的相容性。安裝WCF並不會影響原有的技術如ASMX和.Net Remoting。即使對於WCF和ASMX而言，雖然兩者都使用了SOAP，但基於WCF開發的應用程式，仍然可以直接與ASMX進行互動。 

　　二 WebService的執行機理

　　首先客戶端從伺服器的到WebService的WSDL，同時在客戶端聲稱一個代理類(Proxy Class)， 這個代理類負責與WebService伺服器進行Request 和Response， 當一個資料（XML格式的）被封裝成SOAP格式的資料流傳送到伺服器端的時候，就會生成一個程式物件並且把接收到這個Request的SOAP包進行解析，然後對事物進行處理，處理結束以後再對這個計算結果進行SOAP包裝，然後把這個包作為一個Response傳送給客戶端的代理類(Proxy Class)，同樣地，這個代理類也對這個SOAP包進行解析處理，繼而進行後續操作。

　　三 .net Remoting

　　是在DCOM等基礎上發展起來的一種技術，它的主要目的是實現跨平臺、跨語言、穿透企業防火牆，這也是他的基本特點，與WebService有所不同的是，它支援HTTP以及TCP通道，而且它不僅能傳輸XML格式的SOAP包，也可以傳輸傳統意義上的二進位制流，這使得它變得效率更高也更加靈活。而且它不依賴於IIS，使用者可以自己開發(Development)並部署(Dispose)自己喜歡的宿主伺服器，所以從這些方面上來講WebService其實上是.netemoting的一種特例。

　　區別：

　　1、Remoting可以靈活的定義其所基於的協議，比如http，tcp等，如果定義為HTTP，則與Web Service相同，但是webservice是無狀態的，使用remoting一般都喜歡定義為TCP，這樣比Web Service稍為高效一些，而且是有狀態的。

　　2、Remoting不是標準，而Web Service是標準。

　　3、Remoting一般需要通過一個WinForm或是Windows服務進行啟動，也可以使用iis部署，而Web Service則必須在IIS進行啟動。

　　4、在VS.net開發環境中，專門對Web Service的呼叫進行了封裝，用起來比Remoting方便。

　　5 net remoting只能應用於MS 的.net framework之下，需要客戶端必須安裝framework，但是WebService是平臺獨立的，跨語言（只要能支援XML的語言都可以） 以及穿透企業防火牆。

　　分散式應用程式設計：ASP.NET Web 服務和 .NET Remoting

　　ASP.NET Web 服務偏向於 XML Schema 型別系統，提供具有廣泛使用範圍的跨平臺支援的簡單程式設計模型。.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)。如果從任意程式中提供遠端物件，則需要確保那些程式正在執行。還必須確保它們是執行緒安全的，例如，執行緒 A 不能線上程 B 開始關閉程式之後啟用物件。如果從 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 頁面使用的相同技術（例如，Session 和 Application 屬性包），也可以自己實現自定義的解決方案。

　　.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 端點在效能上非常相近。（更多資訊，請參見 Performance Comparison:NET Remoting vs. ASP.NET Web Services。）

　　企業服務

　　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 Remoting 基礎結構和 ASP.NET Web 服務都可以進行跨程式通訊，但每種設計適用於不同的使用者。ASP.NET Web 服務提供了簡單的程式設計模型，並具有廣泛的使用範圍。.NET Remoting 提供了較為複雜的程式設計模型，而且使用範圍窄得多。請務必瞭解這兩種技術的工作原理，並選擇適合您應用程式的技術。在任意一種情況下，都要使用 IIS 和 ASP.NET 管理程式生命週期，並提供一般的安全性。

　　我採用Remoting技術也是專案的需要：

　　1、Remoteing主要用於C/S結構專案。

　　2、將Remoting採用TCP通訊，比Web Service不是稍微高效一些，而是高几倍，甚至幾十倍，不愧為是在DCOM等基礎上發展起來的技術。對於跨地區，乃至跨省（廣域網）的分散式應用，效率的高低意味著軟體系統的生死存亡。

　　我在部落格上說的這個三層結構，本意也只是在.net環境下，利用反射技術、物件關係對映等技術，寫一個底層點的程式集，方便編寫資料庫訪問程式。該程式集要能封裝常用的資料庫操作。這個程式集不管是在Remoting、Web Service還是WCF，應該都能用的。就象我們在大學課本里學資料結構，學的是一種思想。如果只是單純侷限一種技術，在日新月異的發展中，終將淘汰。我們都是凡人，不可能掌握所有技術。適合自己專案需要的，就是最好的！