一、禁用HTTP POST/GET協(xié)議
  
  　　除非另外指定，否則，.NET將試圖把Web服務(wù)綁定到三種協(xié)議：HTTP/POST、HTTP/GET和SOAP。之所以說(shuō)“試圖”，是因?yàn)橐蕾囉诜?wù)的參數(shù)和返回類型，HTTP/GET協(xié)議可能不可用。.NET生成的WSDL文件將自動(dòng)包含綁定這三種協(xié)議的指令，客戶程序可以自由選擇使用哪種協(xié)議與服務(wù)通信。
  
  　　只要在Web.config文件中加入下列內(nèi)容，就可以方便地刪除對(duì)HTTP/POST和HTTP/GET協(xié)議的綁定：
  
  <webservices>
   <protocols>
   <remove name="HttpPost" />
   <remove name="HttpGet" />
   </protocols>
  </webservices>
  
  
  
  　　為什么要避免通過(guò)HTTP/POST和HTTP/GET協(xié)議引出Web服務(wù)呢？主要的兩個(gè)原因是安全和互操作性。HTTP/GET的安全性不如SOAP，而且由于HTTP/GET常見(jiàn)于Web鏈接，懷有惡意的人可能利用它實(shí)施欺騙，使別人在不知不覺(jué)中用自己的安全標(biāo)識(shí)調(diào)用Web服務(wù)，卻還以為自己在點(diǎn)擊Web鏈接。
  
  　　就互操作性而言，SOAP是廣泛應(yīng)用的Web服務(wù)通信標(biāo)準(zhǔn)，而HTTP/GET和HTTP/POST不是。因此，對(duì)于.NET生成的WSDL文檔中默認(rèn)包含的HTTP/GET和HTTP/POST綁定，許多自動(dòng)生成代理服務(wù)器的工具不會(huì)理解。因此，如果你的Web服務(wù)不是非綁定到HTTP/GET和HTTP/POST協(xié)議不可，最好取消這兩種綁定。
  
  
  
  二、用tcpTrace查看SOAP請(qǐng)求/應(yīng)答消息
  
  　　對(duì)于開(kāi)發(fā)Web服務(wù)應(yīng)用的人來(lái)說(shuō)，調(diào)試可能是件異乎尋常的難事，因?yàn)闊o(wú)論是.NET SDK還是VS.NET，都沒(méi)有提供工具來(lái)查看客戶端和服務(wù)器之間的SOAP消息。
  
  　　如果.NET和非.NET的客戶端、服務(wù)器端的交互過(guò)程出現(xiàn)了問(wèn)題，要想找出問(wèn)題的根源，擁有查看SOAP消息的能力就尤為重要，因?yàn)檫@類問(wèn)題往往與SOAP消息的格式有關(guān)（例如，“消息中包含了SOAPAction 嗎？”）。
  
  　　tcpTrace（www.pocketsoap.com/tcptrace）是一個(gè)查看這類消息交換過(guò)程的優(yōu)秀工具，它通過(guò)設(shè)置一個(gè)客戶端和服務(wù)器端之間的隧道工作。啟動(dòng)tcpTrace時(shí)，它會(huì)要求輸入目標(biāo)URL和端口號(hào)，以及tcpTrace監(jiān)聽(tīng)的本地端口號(hào)。這樣，你就可以通過(guò)設(shè)置代理stub的Url屬性，把stub指向這個(gè)本地端口（例如，localhost:8080）。tcpTrace能夠記錄所有的請(qǐng)求和應(yīng)答HTTP消息。
  
  　　tcpTrace的一個(gè)局限是，它在消息流程中所處的位置決定了它不能用來(lái)查看通過(guò)SSL發(fā)送的消息。如果你要查看通過(guò)SSL發(fā)送的SOAP消息，只能編寫(xiě)一個(gè)定制的ISAPI過(guò)濾器。
  
  
  
  三、簡(jiǎn)化接口設(shè)計(jì)
  
  　　在眾多有關(guān)n-層應(yīng)用設(shè)計(jì)的論述中，簡(jiǎn)化接口設(shè)計(jì)這一設(shè)計(jì)要訣可以說(shuō)是隨處可見(jiàn)。但是，對(duì)于Web服務(wù)這樣的分布式計(jì)算環(huán)境，簡(jiǎn)化接口設(shè)計(jì)的重要性更加突出。
  
  　　在設(shè)計(jì)分布式應(yīng)用時(shí)，出于性能和可伸縮性的考慮，應(yīng)當(dāng)保證客戶端和服務(wù)器端之間的調(diào)用盡可能地少。減少網(wǎng)絡(luò)調(diào)用不僅有利于減少通信開(kāi)銷（如果只用一個(gè)SOAP消息可以達(dá)到目標(biāo)，就絕對(duì)不要發(fā)三個(gè)消息），降低網(wǎng)絡(luò)流量，而且提高了應(yīng)用的性能。顯然，這一切都是開(kāi)發(fā)者夢(mèng)寐以求的目標(biāo)。那么簡(jiǎn)化的接口到底有何特征呢？
  
  　　首先來(lái)看一個(gè)復(fù)雜接口的例子：
  
  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() {
   // 驗(yàn)證身份
   return true;
   }
   }
  }
  
  
  
  　　在這個(gè)例子中，username和password是兩個(gè)屬性，調(diào)用logon()方法之前首先必須設(shè)置這兩個(gè)屬性。有一個(gè)問(wèn)題光看這段代碼不太容易注意到，這就是username和password都作為Web方法引出。這就是說(shuō)，每次對(duì)屬性的get/set操作都會(huì)導(dǎo)致一個(gè)對(duì)服務(wù)的調(diào)用。
  
  　　按照簡(jiǎn)化接口設(shè)計(jì)的要求，改進(jìn)后的代碼如下：
  
  namespace ChattyService {
   public class ChattyService : WebService {
   [WebMethod]
   public bool Logon(string Username, string Password) {
   // 驗(yàn)證身份
   return true;
   }
   }
  }
  
  
  
  　　現(xiàn)在，username和password成了logon()方法的參數(shù)。修改之后的代碼的優(yōu)點(diǎn)在于，它把登錄操作對(duì)服務(wù)器的三次調(diào)用降低到了一次。另一方面，如果參數(shù)的個(gè)數(shù)太多，這個(gè)方法可能看起來(lái)很不像樣。這時(shí)，可能要把方法的參數(shù)整理成幾個(gè)復(fù)雜類型，例如，把username和password兩個(gè)參數(shù)封裝到一個(gè)credential（證書(shū)）對(duì)象里面。
  
  
  
  四、在Web.Config中保存應(yīng)用私有的數(shù)據(jù)
  
  　　用ASP.NET開(kāi)發(fā)的Web服務(wù)能夠發(fā)揮出.aspx應(yīng)用的所有特長(zhǎng)，包括用web.config文件保存應(yīng)用私有數(shù)據(jù)的能力（例如，數(shù)據(jù)庫(kù)連接字符串、文件路徑等）。用Web.config而不是global.asax文件的好處在于修改配置之后不必重新構(gòu)造應(yīng)用。
  
  
  
  五、避免使用ASP.NET會(huì)話狀態(tài)
  
  　　.NET實(shí)現(xiàn)的會(huì)話狀態(tài)管理功能解決了它的前輩ASP 3.0存在的許多問(wèn)題，例如請(qǐng)求串行化等，但仍存在一些局限。應(yīng)當(dāng)認(rèn)識(shí)到，.NET的會(huì)話狀態(tài)管理功能不是專門(mén)為Web服務(wù)環(huán)境中的會(huì)話狀態(tài)而設(shè)計(jì)，而是為了在范圍更廣泛的ASP.NET應(yīng)用中管理會(huì)話狀態(tài)而設(shè)計(jì)，它依賴于HTTP Cookie（有一種通過(guò)改寫(xiě)URL實(shí)現(xiàn)的不需要Cookie的模式，但不適用于Web服務(wù)）。
  
  　　Cookie是HTTP獨(dú)有的。在Web上，所有的瀏覽器都支持HTTP，所以Cookie非常適合在Web應(yīng)用中使用。但是，在Web服務(wù)中應(yīng)用Cookie卻把服務(wù)限定到了HTTP協(xié)議上。另一方面，SOAP協(xié)議的運(yùn)行是獨(dú)立于傳輸協(xié)議的，因此如果把Web服務(wù)應(yīng)用限制到HTTP協(xié)議上，應(yīng)用的靈活性也受到了限制，一旦要通過(guò)非HTTP的傳輸協(xié)議（例如SMTP）提供服務(wù)，事情會(huì)變得很麻煩。