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并沒有什么神秘可言，所有的東西都是建立在已有東西的基礎之上。技術的發展不會是無中生有，只會是一個更好的解決方案而已，在追新求變之前，一個比較牢固的基礎才是最重要