webService幾個最佳實踐

1．  動態url地址的配置

在消費Web服務時，最初都是直接引用靜態Url地址，後來發現當Web服務生產方的地址有所變化時，我的客戶端消費程式（此程式也可能是消費Web服務的Web應用程式服務端）必須要重新更新Web服務，這樣就會增大程式部署的難度。為了使消費程式更加靈活，於是我就在web.config中加入了一段appSettings的配置資訊，將需要修改的Url放入此段配置中，然後開啟在asp.net1.1工程中引用最初的靜態Web服務地址時自動生成的代理類檔案（通常是\Web References\’web服務名’\Reference.cs），將this.URL屬性修改為從配置檔案中讀取剛配好的Url資訊，如：

web.config :

       
   

 
Reference.cs :
public class AccountVerifyForWebservice : System.Web.Services.Protocols.SoapHttpClientProtocol {

        public AccountVerifyForWebservice() {

                     this.Url = ConfigurationSettings.AppSettings["URL_AccountVerifyForWebservice"];

        }

.

}

這樣就降低了部署難度，因為在Web服務地址改變後，你不需要在開發環境中更新消費程式然後再重新部署到客戶端，而只需修改客戶端的web.config檔案內容就可以了，你甚至還可以自己配置一個xml檔案來列舉所有可能的url地址，然後在代理類中列舉這些地址列表即可。

 

 

2．  DNS解析問題

在一個專案中與Weblogic打交道，需要我的aspnet應用程式消費對方提供的web服務，雖然我很順利的完成了Web引用，即通過disco發現了Web服務，自動下載了wsdl檔案，並生成了代理類檔案，也正常通過了編譯，但是在執行時一旦開始invoke此web服務就會報錯，仔細檢查了代理類一切正常，很納悶搞不懂為什麼。後來有同事告訴我可能是DNS的原因，我這才知道Web服務的生產環境上建立了負載平衡，而其提供的DNS伺服器負責將http://eai.ibss:9001/VerifyWebService/.../xxx .jws這樣的以域名地址動態的解析到所有提供Web服務的負載平衡伺服器上，部署環境中的機器都可以通過此DNS訪問web服務。一開始，服務釋出方提供給我的只是其中一臺固定Web伺服器的靜態ip地址（如http://192.168.0.1:9001/VerifyWebService/.../xxx .jws），而wsdl文件中描述的soap呼叫地址是域名地址，引用時自動生成的代理類的Url屬性自然就是域名地址了，而我的開發環境不能夠訪問DNS伺服器，也就不能解析域名地址，所以在執行時會抱錯，因為soap資訊根本就沒有傳送到正確的Web伺服器上去。這種開發，生產和部署環境的不同有時是非常令人頭痛的~~

後來通過採用第一個問題中介紹的配置檔案的解決方案就很有效地解決了目前這個問題，開發除錯時使用靜態地址，部署時更換為域名地址即可。

 

3．  Web服務和Web應用程式的分離

最好不要在同一臺生產伺服器上同時部署web服務和消費此web服務的web應用程式，這樣會造成不必要的效能瓶頸。當客戶端請求一個web應用程式的某個頁面時，伺服器將佔用一個http連線，同時當該頁的生成或某個事件被觸發時需要同步呼叫一個web服務，那麼此時該伺服器將增加一個http連線的佔用，也就是說使用者請求一次頁面有可能會在伺服器上同時造成兩個http連線，若伺服器本身的http連線數為1000個的話那麼可能的實際使用者連線數只有500個。

 

4．  避免使用非string型資料

儘量避免在Web服務中使用非string型的資料作為Web方法的引數或返回值，因為Java或者別的消費客戶端可能並不能夠正常解析int或arraylist這樣的資料型別，而string型幾乎是最通用的資料型別，至少與java能夠正常互動。儘量不要提供DataSet這樣的複雜資料型別，儘管網上已有許多解決方案，但我感覺都挺麻煩的，還不如將DataSet直接輸出到一個二維string型陣列中。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-624813/，如需轉載，請註明出處，否則將追究法律責任。