Axis transfers simple objects, complex objects, List, Map, and other favorites

Axis transfers simple objects, complex objects, List, Map, and other favorites
Source: http://yangzb.javaeye.com/blog/319900

Which java objects can be serialized into xml and deserialized from xml to java objects?
Which objects cannot be serialized or deserialized with xml?
What issues should I pay attention to during development?

According to my understanding, there are several objects:
1) axis1.2 supports several object types.
The following objects are supported:
Java basic types: int, float ,,,,
Basic type packaging class: Integer, Float, Long...
There are also String, Date, Calendar, BigDecimal, BigInteger, List, Map.
All these internally supported objects, whether they are input or output of a Service, we do not need to add the declaration of <beanMapping> or <typeMapping> in the definition of the Service in the WEB-INF/server-config.wsdd of axis1.2 on the server side.

2) Simple javabean object type.
For simple javabean objects, for example, all fields in the objects are the basic types mentioned above. Axis1.2 also provides good support.
For example:
Public class JavaBeanInputService {
Public void testJavaBeanInput (MyBean bean ){
......
}
}
Since MyBean is a custom JavaBean object, you must add <beanMapping ..... /> declaration, let axis know how to set the xml data deserialize in the request as the MyBean object, and how to use the MyBean object serialize as the xml data as the response. in the wsdl automatically generated for JavaInputService using wtp, MyBean is defined in the wsdl as a complexType.

3) a more complex JavaBean object.
For example, some fields in the JavaBean object are custom JavaBean. In this case, multiple complextypes are generated in the WSDL, And the <beanmapping... /> there will also be multiple, and axis1.2 is easy to support.

4) A common non-JavaBean object.
For some objects that are not JavaBean, WTP will also generate the corresponding WSDL complextype for you based on the object's getter method. But obviously this is not enough. For example, some objects have complex data structures, such as Java. util. hashmap (although this is already supported by Axis internally .) If you want to perform serialization and deserialization on these objects, you have to write serializer and deserializer on your own, and ensure that the complextype description in the WSDL is correct.

5) List and map problems in Java.
Imagine if a service looks like this.

Public class listservice {
Public list listtest (list ){
For (iterator iter = List. iterator (); ITER. hasnext ();){
(Mybean) List. Next (); // perform forced conversion.
}
}
}
In the WSDL generated for this service using WTP, the list is mapped to a complextype of maxoccurs = "Unbound" whose type is XSD: anytype. In this case, the interfaces in the stub generated by the client are similar:
Public interface listservice {
Public Object [] listTest (Object [] list );
}
If the input parameter passed by the Client user is String [], a transformation error will inevitably occur on the server.
Therefore, using List and Map as service input in webservice is not feasible. At least in jdk1.4.
A better method is:

6) arrays in java.
In the above example, if the ListService is transformed to the following, basically there is no problem mentioned above.
Public class ListService {
Public MyBean [] listTest (MyBean [] list ){
...
}
}
In this way, in wsdl, MyBean is mapped to a ComplexType, and MyBean [] is mapped to ComplexType to a repeated MyBean type. The Stub interface on the client is similar to this one. In this way, the List and Map tasks are successfully avoided.

Note that you need to configure <arrayMapping.../> In the server-config.wsdd
It seems that the problem of List and Map can be solved by array. This is actually the case. However, you must note that:
Javabean cannot contain a List. If MyBean has a 1: n relationship with another object, it can only be written as an array instead of a List.

7) special Object java. lang. Object
If a service is written in the following format:
Public class ObjectService {
Public Object objInvoke (Object obj ){
...
}
}
It is almost impossible to publish it as a web service. In case of the obj type, the wsdl can only be defined as the xsd: anyType type. If this type is returned to the client, for example, the MyBean type, it will inevitably lead to xml serialization failure. The conclusion is:

In web service, if the input or output type is java. lang. Object, it will cause serious problems.

The above object types can basically cover the object types that need to be considered when java class is published as web service. We can see that when developing web Services, not all java can be easily published as web services, some complex class object types, there are also some special object types to consider. The last question is: Can subclass be easily serialized or deserialized?
The answer is yes. The following Service:
Public class PolymorphicService {
Public MyBean objInvoke (MyBean obj ){
...
}
}
The Stub of the client is as follows:
Public class PolymorphicServiceStub {
Public MyBean objInvoke (MyBean obj ){
...
}
}
If the object passed in when the client calls stub is not the object of the MyBean class, but an object of its subclass, it can also be serialized and uploaded to the server. Similarly, if the object returned by the server is an object of the word class of the MyBean class, it can be successfully serialized to the client.