This section describes the components and interactions in the JAXB processing model.
Figure 17–1 shows the components that make up a JAXB implementation.
A JAXB implementation consists of the following architectural components:
Binding runtime framework: Provides unmarshalling (reading) and marshalling (writing) operations for accessing, manipulating, and validating XML content using either schema-derived or existing program elements.
Figure 17–2 shows what occurs during the JAXB binding process.
The general steps in the JAXB data binding process are:
Generate classes: An XML schema is used as input to the JAXB binding compiler to generate JAXB classes based on that schema.
Compile classes: All of the generated classes, source files, and application code must be compiled.
Unmarshal: XML documents written according to the constraints in the source schema are unmarshalled by the JAXB binding framework. Note that JAXB also supports unmarshalling XML data from sources other than files/documents, such as DOM nodes, string buffers, SAX Sources, and so forth.
Generate content tree: The unmarshalling process generates a content tree of data objects instantiated from the generated JAXB classes; this content tree represents the structure and content of the source XML documents.
Validate (optional): The unmarshalling process optionally involves validation of the source XML documents before generating the content tree. Note that if you modify the content tree in Step 6, below, you can also use the JAXB Validate operation to validate the changes before marshalling the content back to an XML document.
Process content: The client application can modify the XML data represented by the Java content tree by means of interfaces generated by the binding compiler.
Marshal: The processed content tree is marshalled out to one or more XML output documents. The content may be validated before marshalling.
Unmarshalling provides a client application the ability to convert XML data into JAXB-derived Java objects.
Marshalling provides a client application the ability to convert a JAXB-derived Java object tree back into XML data.
By default, the Marshaller uses UTF-8 encoding when generating XML data.
Client applications are not required to validate the Java content tree before marshalling. There is also no requirement that the Java content tree be valid with respect to its original schema to marshal it back into XML data.
Validation is the process of verifying that an XML document meets all the constraints expressed in the schema. JAXB 1.0 provided validation at unmarshal time and also enabled on-demand validation on a JAXB content tree. JAXB 2.0 only allows validation at unmarshal and marshal time. A web service processing model is to be lax in reading in data and strict on writing it out. To meet that model, validation was added to marshal time so one could confirm that they did not invalidate the XML document when modifying the document in JAXB form.