WCF，Net remoting，Web service概念

今天看到WCF，說是整合了Net remoting，Web service。。。下面列一下概念。

一 WCF
概括地說，WCF具有如下的優(yōu)勢：
1、統(tǒng)一性
前面已經(jīng)敘述，WCF是對于ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技術(shù)的整合。由于WCF完全是由托管代碼編寫，因此開發(fā)WCF的應用程序與開發(fā)其它的.Net應用程序沒有太大的區(qū)別，我們?nèi)匀豢梢韵駝?chuàng)建面向?qū)ο蟮膽贸绦蚰菢?#xff0c;利用WCF來創(chuàng)建面向服務的應用程序。
2、互操作性
由于WCF最基本的通信機制是SOAP，這就保證了系統(tǒng)之間的互操作性，即使是運行不同的上下文中。這種通信可以是基于.Net到.Net間的通信。

可以跨進程、跨機器甚至于跨平臺的通信，只要支持標準的Web Service，例如J2EE應用服務器（如WebSphere，WebLogic）。應用程序可以運行在Windows操作系統(tǒng)下，也可以運行在其他的操作系統(tǒng)，如Sun Solaris，HP Unix，Linux等等。

3、安全與可信賴
WS-Security，WS-Trust和WS-SecureConversation均被添加到SOAP消息中，以用于用戶認證，數(shù)據(jù)完整性驗證，數(shù)據(jù)隱私等多種安全因素。
在SOAP的header中增加了WS-ReliableMessaging允許可信賴的端對端通信。而建立在WS-Coordination和WS-AtomicTransaction之上的基于SOAP格式交換的信息，則支持兩階段的事務提交（two-phase commit transactions）。
上述的多種WS-Policy在WCF中都給與了支持。對于Messaging而言，SOAP是Web Service的基本協(xié)議，它包含了消息頭（header）和消息體(body)。在消息頭中，定義了WS-Addressing用于定位SOAP消息的地址信息，同時還包含了MTOM（消息傳輸優(yōu)化機制，Message Transmission Optimization Mechanism）。

4、兼容性
WCF充分的考慮到了與舊有系統(tǒng)的兼容性。安裝WCF并不會影響原有的技術(shù)如ASMX和.Net Remoting。即使對于WCF和ASMX而言，雖然兩者都使用了SOAP，但基于WCF開發(fā)的應用程序，仍然可以直接與ASMX進行交互。

?

二 WebService的運行機理

首先客戶端從服務器的到WebService的WSDL，同時在客戶端聲稱一個代理類(Proxy Class)， 這個代理類負責與WebService服務器進行Request 和Response， 當一個數(shù)據(jù)（XML格式的）被封裝成SOAP格式的數(shù)據(jù)流發(fā)送到服務器端的時候，就會生成一個進程對象并且把接收到這個Request的SOAP包進行解析，然后對事物進行處理，處理結(jié)束以后再對這個計算結(jié)果進行SOAP包裝，然后把這個包作為一個Response發(fā)送給客戶端的代理類(Proxy Class)，同樣地，這個代理類也對這個SOAP包進行解析處理，繼而進行后續(xù)操作。

三 .net Remoting

是在DCOM等基礎(chǔ)上發(fā)展起來的一種技術(shù)，它的主要目的是實現(xiàn)跨平臺、跨語言、穿透企業(yè)防火墻，這也是他的基本特點，與WebService有所不同的是，它支持HTTP以及TCP信道，而且它不僅能傳輸XML格式的SOAP包，也可以傳輸傳統(tǒng)意義上的二進制流，這使得它變得效率更高也更加靈活。而且它不依賴于IIS，用戶可以自己開發(fā)(Development)并部署(Dispose)自己喜歡的宿主服務器，所以從這些方面上來講WebService其實上是.netemoting的一種特例。

區(qū)別：

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

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

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

4、在VS.net開發(fā)環(huán)境中，專門對Web Service的調(diào)用進行了封裝，用起來比Remoting方便。

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

來自MSDN：http://www.microsoft.com/china/MSDN/library/enterprisedevelopment/builddistapp/ASP.NETWebServicesor.NETRemoting-HowtoChoose.mspx?mfr=true

分布式應用程序設(shè)計：ASP.NET Web 服務和 .NET Remoting

ASP.NET Web 服務偏向于 XML Schema 類型系統(tǒng)，提供具有廣泛使用范圍的跨平臺支持的簡單編程模型。.NET Remoting 偏向于運行時類型系統(tǒng)，提供較為復雜而且使用范圍小得多的編程模型。這種本質(zhì)上的差別是決定使用哪種技術(shù)的主要因素。但是，還要考慮很多其他設(shè)計因素，包括傳輸協(xié)議、主機進程、安全性、性能、狀態(tài)管理以及對事務的支持等。

傳輸協(xié)議和主機進程

盡管 SOAP 規(guī)范并不要求用 HTTP 作為傳輸協(xié)議，但是客戶端只能通過 HTTP 訪問使用 ASP.NET Web 服務實現(xiàn)的 Web 服務，因為它是 ASP.NET 支持的唯一一種傳輸協(xié)議。服務是通過 IIS 調(diào)用的，并在 ASP.NET 的輔助進程 aspnet_wp.exe 中執(zhí)行。

.NET Remoting 使您能夠在任何類型的應用程序（包括 Windows 窗體、托管的 Windows 服務、控制臺應用程序或 ASP.NET 輔助進程）中靈活地托管遠程對象。正如前面所述，.NET Remoting 提供兩個傳輸信道——TCP 和 HTTP。這兩個信道都能使用套接字提供任意發(fā)送和接收進程之間的通信。

它還能將 HTTP 信道與 IIS 和 ASP.NET 輔助進程集成。這一點很重要，原因有以下幾點。首先，它是當客戶端請求到達時自動啟動 .NET Remoting 端點的唯一方法。.NET Remoting 管線不包括啟動遠程服務器所需的 DCOM 類型的服務控制管理器 (SCM)。如果從任意進程中提供遠程對象，則需要確保那些進程正在運行。還必須確保它們是線程安全的，例如，線程 A 不能在線程 B 開始關(guān)閉進程之后激活對象。如果從 ASP.NET 提供遠程對象，則可以利用 Aspnet_wp.exe 輔助進程，這樣既可自動啟動又具有線程安全的優(yōu)勢。第二，與 IIS 集成是確保跨進程 .NET Remoting 調(diào)用的唯一途徑，如下一節(jié)所述。

ASP.NET Web 服務和 .NET Remoting 基礎(chǔ)結(jié)構(gòu)都是可擴展的。您可以過濾入站和出站消息，從多方面控制類型封送和元數(shù)據(jù)的生成。使用 .NET Remoting，還能實現(xiàn)您自己的格式化程序和信道。

安全性

由于 ASP.NET Web 服務依賴于 HTTP，因此它們與標準的 Internet 安全性基礎(chǔ)結(jié)構(gòu)相集成。ASP.NET 利用 IIS 的安全性功能，為標準 HTTP 驗證方案（包括基本、簡要、數(shù)字證書，甚至 Microsoft? .NET Passport）提供了強有力的支持。（還可以使用 Windows 集成驗證，但只能用于信任域中的客戶端。）使用可用的 HTTP 驗證方案的一個優(yōu)勢在于，無需在 Web 服務中更改代碼，IIS 是在 ASP.NET Web 服務被調(diào)用之前執(zhí)行驗證的。ASP.NET 還支持基于 .NET Passport 的驗證和其他自定義的驗證方案。ASP.NET 支持基于目標 URL 的訪問控制，并通過與 .NET 代碼訪問安全性 (CAS) 基礎(chǔ)結(jié)構(gòu)的集成支持訪問控制。SSL 可用于確保通信的安全。

盡管這些標準傳輸技術(shù)對于確保 Web 服務相當有效，但它們只能做到這種程度。在涉及到不同信任域中多個 Web 服務的復雜情況下，還得建立自定義的特殊解決方案。Microsoft 和其他公司正致力于創(chuàng)建一套安全性規(guī)范，該規(guī)范將基于 SOAP 消息的可擴展性提供消息級別的安全性功能。這些規(guī)范之一是 XML Web 服務安全性語言（WS-Security），它為消息級別的憑據(jù)傳輸、消息完整性和消息保密定義了框架。

正如上一節(jié)所述，一般情況下，.NET Remoting 管線不能確保跨進程調(diào)用的安全。使用 ASP.NET 托管于 IIS 中的 .NET Remoting 端點可以利用 ASP.NET Web 服務可用的所有安全性功能，包括對使用 SSL 確保有線通信的安全性的支持。如果您正在使用托管在進程中的 TCP 信道或 HTTP 信道（而不是 aspnet_wp.exe），則必須自己執(zhí)行身份驗證、授權(quán)和保密機制。

另一個要關(guān)注的安全性問題是，在不必更改默認安全性策略的情況下，從不完全信任的環(huán)境中執(zhí)行代碼的能力。ASP.NET Web 服務客戶端代理可以在這些環(huán)境中工作，但 .NET Remoting 代理則不能。要從不完全信任的環(huán)境中使用 .NET Remoting 代理，需要特殊的序列化權(quán)限。默認情況下，該權(quán)限不會授予從 Intranet 或 Internet 上下載的代碼。如果要在不完全信任的環(huán)境中使用 .NET Remoting 客戶端，則需要更改從那些區(qū)域中加載的代碼的默認安全性策略。當您從運行于沙箱（如下載的 Windows 窗體應用程序）中的客戶端連接到系統(tǒng)時，ASP.NET Web 服務是較簡單的選擇，因為不需要更改安全性策略。

狀態(tài)管理

默認情況下，ASP.NET Web 服務模型采用無狀態(tài)的服務結(jié)構(gòu)；它并不是本能地與來自同一個用戶的多個調(diào)用相關(guān)。另外，客戶端每次調(diào)用 ASP.NET Web 服務時，都創(chuàng)建一個新的對象以服務于該請求。方法調(diào)用完成后，該對象即被破壞。要維護請求之間的狀態(tài)，可以使用 ASP.NET 頁面使用的相同技術(shù)（例如，Session 和 Application 屬性包），也可以自己實現(xiàn)自定義的解決方案。

.NET Remoting 支持許多狀態(tài)管理選項，并且可能與來自同一個用戶的多個調(diào)用相關(guān)或不相關(guān)，這取決于您選擇的對象生命周期架構(gòu)。SingleCall 對象是無狀態(tài)的（如用于調(diào)用 ASP.NET Web 服務的對象），Singleton 對象共享所有客戶端的狀態(tài)，客戶端激活的對象在每個客戶端的基礎(chǔ)上保持狀態(tài)（帶有其產(chǎn)生的所有相關(guān)的可升級性和可靠性問題）。

性能

從原始性能方面來講，使用 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。）

企業(yè)服務

ASP.NET Web 服務或通過 .NET Remoting 提供的對象可以使用本地事務根據(jù)單個數(shù)據(jù)庫協(xié)調(diào)工作。如果需要根據(jù)多個資源協(xié)調(diào)工作，可以使用 .NET 企業(yè)服務（又稱 COM+）公布的事務（由 COM+ 管線管理的 DTC 分布式事務）。但要注意的是，ASP.NET Web 服務和 .NET Remoting 管線都不能傳播公布的事務，因此兩種端點都不可能通過跨進程的調(diào)用繼承公布的事務。

這不一定是件壞事。一般來講，公布的事務比本地事務代價要高，而要跨進程傳播公布的事務，則代價會更高。如果確實需要這一功能，簡單的解決方案是在 .NET 企業(yè)服務的服務器應用程序中部署一個從 System.EnterpriseServices.ServicedComponent 派生的類（更多信息，請參見 COM+ Integration:How .NET Enterprise Services Can Help You Build Distributed Applications）。對該類對象的跨進程調(diào)用將使用 DCOM 進行處理，以確保正確傳播事務環(huán)境。較難的解決方案是使用底層的 API，手動傳播分布的事務。

值得注意的是，傳統(tǒng)的分布式事務模型一般不適用于松散耦合的 Web 服務。基于補償事務的模型（即，撤消其他事務所提交工作的事務）更有意義，因為其隔離約束條件并不是很嚴格。在包括 Microsoft 的 Web 服務供應商中有一種普遍的說法，即 Web 服務空間需要的事務模型越靈活，該空間中進行的工作越多。等到定義出 Web 服務事務的標準方法時，您就可以根據(jù)情況使用本地或公布的事務實現(xiàn)自己的補償架構(gòu)了。

?

小結(jié)
雖然 .NET Remoting 基礎(chǔ)結(jié)構(gòu)和 ASP.NET Web 服務都可以進行跨進程通信，但每種設(shè)計適用于不同的用戶。ASP.NET Web 服務提供了簡單的編程模型，并具有廣泛的使用范圍。.NET Remoting 提供了較為復雜的編程模型，而且使用范圍窄得多。請務必了解這兩種技術(shù)的工作原理，并選擇適合您應用程序的技術(shù)。在任意一種情況下，都要使用 IIS 和 ASP.NET 管理進程生命周期，并提供一般的安全性。

轉(zhuǎn)載于:https://www.cnblogs.com/dongdonggege/archive/2012/12/24/2830937.html

總結(jié)

以上是生活随笔為你收集整理的WCF，Net remoting，Web service概念(转)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。