WCF探勘1-WAS與net.tcp

前陣子對.NET Remoting、WCF、Web API做了評估，重新肯定WCF在Client/Server皆為.NET情境下的優越性，決定展開一系列對WCF較深入的研究，重新評估這個被我嫌棄多年的技術。

我深信「開發者擁有選擇或棄用某項技術的決定權，但必須基於理性分析評估優劣，而非單憑模糊印象或靠某種說不上來的感覺」。為此，雖然過去對WCF繁瑣易錯的設定方式從未有過好感，還是該咬牙征服它，才有資格大聲說「我決定不用WCF，是因為Blah Blah…」

但歷經一番研究，發現WCF在.NET 4.0之後有不少改良，設定上簡化不少，機車度不若以往，大家可以順著文章看看，或許對WCF也會有所改觀。

過去對WCF的HTTP/HTTPS用法接觸較多，這次重新探勘將聚焦於幾項WCF優於Web API的特色，包含：

WCF TCP傳輸
TCP與HTTP之傳輸效率比較
雙工服務模式（Web API雖然也有SignalR助陣，但WCF內建，勝！）

支援多種傳輸通道是WCF一大特點：WCF內建支援HTTP/HTTPS、TCP、Named Pipe、MSMQ等多種傳輸協定，且標榜不改程式光調設定就能自由切換。不同傳輸方式各有優劣，MSDN有篇文章羅列各種傳輸方式的比較，在此只簡單摘要，想深入了解可參考原文：

HTTP/HTTPS：可通過大部分防火牆及網路限制，穿透力最強，且享有較豐富的偵察、除錯工具支援，Request間不具狀態性，需自行保存。
TCP：Client與Server直接建立TCP連線，傳輸效率最好
Named Pipe（具名管道）：效率與TCP相彷，適用單一電腦不同程式間的WCF溝通，可阻絕來自其他電腦的存取。
MSMQ：架構最複雜，但能確保Request及Response使命必達，不管天崩地裂都會交到對方手上，適用對通訊過程出錯容忍度很低的場合。（可以想見，必須付出效能作為代價）

WCF有多種傳輸方式可供選擇是好事，但若要求開發者自己打點TCP/Named Pipe/MSMQ的連線細節，會讓人很想死。從IIS7起，IIS附加了WAS（Windows Process Activation Service），讓IIS 有能力支援HTTP/HTTPS以外的WCF傳輸協定。只需比照Web Application將WCF網站掛上IIS，再設定該網站支援的傳輸方式，就能透過TCP/Named Pipe/MSMQ等管道進行WCF溝通，非常神奇！

以下我們用一個範例來看WAS如何讓WCF支援TCP協定？

由於WAS依附於IIS，開發機最好安裝IIS，並開啟「.NET Framework 4.5進階服務/TCP啟用」功能以利測試：

不同Windows版本安裝功能的介面有所差異，上圖以Windows 8.1為例。下面再附上2012R2的安裝範例，可使用新增角色與功能精靈安裝：
開啟Visual Studio，新増一個WCF Service Application（.NET Framework版本請選4.5以上）

自.NET 4.0起，WCF大幅簡化config設定要求，若可沿用預設值，不必像過去寫一堆behavior、endpoint… 繁雜設定，設定檔清爽很多。
將WCF Service Application目錄掛成IIS網站應用程式，打開網站應用程式的「進階設定」功能，「已啟用的通訊協定」屬性預設為"http"，改為"http,net.tcp"，這樣子WCF服務就同時支援TCP與HTTP兩種協定囉。
在Visual Studio裡加入另一個WCFClient Console Application測試專案，使用「Add Service Reference」加入WCF參照：

由於WCF Service已掛在本機IIS，URL輸入httq://localhost/wcfwas/service1.svc即可，Visual Studio會自動識別WCF資訊並修改WCFClient的app.config設定。
由於WcfWas被設成"http,net.tcp"雙頻，加入參照時Visual Studio已貼心地在app.config加入兩組endpoint設定，第一組是常見的HTTP設定，第二組（黃框）則是走net.tcp協定，請記住兩組endpoint的name屬性，稍後會用到。
傳統WCF的new Service1Client()寫法在雙頻時不適用，因為.NET無法確定你想走HTTP還是TCP。

正確寫法需在建構時指定endpoint名稱，以下程式示範分別用TCP及HTTP呼叫GetData方法，都順利取得結果。