...

Let's start with serializing: mapping from Java to XML. (JAXB calls this marshalling, and cannot decide how many 'l's to use in spelling it.) Given a Java object, Aegis looks to see if it has a mapping. By default, Aegis has a set of default mappings for the basic types defined in XML Schema, plus a few other special items. These mappings are implemented by Java classes, parts of Aegis, that can turn objects in to XML and vica versa. In particular, note that Aegis will map a DataSource or DataHandler to an MTOM attachment.

What if Aegis finds no mapping for a type? In the default configuration, Aegis invokes the type creators to create a mapping. Type creators use several mechanisms to create XML schema from Java objects. This include reflection, annotations, and XML type mappings files. As part of the mapping process, Aegis will assign a namespace URI based on the Java package. (Note: Aegis does not support elementForm='unqualified' at this time.) These mappings are implemented by a generic mapping class, and stored away.

...

Will it be in the mapping? Yes, because Aegis precreates mappings for the types in the service's parts. Aegis cannot dynamically create or choose a Java class based on XML schema, so the type creators cannot start from XML.

Using Java Classes That Aren't Visible to the Service Interface

Many web service programmers want to use types that are not directly
visible by reflection of the service interface. Here are some popular
examples of types that programmers want to use for property or
parameter types:

• Declare a base type, but transfer any one of a number of classes that extend it.
• Declare a raw Collection class, such as a Set, List, or Map, and send arbitrary objects as keys and values.
• Declare a base exception type for 'throws', and then throw other exception classes that derive from it.
• Declare an interface or an abstract type.

Aegis can handle all of these. For all except interfaces, there are
two mechanisms that involved: the root class list and xsi:type attributes.

As explained above, Aegis can write 'anything', but it can only read
objects of types that are mapped. You must give Aegis a list of all
the types that you want to use over and above those visible from the
service, and you must instruct Aegis to send xsi:type
attributes. These type attributes allow Aegis to identify the type of
these additional objects and look them up in the mappings.

Interfaces require one further step. Obviously, Aegis cannot
instantiate (run 'new') on an interface. So knowing that a particular
XML Schema type maps to an interface is not enough information. To be
able to read an XML element that corresponds to an interface, Aegis
must know a 'proxy class' that implements the interface. You must give
Aegis a mapping from interface types to proxy class names.

How does this work? The core of Aegis is the AegisContext class. Each
AegisDatabinding object has an AegisContext. (It is probably not
possible to share an AegisContext amongst databindings.)

By default, AegisDatabinding will create its own AegisContext with
default properties. To configure additional types, as well control
other options that we will examine later on, you must create the
AegisContext for yourself and specify some of its properties. Then you
pass your AegisContext object into your AegisDatabinding object.

To use additional classes or interfaces, you need to set two (or
three) properties of your AegisContext.

• rootClasses is a collection of Java Class<?> objects. These are
  added to the list of types known to Aegis. Aegis will create a
  mapping for each. For convenience, there is a rootClassNames property for use from Spring.

• writeXsiTypes is a boolean. Set it to true to send xsi:type attributes.

• beanImplementationMap is a mapping from Class<?> to class names.
  Use this to specify proxy classes for interfaces (or abstract classes).