WebService開發的層次

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

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