Web Services何時才能更具意義?
2024-07-21 02:21:21
供稿：網友
目前web services還是一門相當新的技術，而且不是每個人都知道該如何充分利用它們。以我的經驗（我曾在web services底層架構上構建了一個完整的企業軟件產品），我發現web services有這樣兩個主要用途：將多個系統整合到一起，以及將功能函數(function)作為組件提供給遠程調用。本文我將介紹在使用后一種方法時需要注意的問題。
當你想要用web service來提交一個新的函數或service給可能要遠程調用的客戶端時，你需要考慮到許多因素。不論這個函數是用于內部還是用于外部的客戶或合作者，在visual studio .net中開始一個新的web service項目之前先設計一個大綱會幫你節省不少時間。比如，在要求訪問專屬數據庫時以及/或者在很難實現本地部署或造價太高時，將一個功能函數作為一個web service來提供就會很有意義。用于執行簡單計算的函數不要求訪問專屬數據，同時在進行本地部署或維護方面也沒那么復雜。
當功能函數需要一個復雜的安裝過程或一個復雜的、昂貴的硬件配置時，使用web services或許是你的最佳選擇。在這種情況下，將功能函數作為一個web service來提供會為你的客戶解決很多麻煩事，因為他們不用在本地部署它。如果你經常需要發布一個功能函數的新版本，那么你也該考慮用web services。一個web service會提供一種簡便的方法給所有使用該功能函數的客戶發布升級版本，而無需在每次發布新版本時讓他們重新部署一遍。公眾所期望的通過web service接口提供需要訪問專屬數據的功能函數是不容易得到的。不管怎樣，客戶端需要能夠得到數據，而web service顯然是一個比傳送普通文件（flat file）數據更好的方法。最后，最好能將依賴于經常改變數據的功能函數作為web services來提供。在更新數據速度和更改數據大小方面的提高會使遠程訪問專屬數據的優勢更為明顯。
在你決定是否將一個功能函數作為一個web service來提供時，部署問題是一個最重要的因素。web services會使軟件的部署更簡單。比如，如果你在構建一個指導駕駛的應用程序，你就不需要擔心如何安裝地圖軟件?；蛘呷绻阌幸粋€需要經常升級的功能函數，你就不需要每幾個月就回到公司讓他們幫你部署更新。
明智地選擇web services
然而，你要了解并非web services的所有方面都是好的，它們也有優點和缺點。當然，在開始你的項目之前你得確認其優點是多于缺點的。否則你唯一需要用到新的web service的地方就是在你的簡歷中了。
比如說，一個運行于其他架構中的web service肯定不如在你自己的服務器中運行的那么可靠。即便是保護最完善的和維護得最好的網絡在某些方面也并不是完全牢靠的。你必須能夠向你的客戶證明，無論是在內部還是外部，在service的部署和維護方面有很大優勢來彌補本身固有的在一個易出錯的網絡中遠程訪問功能函數所帶了的不足之處。
我最喜歡用平方根功能函數來說明一個典型的“錯誤”使用web service的例子（見表1）。雖然這個場景有點夸張，但卻很能說明問題。平方根功能函數沒有體現任何web service所提供的優勢，相反卻體現了其所有的缺陷。對它進行部署并非難事，而且它沒有（至少最近沒有）因為發生了變化而需要進行重新部署，這樣一來就使web services部署優勢不能夠體現出來了。而且，它不需要訪問任何數據庫或者專屬數據來實現計算功能。然而它的確需要將功能函數請求發送到web服務器，這會致使web service因為其本身固有的緩慢或無網絡鏈接問題而執行地很慢。在這種情況下，一個象平方根這樣的小函數會導致一個很大的應用程序的機能完全停止。在你首次嘗試web services時，它會試圖將一些應用函數（utility function）作為web services來發布――一些將位圖（bitmap）轉化為jpeg的函數或壓縮位圖數據的函數。這些功能函數或許是非常便利的，但它們并不適合用web services提供。
當數據可能會對其他部門有用時，內部的department-to-department (d2d) web services可能會適用于所有功能函數，甚至是一些很難部署的功能函數。web services提供了一種很棒的方法能夠快速高效地在企業內部實現對軟件部署和維護，而無需去訪問防火墻以外的web services。因為d2d web services是在你的網絡內部運行的，這樣就減少了由于網絡問題而導致程序中斷的可能性，而且volume的層級也更容易預測。
通常在一個部門構建需要訪問其他部門管制的數據的程序時，持有這些數據的部門會設置一個數據輸出程序（data export procedure）將一個包含該數據的普通文件傳輸到所需要的部門，這樣他們便可以將數據導入數據庫中了。遺憾的是這種極不方便的共享數據方法還是非常普遍的。web services提供了一種更好的方法為內部部門數據共享加載普通文件數據。web services不是將原始數據傳送過去讓客戶端程序自己進行數據處理，而是更多地讓你來控制，它們會提供計算功能而不是用來計算的數據。這不僅是一種更穩定的信息共享的方法，而且它還提供了一種機制來增強和數據有關的商業規則。
盡管采用了同樣的方法，對需要通過web services來提供給外部的功能函數的評估還是非常重要的。使用一個外部企業提供的web service的危險性更大一些。然而，這種危險性會被它們能充分利用分布程序跨防火墻而無需在本地部署service的優勢所抵消（見表2）。
考慮以下問題
在你向公司建議將某一功能函數作為一個web service 提供給你的商業伙伴或用戶時，你需要說明其優勢是否大于劣勢。先考慮下面這些問題的答案會對你有所幫助：
對使用的程序而言，該功能的緊急性有多高？
傳入或輸出web service 的數據有多敏感?
數據源是什么? 它多長時間更新一次?是否是公開的?
你多久參與一次該功能新版本的發布？
誰在控制web service所處的架構? 該架構是否可靠?
web services在大多數it企業都具有利用潛力，尤其是在軟件部署方面，但你也不能將它隨意使用到任何地方。你要避免毫無意義地將功能函數或服務用做web services。有時在本地部署是非常有必要的。
