ASP.NET開發Web服務的五則技巧

　　除非另外指定，否則，.NET將試圖把Web服務綁定到三種協議：HTTP/POST、HTTP/GET和SOAP。之所以說“試圖”，是因為依賴於服務的參數和傳回型別，HTTP/GET協議可能不可用......

　　一、禁用HTTP POST/GET協議

　　除非另外指定，否則，.NET將試圖把Web服務綁定到三種協議：HTTP/POST、HTTP/GET和SOAP。之所以說“試圖”，是因為依賴於服務的參數和傳回型別，HTTP/GET協議可能不可用。.NET產生的WSDL檔案將自動包含綁定這三種協議的指令，客戶程式可以自由選擇使用哪種協議與服務通訊。

　　只要在Web.config檔案中加入下列內容，就可以方便地刪除對HTTP/POST和HTTP/GET協議的綁定：

　　

**< webservices> 　　**< protocols> 　　**< remove name="HttpPost" /> 　　**< remove name="HttpGet" /> 　　**< /protocols> 　　**< /webservices>

　　為什麼要避免通過HTTP/POST和HTTP/GET協議引出Web服務呢?主要的兩個原因是安全和互通性。HTTP/GET的安全性不如SOAP，而且由於HTTP/GET常見於Web連結，懷有惡意的人可能利用它實施欺騙，使別人在不知不覺中用自己的安全標識調用Web服務，卻還以為自己在點擊Web連結。

　　就互通性而言，SOAP是廣泛應用的Web服務通訊標準，而HTTP/GET和HTTP/POST不是。因此，對於.NET產生的WSDL文檔中預設包含的HTTP/GET和HTTP/POST綁定，許多自動組建代理程式伺服器的工具不會理解。因此，如果你的Web服務不是非綁定到HTTP/GET和HTTP/POST協議不可，最好取消這兩種綁定。

　　二、用tcpTrace查看SOAP請求/應答訊息

　　對於開發Web服務應用的人來說，調試可能是件異乎尋常的難事，因為無論是.NET SDK還是VS.NET，都沒有提供工具來查看用戶端和伺服器之間的SOAP訊息。

　　如果.NET和非.NET的用戶端、伺服器端的互動過程出現了問題，要想找出問題的根源，擁有查看SOAP訊息的能力就尤為重要，因為這類問題往往與SOAP訊息的格式有關(例如，“訊息中包含了SOAPAction 嗎?”)。

　　tcpTrace(www.pocketsoap.com/tcptrace)是一個查看這類訊息交換過程的優秀工具，它通過設定一個用戶端和伺服器端之間的隧道工作。啟動tcpTrace時，它會要求輸入目標URL和連接埠號碼，以及tcpTrace監聽的本地連接埠號碼。這樣，你就可以通過設定代理stub的Url屬性，把stub指向這個本地連接埠(例如，localhost:8080)。tcpTrace能夠記錄所有的請求和應答HTTP訊息。

　　tcpTrace的一個局限是，它在訊息流程程中所處的位置決定了它不能用來查看通過SSL發送的訊息。如果你要查看通過SSL發送的SOAP訊息，只能編寫一個定製的ISAPI過濾器。

　　三、簡化介面設計

　　在眾多有關n-層應用設計的論述中，簡化介面設計這一設計要訣可以說是隨處可見。但是，對於Web服務這樣的分散式運算環境，簡化介面設計的重要性更加突出。

　　在設計分布式應用時，出於效能和延展性的考慮，應當保證用戶端和伺服器端之間的調用儘可能地少。減少網路調用不僅有利於減少通訊開銷(如果只用一個SOAP訊息可以達到目標，就絕對不要發三個訊息)，降低網路流量，而且提高了應用的效能。顯然，這一切都是開發人員夢寐以求的目標。那麼簡化的介面到底有何特徵呢?

首先來看一個複雜介面的例子：

　　

namespace ChattyService { 　　public class ChattyService : WebService { 　　private string username; 　　private string password; 　　public string Username { 　　[WebMethod] 　　set { 　　username = Username; 　　} } 　　public string Password { 　　[WebMethod] 　　set { 　　password = Password; 　　} } 　　[WebMethod] 　　public bool Logon() { 　　// 驗證身份 　　return true; 　　} 　　} 　　}

　　在這個例子中，username和password是兩個屬性，調用logon()方法之前首先必須設定這兩個屬性。有一個問題光看這段代碼不太容易注意到，這就是username和password都作為Web方法引出。這就是說，每次對屬性的get/set操作都會導致一個對服務的調用。

按照簡化介面設計的要求，改進後的代碼如下：

　　

namespace ChattyService { 　　public class ChattyService : WebService { 　　[WebMethod] 　　public bool Logon(string Username, string Password) { 　　// 驗證身份 　　return true; 　　} 　　} 　　}

　　現在，username和password成了logon()方法的參數。修改之後的代碼的優點在於，它把登入操作對伺服器的三次調用降低到了一次。另一方面，如果參數的個數太多，這個方法可能看起來很不像樣。這時，可能要把方法的參數整理成幾個複雜類型，例如，把username和password兩個參數封裝到一個credential(認證)對象裡面。

　　四、在Web.Config中儲存應用私人的資料

　　用ASP.NET開發的Web服務能夠發揮出.aspx應用的所有特長，包括用web.config檔案儲存應用私人資料的能力(例如，資料庫連接字串、檔案路徑等)。用Web.config而不是global.asax檔案的好處在於修改配置之後不必重新構造應用。

　　五、避免使用ASP.NET工作階段狀態

　　.NET實現的工作階段狀態管理功能解決了它的前輩ASP 3.0存在的許多問題，例如請求序列化等，但仍存在一些局限。應當認識到，.NET的工作階段狀態管理功能不是專門為Web服務環境中的工作階段狀態而設計，而是為了在範圍更廣泛的ASP.NET應用中管理工作階段狀態而設計，它依賴於HTTP Cookie(有一種通過改寫URL實現的不需要Cookie的模式，但不適用於Web服務)。

　　Cookie是HTTP專屬的。在Web上，所有的瀏覽器都支援HTTP，所以Cookie非常適合在Web應用中使用。但是，在Web服務中應用Cookie卻把服務限定到了HTTP協議上。另一方面，SOAP協議的運行是獨立於傳輸協議的，因此如果把Web服務應用限制到HTTP協議上，應用的靈活性也受到了限制，一旦要通過非HTTP的傳輸協議(例如SMTP)提供服務，事情會變得很麻煩。