一、禁用HTTPPOST/GET協(xié)議

　　除非另外指定，否則，.NET將試圖把Web服務(wù)綁定到三種協(xié)議：HTTP/POST、HTTP/GET和SOAP。之所以說“試圖”，是因為依賴于服務(wù)的參數(shù)和返回類型，HTTP/GET協(xié)議可能不可用。.NET生成的WSDL文件將自動包含綁定這三種協(xié)議的指令，客戶程序可以自由選擇使用哪種協(xié)議與服務(wù)通信。

　　只要在Web.config文件中加入下列內(nèi)容，就可以方便地刪除對HTTP/POST和HTTP/GET協(xié)議的綁定：

　　為什么要避免通過HTTP/POST和HTTP/GET協(xié)議引出Web服務(wù)呢？主要的兩個原因是安全和互操作性。HTTP/GET的安全性不如SOAP，而且由于HTTP/GET常見于Web鏈接，懷有惡意的人可能利用它實施欺騙，使別人在不知不覺中用自己的安全標(biāo)識調(diào)用Web服務(wù)，卻還以為自己在點擊Web鏈接。

　　就互操作性而言，SOAP是廣泛應(yīng)用的Web服務(wù)通信標(biāo)準，而HTTP/GET和HTTP/POST不是。因此，對于.NET生成的WSDL文檔中默認包含的HTTP/GET和HTTP/POST綁定，許多自動生成代理服務(wù)器的工具不會理解。因此，如果你的Web服務(wù)不是非綁定到HTTP/GET和HTTP/POST協(xié)議不可，最好取消這兩種綁定。

二、用tcpTrace查看SOAP請求/應(yīng)答消息

　　對于開發(fā)Web服務(wù)應(yīng)用的人來說，調(diào)試可能是件異乎尋常的難事，因為無論是.NETSDK還是VS.net，都沒有提供工具來查看客戶端和服務(wù)器之間的SOAP消息。

　　如果.NET和非.NET的客戶端、服務(wù)器端的交互過程出現(xiàn)了問題，要想找出問題的根源，擁有查看SOAP消息的能力就尤為重要，因為這類問題往往與SOAP消息的格式有關(guān)（例如，“消息中包含了SOAPAction嗎？”）。

　　tcpTrace是一個查看這類消息交換過程的優(yōu)秀工具，它通過設(shè)置一個客戶端和服務(wù)器端之間的隧道工作。啟動tcpTrace時，它會要求輸入目標(biāo)URL和端口號，以及tcpTrace監(jiān)聽的本地端口號。這樣，你就可以通過設(shè)置代理stub的Url屬性，把stub指向這個本地端口（例如，localhost:8080）。tcpTrace能夠記錄所有的請求和應(yīng)答HTTP消息。

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

三、簡化接口設(shè)計

　　在眾多有關(guān)n-層應(yīng)用設(shè)計的論述中，簡化接口設(shè)計這一設(shè)計要訣可以說是隨處可見。但是，對于Web服務(wù)這樣的分布式計算環(huán)境，簡化接口設(shè)計的重要性更加突出。

　　在設(shè)計分布式應(yīng)用時，出于性能和可伸縮性的考慮，應(yīng)當(dāng)保證客戶端和服務(wù)器端之間的調(diào)用盡可能地少。減少網(wǎng)絡(luò)調(diào)用不僅有利于減少通信開銷（如果只用一個SOAP消息可以達到目標(biāo)，就絕對不要發(fā)三個消息），降低網(wǎng)絡(luò)流量，而且提高了應(yīng)用的性能。顯然，這一切都是開發(fā)者夢寐以求的目標(biāo)。那么簡化的接口到底有何特征呢？

　　首先來看一個復(fù)雜接口的例子：
namespaceChattyService{publicclassChattyService:WebService{privatestringusername;privatestringpassword;publicstringUsername{[WebMethod]set{username=Username;}}publicstringPassword{[WebMethod]set{password=Password;}}[WebMethod]publicboolLogon(){//驗證身份returntrue;}}}