以下為網上看到的對Web Service比較經典易懂的分析，轉錄之．

Web?Service是最近幾年比較火的一個東西，它帶來了一大堆的新名詞，所以顯得比較炫。看透其華而不實的表面，它也就不再神奇。下面的討論均以Java為參考。?

1?訪問一個Web?Service實際上可以看作調用一個函數，唯一不同的就是這個函數是遠程的，這么一說，它和RMI就沒有什么本質的區別了。?
既然是一個函數，當然要有函數的聲明了，完成這個工作的就是WSDL，它詳細的定義函數的原型，包括函數名、入口參數、出口參數，這就是WSDL中opertion完成的工作。?
既然是一個遠程的函數，還要涉及與遠程地址的一個綁定，這是WSDL中service的任務。?
Axis是一個可以通過WSDL生成相應訪問代碼的開發包，JBuilder中將它集成了進去，通過Wizard的方式簡化了原本需要在命令行中手工完成的操作。?

2?既然是遠程訪問，就一定要有一個訪問協議，Web?Service的訪問協議就是SOAP，SOAP建立在XML之上，不同的就是對XML原本沒有限制的格式加上了一些限制，需要有envelope，在envelope中，還要分header和body。?
如果利用SOAP開發Web?Service的程序，那就需要根據WSDL的定義來自行組裝SOAP包，這顯然要比利用WSDL直接面向Web?Service開發要復雜一些。?
JAXM是一個利用SOAP進行通信的開發包，它簡化了SOAP消息的打包過程。?

3?SOAP是建立在XML之上的，那么顯然XML的開發包同樣適合于SOAP。?
在這個層次上開發Web?Service，除了要完成上一層的工作外，還要自行按照SOAP的格式組裝SOAP消息，這顯然又增加了工作量。?
XML的開發工具就比較多了，從最簡單的SAX和DOM到DOM4J、JDOM，還有不少XML到對象綁定的工具，如JAXB、Castor等等。?
其實，不考慮Web?Service，完全用XML做通信協議的情況也并不少見。知曉XML-RPC的存在，就不難理解了XML做通信的含義了。?

截至到這里所討論的內容，Sun提供了JWSDP（Java?Web?Service?Developer?Pack），其中包含從XML解析到WSDL生成的全套解決方案。?

4?上面討論的所有東西實際上都還停留在傳遞消息的內容上，并未涉及通信的過程。不要一看到Web?Service的Web就想當然認為它只能通過HTTP來傳輸。前面的討論可以看出，所有的消息內容與傳輸并無直接關系，所以，無論是以HTTP傳輸，還是SMTP或是自定義的協議都沒有問題。?
在這個層次上開發Web?Service，前面的種種險阻之外，還要完成對XML的手工解析工作。?
這里還是以最常見的HTTP方式來討論。?
HTTP的開發就將Server和Client區別對待，Server的實現通常的選擇是Servlet，讓Web?Server替我們完成HTTP協議的解析可以省去我們很多的作。Client的實現可以選擇JDK自帶的Http?Client，Apache的Jakarta項目下的Commons子項目也提供了一個HttpClient。?

5?無論是HTTP還是SMTP，抑或是自定義協議，歸根結底都是應用級的協議，底層的實現都是由Socket完成。到了這個層次基本就是原始時代了，什么都沒有，一切都要手工完成。?
在這個層次上開發Web?Service，所有前面的困難都要一一經歷，此外，還有協議的開發等待著不幸至此的人們。?
到了這里，也不需要其它的工具了，JDK自帶的Socket可以保打天下。?

6?還想往下嗎？再往下就是操作系統的實現了，Java的平臺無關就失去了意義，也超出了我目前所了解的范圍，到此打住吧！?

前面所提及應該算是Web?Service的一個基本知識結構，這里并沒有討論UDDI等等的內容，一來我對它并不了解，二來那應該屬于應用，不應該算Web?Service實現中。?

雖然我們可能不會從最下層開發Web?Service，但遇到底層的問題的情況卻在所難免。?
我就曾經在開發一個Web?Service應用的時候，被人抓住HTTP頭中的SOAPAction大小寫與某個所謂的規范不同，我查了半天HTTP規范和SOAP規范，知道了HTTP是區分大小，而SOAPAction就是應該這么寫，據理力爭，指出所謂規范的錯誤。?

經過前面的討論，我們可以看出，Web?Service并沒有什么神秘可言，所有的東西都是建立在已有東西的基礎之上。技術的發展不會是無中生有，只會是一個更好的解決方案而已，在追新求變之前，一個比較牢固的基礎才是最重要

查看原文地址