一、禁用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操作都會導致一個對服務的調用。
