axis 传输 简单对象，复杂对象，List，Map等收藏

axis 传输 简单对象，复杂对象，List，Map等收藏

那些java的对象是可以序列化为xml的， 并且可以从xml反序列化为java对象的？
那些对象与xml之间不能够序列化和反序列化？
在开发的时候应该注意哪些问题？

根据我的理解， 有如下几种对象：
1）axis1.2内在支持的几种对象类型。
          这几种内在支持的对象包括：
          java基本类型 : int, float,,,,
          基本类型包装类 : Integer, Float, Long...
          还有String, Date, Calendar, BigDecimal, BigInteger, List, Map.
     凡是这些内在支持的对象， 不管他们作为某个Service的input 还是 output, 我们在服务端的axis1.2的WEB-INF/server-config.wsdd的该Service的定义中都不需要加入 或者是的声明。

2）简单的javabean对象类型。
       对于简单的javabean对象， 比如对象中所有的field都是上面提到的基本类型。 axis1.2也提供了很好的支持。
       比如：
       public class JavaBeanInputService { 
           public void testJavaBeanInput(MyBean bean) {
               ......
          }
       }
         由于MyBean是一个自定义的JavaBean对象， 所以在server-config.wsdd中就必须加上的声明， 让axis知道怎么把request中xml数据deserialize为MyBean对象，又如何把MyBean对象serialize为xml数据作为response.用wtp自动为JavaInputService生成的wsdl中， MyBean是作为一个complexType在wsdl中定义的。

3）复杂一点的JavaBean对象。
        比如JavaBean对象中的一些field又是自定义的JavaBean,  这种情况下， wsdl中生成的complextype会有多个，而在wsdd定义的也会有多个， axis1.2支持起来都是易如反掌。

4）普通的非javabean对象。
      对于一些不是javaBean的对象， wtp也会替你生成对应的wsdl的ComplexType, 依据的是对象的getter方法。但是显然这是不够的。 比如说有些对象的数据结构比较复杂，像java.util.HashMap(虽然这个已经被axis内在支持了。)这些对象如果想要把自己的状态进行serialization和 deserialization， 就得自己编写serializer和deserializer,  而且还必须保证wsdl中的该complexType的描述是正确的。

5）java中的List, Map问题。
       试想一下如果一个service的样子是这样子的。

       public class ListService{
             public List listTest(List list) {
                    for(Iterator iter = list.iterator(); iter.hasNext(); ) {
                           (MyBean)list.next();//进行强转。
                    }
              }
       }
        用wtp为这个service生成的wsdl中把list映射为一个type为xsd:anyType的maxOccurs="unbound"的complexType。这样的话客户端生成的Stub中的接口中类似于:
        public interface ListService{
             public Object[] listTest(Object[] list) ;
        }
        如果Client端用户传递的入口参数是String[]，那么在服务端执行的必然会发生转型错误。
        因此，在webservice中把List, Map作为service的input, output的做法都是不可行的。至少在jdk1.4的版本中是这样的。
        一个更好的方法就是:

6）java中的数组。
      上例中的ListService如果改造为下面这样，基本上就没有上面提到的问题了。
      public class ListService{
             public MyBean[] listTest(MyBean[] list) {
                   ...
             }
       }
        这样在wsdl中， MyBean被映射为一种ComplexType，MyBean[]为映射为ComplexType为映射为可以重复出现的MyBean类型。在客户端的 Stub的接口跟这个也是类似的。从而也成功地避免了List, Map中型别问题。

       要注意的是，在server-config.wsdd中需要配置
       似乎List, Map的问题用数组就可以解决了。事实上就是如此。但是还得注意的是：
　　 javabean里边也不能含有List. 如果MyBean跟其它某个对象是1：n的关系，那么也只能写成数组的形式，而不能是List的形式。

7）特殊对象java.lang.Object
       如果一个service写成了下面的形式：
       public class ObjectService{
             public Object objInvoke(Object obj) {
                   ...
             }
       }
        想把它发布为web service, 那么几乎是不太可能的。遇到obj类型，wsdl里边只能定义为xsd:anyType类型，而这种类型如果给客户端返回一个比如MyBean类型，那么必然会导致xml的serialization的失败。结论就是：

 

         web service中如果input 或者是output是java.lang.Object类型，那么将会导致严重问题。
        
        上面的几种对象类型基本上能够涵盖将java class发布为web service时需要考虑的对象类型。可以看到开发web service的时候，并不是所有的java都能够轻而易举地发布为web service, 一些复杂的类的对象类型，还有一些特殊的对象类型都是要考虑的。最后一个问题是：子类是否也很容易的得到序列化和反序列化？
         答案是肯定的。如下的Service:
          public class PolymorphicService{
             public MyBean objInvoke(MyBean obj) {
                   ...
             }
         }
          客户端的Stub如下:
          public class PolymorphicServiceStub{
             public MyBean objInvoke(MyBean obj) {

                   ...
             }
         }
         如果在客户端调用stub时传入的不是MyBean类的对象，而是它的子类的一个对象，那么也可以被序列化而传到服务端。同样，如果服务端返回的对象是MyBean类的字类的一个对象，也可以成功的被序列化到客户端。