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

 
     
  一、禁用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)提供服務,事情會變得很麻煩。 
   

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章