问题四：庞然大物
还是先看一个例子，下面是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 }
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 }
这个方法接收一个Student数组，包含成百上千个Student，与上面例子不同的是Student和Teacher现在是多对一的单向关系，所以不会有“循环引用”的问题。假设所有这些Student的Teacher是一个人。我们试着将这个Student数组对象转换为一段XML，如下：
1 <student>
2 <teacher>
3 ...
4 </teacher>
5 </student>
6 <student>
7 <teacher>
8 ...
9 </teacher>
10 </student>
11 ...
2 <teacher>
3 ...
4 </teacher>
5 </student>
6 <student>
7 <teacher>
8 ...
9 </teacher>
10 </student>
11 ...
问题出来了，看到了没有，每个Student节点下面都有一个Teacher节点，当这段XML被接收方转换为Student数组时，每个学生都有了一个自己的老师，Teacher对象被复制了成百上千次，经过这么一个转换--传输--转换的过程，这个数组对象真的成了一个“庞然大物”。
问题的根源在于Student和Teacher之间的关系是多对一，当传送“多”方时，“一”方有可能会被复制多次。从而占用大量网络传输带宽和内存。在这里参数不一定非要是一个集合或者数组，例如ObjectA和ObjectB都有一个对ObjectC的引用，经过SOAP传送过后，ObjectC就由一个变成两个了，分别属于ObjectA和ObjectB，而不再是共享一个ObjectC了。
