一優點（版本一）
1、可操作的的分布式應用程序
可以實現不同應用程序和在不同系統平台上開發出來的應用程序之間通信。與RMI、DOCM、CORBA最大的不同就是：Web Service 以 SOAP 作為基本通信協議從而避免了復雜的協議轉換.
2、普遍性、使用HTTP和XML進行通信
任何支持HTTP和XML 技術的設備都可以擁有和訪問Web Service，不同平台不同開發語言照樣可以調用我們發布的Web Service.
3、Web Service 甚至可以穿越防火牆，真正的自由通信
一般要訪問的Web服務器以及要訪問的Web Service的客戶端很可能位於防火牆后面，都默認關閉其它端口而開發HTTP端口，而Web service 正是基於HTTP的，所以它可以穿越防火牆.
4、通過 SOAP 協議實現異地調用
SOAP 是 Web Service 的基本通信協議，它是在分散或分布式環境中交換信息，它基於XML的協議，通過SOAP協議可以實現不同項目、不同地點、甚至異地調用應用程序
實際上，WebService 的主要目標是跨平台的可互操作性。為了達到這一目標，WebService 完全基於XML （可擴展標記語言）、XSD （XMLSchema ）等獨立於平台、獨立於軟件供應商的標准，是創建可互操作的、分布式應用程序的新平台。由此可以看出，在以下三種情況下，使用 WebService 會帶來極大的好處。
一優點（版本二）
優點一：跨防火牆的通信
如果應用程序有成千上萬的用戶，而且分布在世界 各地，那么客戶端和服務器之間的通信將是一個棘手的問題。因為客戶端和服務器之間通常會有防火牆或者代理服務器。在這種情況下，使用DCOM 就不是那么簡 單，通常也不便於把客戶端程序發布到數量如此龐大的每一個用戶手中。傳統的做法是，選擇用瀏覽器作為客戶端，寫下一大堆ASP 頁面，把應用程序的中間層暴 露給最終用戶。這樣做的結果是開發難度大，程序很難維護。
舉個例子， 在應用程序里加入一個新頁面，必須先建立好用戶界面(Web 頁面) ，並在這個頁面后面，包含相應商業邏輯的中間層組件，還要再建立至少一個ASP 頁面，用來接受用戶輸入的信息，調用中間層組件，把結果格式化為HTML 形式，最后還要把“ 結果頁” 送回瀏覽器。要是客戶端代碼不再如此依賴於HTML 表單，客戶 端的編程就簡單多了。
如果中間層組件換成WebService 的話，就可以從用戶界面直接調用中間層組件，從而省掉建立ASP 頁面的 那一步。要調用WebService ，可以直接使用MicrosoftSOAPToolkit 或.NET 這樣的SOAP 客戶端，也可以使用自己開發的 SOAP 客戶端，然后把它和應用程序連接起來。不僅縮短了開發周期，還減少了代碼復雜度，並能夠增強應用程序的可維護性。同時，應用程序也不再需要在每次調用中間層組件時，都跳轉到相應的“ 結果頁” 。
從經驗來看，在一個用戶界面和中間層有較多交互的應用程序中，使用 WebService 這種結構，可以節省花在用戶界面編程上20% 的開發時間。另外，這樣一個由WebService 組成的中間層，完全可以在應用程序集成或其它場合下重用。最后，通過WebService 把應用程序的邏輯和數據“ 暴露” 出來，還可以讓其它平台上的客戶重用這些應用程序。
優點二：應用程序集成
企業級的應用程序開發者都知道，企業里經常都要把用不同語言寫成的、在不同平台上運行的各種程序集成起來，而這種集成將花費很大的開發力量。應用程序經常需要從運行在IBM 主機上的程序中獲取數據；或者把數據發送到主機或UNIX 應用程序中去。即使在同一個平台上，不同軟件廠商生產的各種軟件也常常需要集成起來。通過WebService ，應用程序可以用標准的方法把功能和數據“ 暴露” 出來，供其它應用程序使用。
例如，有一個訂單登 錄程序，用於登錄從客戶來的新訂單，包括客戶信息、發貨地址、數量、價格和付款方式等內容；還有一個訂單執行程序，用於實際貨物發送的管理。這兩個程序來自不同軟件廠商。一份新訂單進來之后，訂單登錄程序需要通知訂單執行程序發送貨物。通過在訂單執行程序上面增加一層WebService ，訂單執行程序可以把“AddOrder” 函數“ 暴露” 出來。這樣，每當有新訂單到來時，訂單登錄程序就可以調用這個函數來發送貨物了。
優點三：B2B 的集成
用WebService 集成應用程序，可以使公司內部的商務處理更加自動化。但當交易跨越供應商和客戶、突破公司的界限時會怎么樣呢？跨公司的商務交易集成通常叫做B2B 集成。WebService 是B2B 集成成功的關鍵。通過WebService ，公司可以把關鍵的商務應用“ 暴露” 給指定的供應商和客戶。例如，把電子下單系 統和電子發票系統“ 暴露” 出來，客戶就可以以電子的方式發送訂單，供應商則可以以電子的方式發送原料采購發票。當然，這並不是一個新的概念，EDI( 電子 文檔交換) 早就是這樣了。但是，WebService 的實現要比EDI 簡單得多，而且WebService 運行在Internet 上，在世界任何地方都可 輕易實現，其運行成本就相對較低。不過，WebService 並不像EDI 那樣，是文檔交換或B2B 集成的完整解決方案。WebService 只是B2B 集成的一個關鍵部分，還需要許多其它的部分才能實現集成。
用WebService 來實現B2B 集成的最大好處在於可以輕易實現互操作性。只要把商務邏輯“ 暴露” 出來，成為WebService ，就可以讓任何指定的合作伙伴調用這些商務邏輯，而不管他們的系統在什么平台上運行，使用什么 開發語言。這樣就大大減少了花在B2B 集成上的時間和成本，讓許多原本無法承受EDI 的中小企業也能實現B2B 集成。
優點四：軟件和數據重用
軟件重用是一個很大的主題，重用的形式很多，重用的程度有大有小。最基本的形式是源代碼模塊或者類一級的重用，另一種形式是二進制形式的組件重用。
當前，像表格控件或用戶界面控件這樣的可重用軟件組件，在市場上都占有很大的份額。但這類軟件的重用有一個很大的限制，就是重用僅限於代碼，數據不能重用。原因在於，發布組件甚至源代碼都比較容易，但要發布數據就沒那么容易，除非是不會經常變化的靜態據。 WebService 在允許重用代碼的同時，可以重用代碼背后的數據。使用WebService ，再也不必像以前那樣，要先從第三方購買、安裝軟件組 件，再從應用程序中調用這些組件；只需要直接調用遠端的WebService 就可以了。舉個例子，要在應用程序中確認用戶輸入的地址，只需把這個地址直接 發送給相應的WebService ，這個WebService 就會幫你查閱街道地址、城市、省區和郵政編碼等信息，確認這個地址是否在相應的郵政編碼區域。WebService 的提供商可以按時間或使用次數來對這項服務進行收費。這樣的服務要通過組件重用來實現是不可能的，那樣的話你必須下載並安裝好包含街道地址、城市、省區和郵政編碼等信息的數據庫，而且這個數據庫還是不能實時更新的。
另一種軟件重用的情況是，把好幾個應用程序的 功能集成起來。例如，要建立一個局域網上的門戶站點應用，讓用戶既可以查詢聯邦快遞包裹，查看股市行情，又可以管理自己的日程安排，還可以在線購買電影票。現在Web 上有很多應用程序供應商，都在其應用中實現了這些功能。一旦他們把這些功能都通過WebService“ 暴露” 出來，就可以非常容易地把所 有這些功能都集成到你的門戶站點中，為用戶提供一個統一的、友好的界面。
將來，許多應用程序都會利用WebService ，把當前基 於組件的應用程序結構擴展為組件/WebService 的混合結構，可以在應用程序中使用第三方的WebService 提供的功能，也可以把自己的應用程序功能通過WebService 提供給別人。兩種情況下，都可以重用代碼和代碼背后的數據。
從以上論述可以看出，WebService 在通過Web 進行互操作或遠程調用的時候是最有用的。不過，也有一些情況，WebService 根本不能帶來任何好處。
優點（版本三）
使用Web服務的優點
Web服務是通過Web接口提供的某個功能程序段，是通過標准的Internet協議可編程訪問的Web組件。“軟件就是服務”，這已經是軟件發展的一個潮流了。未來的軟件廠商就像現在的電信公司一樣，用戶可以按照時間來租用軟件公司的服務。"Web服務”可以說是整個.NET計划的核心，簡單的說，Web服務就是一種遠程訪問的標准。Web服務也是一種應用程序，它可以使用標准的互聯網協議，像超文本傳輸協議(HTTP)和XML，將功能綱領性地體現在互聯網和企業內部網上。可將Web服務視作Web上的組件編程。從理論上講，開發人員可通過調用Web應用編程接口(API)(就像調用本地服務一樣)，將Web服務集成到應用程序中，不同的是Web API調用可通過互聯網發送給位於遠程系統中的某一服務。
Web服務是為應用程序的使用而准備的，而不是為最終用戶准備的。通過將一個系統作為一個Web，第三方可以將我們的系統功能整合到他們自己的客戶應用程序中。這樣便獲得了一種開發解決方案的新途徑:無需在系統中設計所需的功能，只需簡單地訪問合適的Web服務以執行所需的操作即可。這一切，是通過將緊密禍合的、高效的n層計算技術與面向消息的、松散禍合的Web概念相結合來實現的。
Web服務不僅為那些使用第三方Web服務的應用程序提供了很多的好處，也為發布客戶Web服務的應用程序本身提供了很多好處:
1平台的無關性
Web服務使用的HTTP和SOAP等協議己經是互聯網上通用的協議，任何能夠訪問Internet的平台都可以訪問Web服務。任何與Internet建立連接的應用程序都可以向Internet上的任何一個Web服務發送XML格式的SOAP消息，同時也可以接收來自Web服務的SOAP消息。
2功能復用
功能復用采用了許多與接口相關的技術，可以使用面向對象的技術和組件對象的技術來創建系統。功能復用的應用程序設計具有在自己的程序中使用其他的系統執行特殊功能的特性，通過使用外部廠商提供的Web服務，開發人員能夠利用外部廠商己經實現的功能。這意味着可以使用較少的時間開發與解決具體的業務問題無關的應用程序，使用第三方的技能和經驗，可以使你集中精力處理業務問題。以前，為尋求某一功能，開發人員不得不在某些技術中做出選擇，Web服務則支持開發人員選擇正確的功能，而不是選擇正確的技術。其原因就在於，接口是己經定義好的，執行實際功能的應用程序可以用任意的編程語言編寫。開發人員選擇這項功能的唯一依據是系統需求，而不是技術的約束。
3服務器的中立性
Web服務的接口是基於標准的，而且在Web服務和客戶機之間傳遞的消息在HTTP之上使用了XML。因此，開發Web服務所使用的程序設計語言和服務器軟件是沒有關系的。Web服務所在的服務器可以運行UNIX,Windows 2000或其他的操作系統，而Web服務幕后執行功能的軟件可以是Java, C#或開發小組習慣使用的任何其他編程語言編寫的。有了Web服務之后，你就不再被迫基於第三方的功能需求來選擇一種程序設計語言了。這給了從事Web服務開發的人員很大的靈活性，開發人員也不再需要根據客戶機
的需求，而是根據自己使用某個程序設計語言方面的經驗來開發解決方案。這增加了開發人員的滿意程度，也提高了工作效率。
4拓展業務
通過允許第三方使用Web服務訪問內部傳統的方式，企業允許消費者以更加集成化的方式和以用戶為中心的方式訪問他們。當允許其他的應用程序使用企業應用程序中的功能時，企業便可以將精力集中在自己的特殊產品上。第三方能夠結合開發廠商提供的相關Web服務為消費者開發集成的解決方案，給用戶帶來更好的體驗，而且廠商也拓展了自己的業務。
Web服務也能夠被用來拓展貿易伙伴關系。通過將供應鏈與Web服務的供應商集成在一起，可以使業務過程能夠動態、靈活地變換需求。當有新的業務伙伴加入時，新伙伴就能夠使用公司所提供的Web服務順利地集成到整個系統中。
5安全的通信
Web服務像所有的Web應用程序一樣安全，保護在線商業站點使用的技術也同樣用於保護和驗證Web服務的身份。對數據進行全球統一編址並不意味着讓所有人都可以訪問你的數據，我們可以通過不公布其URI而很方便地隱藏對象，也可以很方便地對對象使用安全策略。幾乎所有的防火牆都允許HTTP通過，這就意味着可以在Internet上的防火牆背后提供Web服務，但是這並不意味着能夠任意訪問你使用XML編碼的HTTP信息包的受保護的網絡。我們可以對每個數據對象使用4種基本的權限:GET權限、PUT
權限、DELETE權限和POST權限。我們可以使一部分資源具有或不具有GET, PUT, DELETE和POST四種權限，這與當前廣泛使用的文件系統的權限有點類似，它是有效和成熟的。以資源為中心的web服務可以很好地與防火牆進行合作。防火牆管理員能夠很容易地通過阻止不使用GET方法的HTTP請求而使一種web服務只能被讀取。
Web Service 優勢
１．異構平台的互通性
理論上， Web Service 最大的優勢是提供了異構平台的無縫街接技術手段。由於不同的用戶使用不同的硬件平台，不同的操作平台，不同的操作系統，不同的軟件，不同的 協議通信，這就產生了互相通信的需求。 Web Service 使任何兩個應用程序，只要能讀寫ＸＭＬ，那么就能互相通信。
２．更廣泛的軟件復用
軟件的復用技術通過組合已有模塊來搭建應用程序，能大幅度提高軟件的生產效率和質量。用戶只要獲得了描述 Web Service 的 WSDL 文件，就可以方便地生成客戶端代理，並通過代理訪問 Web Service 。
3. 普通的通信能力
Web Service 可用基於 XML 的 SOAP 來表示數據和調用請求。並且通過 HTTP 協議傳輸 XML 格式的數據。
4. 迅捷的軟件發行方式
Web Service 將徹底地改變軟件的發行方式。軟件供應商可以把軟件分解成若干 Web Service 模塊構成的系統，直接在 Web 上發布軟件。
5. 方便的商務的商務的集成
企業通過把業務軟件的核心模塊以 Web Service 的形式向其合作伙伴發布，這樣既保留了原有的數據和軟件，又方便了彼此的聯系。
缺點
缺點一：單機應用程序
目前，企業和個人還使用着很多桌面應用程序。其中一些只需要與本機上的其它程序通信。在這種情況下，最好就不要用WebService ，只要用本地的 API 就可以了。COM 非常適合於在這種情況下工作，因為它既小又快。運行在同一台服務器上的服務器軟件也是這樣。最好直接用COM 或其它本地的API 來 進行應用程序間的調用。當然WebService 也能用在這些場合，但那樣不僅消耗太大，而且不會帶來任何好處。
缺點二：局域網的同構應用程序
在許多應用中，所有的程序都是用VB 或VC 開發的，都在Windows 平台下使用COM ，都運行在同一個局域網上。例如，有兩個服務器應用程序需要相互通信，或者有一個Win32 或WinForm 的客戶程序要連接局域網上另一個服務器的程序。在這些程序里，使用DCOM 會比SOAP/HTTP 有效得多。 與此相類似，如果一個.NET 程序要連接到局域網上的另一個.NET 程序，應該使用.NETremoting 。有趣的是，在.NETremoting 中， 也可以指定使用SOAP/HTTP 來進行WebService 調用。不過最好還是直接通過TCP 進行RPC 調用，那樣會有效得多。