詳解WebService開發(fā)中四個(gè)常見問題

作者：AndyHan 2009-04-01 16:46:31

WebService開發(fā)中經(jīng)常會(huì)碰到諸如WebService與方法重載、循環(huán)引用、數(shù)據(jù)被穿該等等問題。本文會(huì)給大家一些很好的解決方法。

任何問題都需要從它的根源說起，所以簡(jiǎn)單說一下WebService的工作原理。客戶端調(diào)用一個(gè)WebService的方法，首先需要將方法名和需要傳遞的參數(shù)包裝成XML(也就是SOAP包)，通常是通過HTTP傳遞到服務(wù)器端，然后服務(wù)器端解析這段XML，得到被調(diào)用方法名稱和傳遞來的參數(shù)，進(jìn)而調(diào)用WebService實(shí)例的相應(yīng)方法。方法執(zhí)行完成之后，將返回的結(jié)果再包裝成XML(SOAP響應(yīng))發(fā)送到客戶端，客戶端解析這段XML，進(jìn)而得到返回結(jié)果。這里關(guān)鍵的地方在于中間加入了對(duì)象和XML相互轉(zhuǎn)換的過程。

問題一：WebService與方法重載

首先說明，WebService不支持方法重載。下面舉例說明。

例如定義如下WebService接口：

1 @WebService
2 public interface IHello {
3         @WebMethod
4         public String sayHello(int id);
5 
6         @WebMethod
7         public String sayHello(String name);
8         
9         @WebMethod
10         public String sayHello2(int id);
11 
12         @WebMethod
13         public String sayHello2(int id, String name);
14     }

先來看方法sayHello()，如果客戶端發(fā)送如下SOAP請(qǐng)求：

1 <soap:Envelope>
2         <soap:Body>
3             <sayHello>
4                 <arg0>11</arg0>
5             </sayHello>
6         </soap:Body>
7     </soap:Envelope>

從SOAP請(qǐng)求我們可以看出客戶端需要調(diào)用方法為sayHello()，所傳遞的參數(shù)為11，但是無法知道是整數(shù)的11，還是字符串"11"，所以也就無法確定所調(diào)用的方法是哪一個(gè)。

接下來看一下sayHello2()，如果客戶端傳遞的參數(shù)只包括一個(gè)id值，例如：

1 <soap:Envelope>
2         <soap:Body>
3             <sayHello2>
4                 <arg0>1</arg0>
5             </sayHello2>
6         </soap:Body>
7     </soap:Envelope>

還是無法判斷調(diào)用的是哪個(gè)方法，因?yàn)榭梢岳斫鉃榭蛻舳藗鬟f的第二個(gè)參數(shù)為空(Null)。

通常情況下，在發(fā)布一個(gè)含有重載方法的WebService時(shí)會(huì)有異常發(fā)生，或者當(dāng)調(diào)用一個(gè)方法時(shí)，服務(wù)器端報(bào)告找不到相對(duì)應(yīng)的方法。

問題二：我的數(shù)據(jù)被修改了?

先來看WebService接口：

1 @WebService
2     public interface IHello {
3     
4         @WebMethod
5         public String sayHello(IPerson person);
6     
7     }
8     
9     public interface IPerson {
10         ...
11     }
12     
13     public class Person implements IPerson{
14         ...
15     }

這里需要注意的是WebService的方法sayHello()的參數(shù)是一個(gè)接口，而不是一個(gè)具體類(例如Aegis綁定就允許直接發(fā)布這樣的WebService)。在客戶端調(diào)用sayHello()的時(shí)候傳遞一個(gè)Person對(duì)象，它實(shí)現(xiàn)了IPerson接口。經(jīng)過中間一系列的XML和對(duì)象之間的轉(zhuǎn)換過程，服務(wù)器端得到的只是一個(gè)實(shí)現(xiàn)了IPerson接口的實(shí)例，它不一定就是一個(gè)Person對(duì)象，如果要強(qiáng)制將其轉(zhuǎn)換為Person，就有可能拋出異常。

問題的根源在于Aegis將XML轉(zhuǎn)換為Java對(duì)象是通過Proxy或CGlib這類的工具生成一個(gè)“代理類”實(shí)現(xiàn)IPerson接口，然后創(chuàng)建這個(gè)代理類的一個(gè)實(shí)例，那它肯定不是一個(gè)Person了。

#p#

問題三：循環(huán)引用

還是先來看一個(gè)例子。下面是WebService的接口：

1 @WebService
2     public interface IHello {
3     
4         @WebMethod
5         public String sayHello(Teacher teacher);
6     
7     }
8     
9     public class Teacher {
10         private Student[] students;
11         
12         //getters and setters
13         ...
14     }
15     
16     public class Student {
17         private Teacher teacher;
18         
19         //getters and setters
20         ...
21     }

請(qǐng)注意，Teacher和Student是一對(duì)多的“雙向”關(guān)系。在這種情況下，我們可以想一下如何將一個(gè)Teacher對(duì)象轉(zhuǎn)換成一段XML?

您可能想到下面的答案：

1 <teacher>
2         <students>
3             <teacher>
4                 <students>
5                     <teacher>
6                         <students>
7                             ...
8                         </students>
9                         ...
10                     </teacher>
11                 </students>
12                 ...
13             </teacher>
14         </students>
15         
16         <students>
17             ...
18         </students>
19         ...
20     </teacher>

看到了吧，XML竟然也會(huì)進(jìn)入“死循環(huán)”。問題的根源在于對(duì)象之間的循環(huán)引用。這種問題通常在客戶端發(fā)送WebService請(qǐng)求之前就會(huì)拋出異常，因?yàn)闊o法將這個(gè)對(duì)象轉(zhuǎn)換為可傳輸?shù)腦ML。

問題四：龐然大物

還是先看一個(gè)例子，下面是WebService的接口：

1 @WebService
2     public interface IHello {
3     
4         @WebMethod
5         public String sayHello(Student[] students);
6     
7     }
8     
9     public class Teacher {
10         ...
11     }
12     
13     public class Student {
14         private Teacher teacher;
15         
16         //getters and setters
17         ...
18     }

這個(gè)方法接收一個(gè)Student數(shù)組，包含成百上千個(gè)Student，與上面例子不同的是Student和Teacher現(xiàn)在是多對(duì)一的單向關(guān)系，所以不會(huì)有“循環(huán)引用”的問題。假設(shè)所有這些Student的Teacher是一個(gè)人。我們?cè)囍鴮⑦@個(gè)Student數(shù)組對(duì)象轉(zhuǎn)換為一段XML，如下：

1 <student>
2     <teacher>
3                 ...
4         </teacher>
5     </student>
6 <student>
7     <teacher>
8                 ...
9         </teacher>
10     </student>
11     ...

問題出來了，看到了沒有，每個(gè)Student節(jié)點(diǎn)下面都有一個(gè)Teacher節(jié)點(diǎn)，當(dāng)這段XML被接收方轉(zhuǎn)換為Student數(shù)組時(shí)，每個(gè)學(xué)生都有了一個(gè)自己的老師，Teacher對(duì)象被復(fù)制了成百上千次，經(jīng)過這么一個(gè)轉(zhuǎn)換--傳輸--轉(zhuǎn)換的過程，這個(gè)數(shù)組對(duì)象真的成了一個(gè)“龐然大物”。

問題的根源在于Student和Teacher之間的關(guān)系是多對(duì)一，當(dāng)傳送“多”方時(shí)，“一”方有可能會(huì)被復(fù)制多次。從而占用大量網(wǎng)絡(luò)傳輸帶寬和內(nèi)存。在這里參數(shù)不一定非要是一個(gè)集合或者數(shù)組，例如ObjectA和ObjectB都有一個(gè)對(duì)ObjectC的引用，經(jīng)過SOAP傳送過后，ObjectC就由一個(gè)變成兩個(gè)了，分別屬于ObjectA和ObjectB，而不再是共享一個(gè)ObjectC了。

【編輯推薦】