1. 程式人生 > >Web Service和WCF的到底有什麼區別

Web Service和WCF的到底有什麼區別

Web Service是早期的技術實現了,也是soap的東西,採用的主要是http協議,假如是在C#上開發的話,需要寄宿在IIS上來實現。 WCF的話是相對較新的技術,裡面的basichttpbinding可以跟以前的ws進行通訊,並且集成了大部分的通訊協議(幾種http協議的實現以及net.Tcp實現、msmq、命名管道等實現),另外寄宿的宿主可以是命令列控制檯、IIS、桌面程式等。 差別的話,感覺有這以下幾點[針對C#來說的]。 ws的話,程式設計模型沒有wcf的那麼好,具體的實現差別建議百度下,個人覺得wcf比較好。wcf可以用契約的介面方式來進行實現,而ws的話主要是通過繼承WebService的類來實現的,方法上新增WebMethod特性,WCF的話是通過服務契約來宣告(可以是介面也可以是類物件) ws的話通用性比較強,跟java等ws也可以進行互相通訊,然後假如是wcf釋出的服務,除了basicHttpBinding這種繫結之外,其餘的幾種繫結基本上不能作為互相通訊。例如命名管道跟net.Tcp都是,值得說的是這裡的net.Tcp跟原生的tcp是不一樣的,內部實現上參考tcp的可靠連線機制進行了應用層的一套實現。 另外一點就是服務引用跟web引用上的,這個嚴格來說不能屬於兩者的區別,只是.net版本的區別,主要是針對客戶端對服務端釋出好的服務進行的引用,服務引用生成的時候,會在配置檔案上存在一份配置項,可以進行ABC終結點的配置,假如是web引用的話,會在setting中新增上一個硬編碼的地址。建議用服務引用。 還有一個就是客戶端呼叫服務端開發的時候,webservice的話,基本上只能通過服務端釋出的地址來進行引用[應用的方式可以參考點3],或者通過服務端提供的wsdl檔案來進行引用(該種方式一般比較少,因為需要提供檔案,而不是通過公開的方式來進行介面的提供,無法應對服務變更後釋出問題,但是確實有這個情況的存在)。而wcf的話,還存在可以通過提供契約檔案(就是聲明瞭ServiceContract的那個介面檔案)來進行服務的呼叫。 在介面層面的話,凡是IList<class T>以及IDictionary<class T>這一類的泛型實現都會在進行服務引用的時候,都會轉換為陣列的,例如void F(IList<int>)會在引用後成為void F(int[])這種方式,而才用點4提供的契約檔案的話就能保持方法的原始宣告。 個人建議的話,假如是新開發的系統基本上都才用wcf比較好,一個是介面的思想,一個是假如需要轉換為其他協議的話可以比較方便,只需要通過配置檔案修改下就可以[當前前提是沒有用到特定協議的特定屬性,例如服務回撥,有些協議是不支援雙向通訊的]。而且也需要考慮釋出的服務是否需要公開給別的語言進行通訊。 另外說的效能在下降的話,大概說明下: 基本上針對應用的開發都是基於socket的開發,傳統的socket開發的話,是需要自己去實現整個通訊框架的,包括多執行緒處理,IOCP等的實現[基本上.net的非同步通訊模型在內部實現都會繫結好,IOCP是一個非同步模型,自行百度],二進位制流的編碼處理[網路傳輸都是通過二進位制的,例如utf8到二進位制的轉換],tcp無邊界訊息的處理[udp的話沒有這個,但是包體的大小也是有限制],通訊協議的約定處理[例如ws跟wcf是採用soap這種,各種ws的約定,例如多少個位元組表示資料流的長度、資料的檢驗,還是資料加密位,也包括資料的位移處理],資料上拋模型跟資料回覆模型[接受到資料後是需要上拋給業務層去進行處理的,然後也需要回復給客戶端,不過也不一定是這樣,看需求],還有各種針對性的處理,例如客戶端socket的儲存[有可能對長期不適用的套接字要進行自動斷開的業務]。類似wcf這種東西的話,還有序列化跟反序列化的情況[序列化跟反序列化是效能開銷比較大的,例如序列化是通過反射來實現的,反射又是跟程式集的元資料有關的,屬於執行時行為],假如是自己實現tcp通訊模型,就不一定會有序列化跟反序列化的通訊模型了,而且wcf為了讓通訊跟本地呼叫那樣以及標準的方面,位元組流都是比較大的,這裡也會增加通訊的頻寬【好比自定義的協議4個位元組的資料包長度+1個位元組的加密壓縮位+N個數據包位+X個位元組的檢驗位,這種的話實際用到的位元組就比較少了,因為在資料包裡面,可以會用2個位元組表示協議頭,例如ox0A表示登入介面,再用4個位元組表示登入名,4個位元組表示密碼等】。以上是簡單的對socket跟wcf\ws等協議的差別說明。socket跟wcf\ws對比的話,socket效能是最高的,高併發高響應的時候,這裡是有差距的,技術上的話,socket需要更加多的技術支援[開發週期長,對人員要求高],而wcf在應用層面上基本無難度,就是一些配置,出現問題也大部分可以通過百度來處理。另外一個就是託管語言本身的問題,GC這塊的,GC回收的時候,是需要掛起堆疊上的執行緒的,而且GC的執行緒優先順序比自己所能建立的所有執行緒的優先順序都要高,等GC執行完畢的時候才能去執行自己的執行緒,wcf在堆物件上申請的空間也會更加多,自然導致GC會受到的概率也會更加大,這裡也會可能導致wcf效能不如socket。基本上來說,C#的類都是引用物件,都是堆申請的,在引用計數超出的時候,都會被下一個GC[]操作去回收,真是個奇葩的事情。 總之,在ws跟wcf之間選擇的話,個人覺得優先選擇wcf好點。 如果是對效能要求較高[高併發等],或者是長連線再或者是需要用到UDP這種的話,就基本上無法用wcf跟ws這種了,wcf是沒有udp協議的,http協議也只是在tcp協議下的上層協議,底層傳送的資料包跟實作是不通的。另外對於長連線,雖然wcf提供了類似回撥這種情況機制,只是個人不推薦使用在這種長連線的場合下。