JAX-RPC Supported Java Types

JAX-RPC supports only a subset of Java types, because the data types transmitted by the remote procedure calls must map to XML data types. When a Web service receives a remote method call from its client, the JAX-RPC runtime service environment first transforms the XML representation of the call inputs to its corresponding Java type (this process also is known as deserialization), then passes the Java object to the service implementation to process the remote call. After the call is processed, the JAX-RPC runtime service environment transforms the return object to its XML representation (this process is also known as serialization), the XML representation of the return object is then sent back to the service client. This derialization/deserialization process happens to both client and service. Thus, the values of a JAX-RPC supported Java type must be serializable to and from the corresponding XML representation.

The mechanism used to change the objects into a format that can be transmitted over the network is called marshalling, and reconstructing the objects from this format is called unmarshalling. Marshalling over the wire requires object state to be extracted and sent in a well-defined format. Unmarshalling requires that the format be known, for reconstruction to take place. To marshal and unmarshal successfully, both sides in the exchange must use the same protocol to encode and decode object structure and data.

Java-to-XML Marshalling

While JAX-RPC does not define the actual marshalling mechanism, it does define the input and output types that result from that marshalling. Vendors write the marshalling code as part of their implementations. In JAX-RPC, marshalling is different from the standard Java serialization mechanism, where all nontransient fields in the class are automatically serialized.

JAX-RPC defines a standard set of Java types as method arguments and return types, meaning that a JAX-RPC—compliant system will provide the ready-to-use serializers and deserializers for these types:

• JAX-RPC supports all Java primitive types and their corresponding wrapper classes:
  
  

  Primitive Type/Wrapper Class	XML Element
  boolean/Boolean	xsd:boolen/soapenc:boolean
  byte/Byte	xsd:byte/soapenc:byte
  double/Double	xsd:double/soapenc:double
  float/Float	xsd:float/soapenc:float>
  int/Integer	xsd:int/soapenc:int
  long/Long	xsd:long/soapenc:long
  short/Short	xsd:short/soapenc:short

  
  

  You may note that the primitive type char is not here. A char is treated as a String, since XML schemas have no char type primitive.

• JAX-RPC supports a subset of standard Java classes:
  
  

  Standard Java Class	XML Element
  java.lang.String	xsd:string
  java.util.Date	xsd:dateTime
  java.util.Calendar	xsd:dateTime
  java.math.BigInteger	xsd:integer
  java.math.BigDecimal	xsd:decimal
  javax.xml.namespace.Qname
  java.net.URI
  Classes in the Java Collection Framework that are mapped using pluggable serializers and deserializers.

  
  

• JAX-RPC Value Types:
  
  

  Basically, a Java object whose state can be moved between a service client and service endpoint.

• A Java class must follow these rules to be a JAX-RPC conformant value type:
• Class must have a public default constructor (no-argument constructor).
• Class must not implement (directly or indirectly) the java.rmi.Remote interface.
• Class may implement any Java interface (except java.rmi.Remote interface) or extend another Java class.
• Class may contain public, private, or protected information. Fields must be supported JAX-RPC data.
• Class must follow the JavaBeans set and get method design pattern.
• Class may contain static or transient fields.
• Class for a JAX-RPC value type may be designed as a JavaBeans class with simple properties.

• Finally, Java arrays also can be used in JAX-RPC, provided that the type of the array is one of the JAX-RPC suuported types. JAX-RPC also supports multi-dimensional arrays.