這兩個禮拜花了不少時間在學習WebService這項技術。
我嚐試了兩種不同的伺服器，一個是Sun的Tomcat，另外
一個是Oracle的OC4J，花了不少時間，看了兩者的不同的
規格，也試了兩者所提供的範例程式，我有一個很強烈的感覺
是，WebService這項技術確實很熱，未來也很有潛力，但是
現在如果要進入這個市場，是相當痛苦的一件事情!
        為什麼呢？我們先來了解一下WebService這個技術。很粗淺
的講法，可以把WebService當成是 "透過一隻CGI或SSI程式，
把伺服器上的物件提供給客戶端使用" 這樣的技術。如果有
使用過一些分散式物件的人就會知道，傳統的分散式物件技術，
例如RMI等等，很大的一個困擾是防火牆的問題，因為這些分散式
物件的技術，底下往往是利用一般的Socket連線，走特殊的協定，
通常這些協定一碰到防火牆就會被擋回來了。但是WebService
沒有這個問題，因為基本上它使用的協定是HTTP，這種協定通常
不會被防火牆擋。WebService就是將request和response寫成xml的格式，
再利用SOAP這種技術把xml包裹成HTTP的型式來傳送。
        Ok，問題來了。將xml利用SOAP來包裹，然後在送到物件或傳回到
客戶端的時候進行解析，這部分並沒有很強制的規格。雖然說xml
的解析有很多函式庫可以做，SOAP的格式也已經由W3C制定，如果
要自己從頭作所有的工作是沒有問題的，但相信沒有人會這樣做，於是乎，
這一整套東西到底要怎麼包起來就有許多種不同的實作方式。在Sun
方面，推出了一套Java Web Service Developer Pack，這裡面的實作使用
Jax-Rpc，這是一個將傳統RPC使用xml包裹的函式庫，Tomcat是採用
這種型式，而且Jax-Rpc是Sun的整套xml函式庫的一部份，看樣子會是
Sun要大力推動的。
        可是，現在市面上並非沒有其他的solution，像Borland的application server，
使用的是Apache的AXIS這個函式庫，而Oracle的OC4J server雖然沒有明講，
但可以看得出來絕對不是使用Jax-Rpc。由於選擇方式的不同，將WebService
的物件發布到server上的方法會完全不一樣。就我個人試用的結果，感覺上
Tomcat那一套太過複雜了，雖然Sun有提供一套叫做xrpcc的工具，但是
使用起來必須個別產生許多不同的設定檔，然後再設法包裹成.war的型態
來發布，有點麻煩。而Borland的application server則是跟Borland的JBuilder
綁得太緊了，從JBuilder來發布是很方便沒錯，但也因此減少了彈性。OC4J
的做法好像比較好，它是讓使用者將所有物件包裹成.ear的標準格式，只要寫
一份設定檔就好，然後按照一般發布EJB的方法來把.ear檔案發布到OC4J上面，
其他的設定檔和給客戶端使用的stub等等，OC4J會自行產生，這樣似乎是
比較省力，而又夠彈性的做法，因為.ear格式是標準的J2EE的發布格式。
        只是，由於大家的發布方式都不一樣，難免會有相容性的問題，而目前
幾乎沒有看到production level的伺服器使用Jax-Rpc這個規格，所以WebService
現在雖然很熱，但要真的能夠實用，要夠穩定，恐怕還要一段時間。而
工程師們就有得辛苦了，如果老闆今天突然想換應用程式伺服器，那肯定是
一個頭兩個大了。