XML to Java code data binding object


In the first part of this four part series, we will find out what data binding is, what its advantages over other methods of processing XML data in Java applications, and how to start using it. This section examines why data binding is used and how to model various constraints so that XML documents can be converted into Java objects. It also covers the inputs and outputs used to generate data binding classes.

Do you want to use XML in your Java applications? Well, get on this boat with thousands of others. When you dig deeper into XML, you may find that Dom and sax APIs (see resources) are just bluff. You might think there must be some simple way to get an XML document and access it through a Java application, right? Instead of using callbacks or complex tree structures, use methods like setowner (stringowner) and int getnumorders(), right? If you’ve ever thought along this line, data binding is the solution you’re looking for.

 Analyze options

With the proliferation of XML and xmlism today (XSL, RDF, namespace, RSS, XML schema, XSLT…), you might think there are many ways to access XML data in Java applications. Surprisingly, if you go to the bottom, there are only three ways to access XML data. That’s right — there are only three methods, one of which has recently emerged with a new Java API.

Look at it this way: the small range of choices makes it easier for you to choose the method that suits you.


Callbacks work as an event driven model. When parsing an XML document, certain events — such as the beginning of the document and the beginning of character data in an element — trigger the callback method. You can implement java code for these events by using the data required to execute the logic. To understand this method, we can’t rely entirely on intuition; It usually takes some time for developers to understand and master the use of callback model. Sax, a simple API for XML, is the de facto standard for this way of using XML.


More common and popular are APIs that take an XML document and create a tree structure of the data. The XML document becomes the head of the tree and acts as a container. It has several children, such as the root element. The root element has its additional children, and so on until (in a sense) a graph of XML data is obtained. Because almost every college student must have processed the tree structure at some stage, this can be used as a very intuitive way to represent XML data.

The most popular API for tree representation of XML documents is the W3C recommendation, document object model (DOM). An updated API, JDOM (which is not an acronym), has also been popularized and popular recently. (although this scheme was established by Jason hunter and I, I have to be honest.) in addition, DOM and JDOM are the basic requirements of spinnaker scheme design. Spinnaker is a new XML analyzer, which is being developed as a part of Apache XML scheme.

Although tree APIs seem easier to use than event driven Sax, they are not always appropriate. Very large documents may require a lot of memory (especially when using DOM); When performing transformation (XSLT) on the tree structure, the system may stop running or even crash completely. Although newer APIs such as JDOM can handle these problems, they will still be a problem if you have to deal with a very large amount of data. Moreover, sometimes developers prefer to model the data in XML documents as a simple java object with value reading and writing methods instead of working in a tree model. For example, developers would rather not access the child node named skunumber and set the text value of the node, but just call setskunumber (“mysku”) and continue.

The latest method of accessing XML data with java code depends on a new set of Java methods and related APIs, which are still under development. Data binding is a “Java specification requirement” (jsr-031, see resources) built by sun. It is designed to make it easier for Java objects to bind to XML documents, so that one format can be easily converted to another format, and vice versa. The binding refers to a Java object with read-write methods, which will affect the underlying XML document, and are directly mapped to the names of elements and features in the XML document. This explanation will be more meaningful when you move on to some details in the next part of this series, but for now, just one thing is enough: this enables the XML document feature name to change its value through a method called setname (), as I implied above.

Data binding

This access is gaining popularity and is particularly useful when storing configuration information in XML documents. Many developers find it very easy to directly access the required parameters without using a more complex tree structure. Although this access is not useful for document conversion or messaging, it is extremely convenient for simple data processing. It is the third approach to using XML that we focus on in this article and this series.

(of course, any method will lead to a series of new terms later, so please check the term explanation to understand these new jargon.)

Can any XML document be converted to Java objects? Or are only certain types of XML documents available? Good question! You probably only want to convert documents that meet a set of constraints into Java objects. This is similar to the way you define a java interface: you ensure that only the object appropriate to the interface is instantiated and used, allowing you to make assumptions about how to manipulate the object. Similarly, you are only allowed to convert XML objects that meet a set of constraints into Java objects; This enables you to use the objects you create in the way you want.

 Constraint data

Before studying the code, you need to answer a few questions about how to represent XML data. This is one of the most challenging aspects of data binding. Do you want to create a new class for each document or an instance of an existing class? Which existing class do you want to use? And most importantly, is the document you are working on suitable for conversion to Java objects?

That’s a lot of questions, but you’ll find all the answers here. These problems are regarded as a series of decision points and a series of choices. First, you must determine whether you can create Java objects from the XML document (as discussed earlier). If so, you decide whether the transformation should take the form of a new Java class or just an instance of an existing class. Finally, if you selected an existing class, which class would you use? The result is a variety of decision trees.

If we look at a sample XML document shown in Listing 1 and then deal with these issues, the meaning of the decision tree becomes clearer. This sample document represents the configuration of a service (specifically, a web container) in Enhydra application server.

Listing 1. An XML document for configuring the web container in Enhydra? xml version=”1.0″?>

  <webServiceConfiguration version=”1.0″ name=”My Web Container” >
  <port number=”80″ protocol=”http” protected=”false” />
  <document root=”/usr/local/enhydra/html” index=”*.html,*.xml” error=”error.html” />

This configuration document contains information about the version and name of the service itself, as well as several nested items, each representing some additional information about the web container service. It gives detailed information about ports (including port number, protocol and security), as well as document service information (including document root, default extension for index page and error page). All this, taken together, is all the information needed to configure a new web container service.

With this example in mind, you can start answering questions about the data representation.

Is it suitable for conversion?

Absolutely! Just look at the XML document in Listing 1 and you will see that it represents an object (the overall configuration object) with several features or variables. Some of these variables are other objects (ports and documents), which have their own characteristics. In fact, this is an excellent example of an XML document suitable for conversion to Java objects. To further ensure that this object is available, I’ll show you a way to constrain the data in the document later. However, let’s continue down the decision tree first.

Convert to class or instance?

After solving the suitability problem, you can now decide whether to turn each XML configuration document into a new Java class or simply into a new instance of an existing class. In other words, whether you should generate new code or use existing code. In this way, this becomes a simple reusability problem. It is easier and wiser to generate new instances of existing classes for each XML document. If you must try to create a new Java class from each document, there may be no compatibility between the resulting classes — that is, two identical documents may lead to two different Java classes!

Instead of this potentially confusing approach, you can take a set of XML constraints (represented by a DTD or XML schema, which will be described below) and generate a Java class (or classes, as needed) based on these constraints. The generated class will represent any XML document that meets these constraints; Each of these XML documents will be unpacked into an instance of the generated class. In this case, you can define constraints for the document that represents the web service configuration. These constraints will be mapped to a Java class, which we will call webserviceconfiguration. Then you can get any kind of XML document representing a specific web service configuration and create an instance of the previously generated class by assuming that the document meets our constraints. This will allow applications to use different XML documents as objects of the same type, as long as the data in these documents is valid for the purpose for which the object is designed.

New class or existing class?

Now you are also qualified to answer the next question: you want to create an existing class, an instance of the webserviceconfiguration class. All that’s left to figure out is how the class is pre generated. So now, please focus your attention on the question: how to obtain a set of constraints, implement them in XML, and ensure that the document complies with these constraints? Another question is, how can you generate a reusable Java class from these constraints?

Leverage document constraints

Now that you know that this document will be converted into a Java instance, another problem arises: consider that you must ensure that this document can be unpacked correctly into a selected Java class in some way. Missing variables or incorrect data types can cause errors during unpacking — or even run-time exceptions when clients access incorrectly configured containers.

At best, before the actual unpacking process begins, the author of the document can ensure that the configuration document is “legal” for the class they choose to represent the data. XML readers who read this scheme may turn their eyes and mutter, “well, of course, you will use XML document constraints.” confirming the legitimacy of the data to the selected class can be done by referring to DTD (document type definition) or XML scheme.

By using a set of constraints represented by external DTDs or schema files, document authors can test configuration data on the “interface” of these data. In other words, you can build an application so that it can check the data contained in the XML instance document against the required data, which is specified in the external file of the document constraints. This allows you to create an interface for the data.

Making a decision between using a DTD scheme or an XML scheme is a fairly simple choice: because the Java language is highly typed, we want to support typing in XML documents. For example, the data interface should be able to verify that the port number of the web container is provided as an integer rather than a string, which will cause an error when the service is started. DTD does not support type checking, so we should definitely choose XML schema. Although the XML scheme is somewhat uncertain in the field of specification, it has stabilized to a large extent and is expected to be finalized within the year. We can write data constraints in an XML scheme, and then use this scheme to verify possible instance documents to ensure that unpacking can be carried out on these instance documents. The following XML schema represents the data interface of our web container service.

Listing 2. XML scheme representing the data interface of a web container configuration document? xml version=”1.0″?>

  <schema targetNamespace=”http://www.enhydra.org” xmlns=”http://www.w3.org/1999/xmlSchema” xmlns:enhydra=”http://www.enhydra.org” >

  <complexType name=”ServiceConfiguration”>
  <attribute name=”name” type=”string” />
  <attribute name=”version” type=”float” />

  <element name=”serviceConfiguration” type=”ServiceConfiguration” />

  <complexType name=”WebServiceConfiguration” baseType=”ServiceConfiguration” derivedBy=”extension”>
  <element name=”port”>
  <attribute name=”protocol” type=”string” />
  <attribute name=”number” type=”integer” />
  <attribute name=”protected” type=”string” />

  <element name=”document”>
  <attribute name=”root” type=”string” />
  <attribute name=”index” type=”string” />
  <attribute name=”error” type=”string” />

  <element name=”webServiceConfiguration” type=”WebServiceConfiguration” />


The XML Schema in Listing 2 defines several different data objects that together represent the configuration object of a web service. First, a core service configuration is defined, which contains the version and name. This can be used as the basic object for all services, such as load balancing services, EJB containers, and, of course, our web services. Then, as an extension of this basic service, web service configuration is defined. Note that after Java is formed, the solution has modeled the data interface. We add the additional web service attributes port and document to the version and name base attributes. These attributes themselves are objects with their own attributes (protocol, root, error, etc.).

In the way this scenario is defined, features represent simple java types, usually primitive types. In this way, name and version become the Java primitive types of string and float, respectively. Elements such as port and document become Java objects. They can have their own attributes or be represented by features. This leads to recursion: the element becomes a new object and each of its attributes is checked. If the attribute is a feature, create a simple java primitive member variable for this object; If the attribute is an element, create a new object and add it as a member variable, and then start the same process on the new object until all classes have been created.
Get Java from radish… Um… XML

Once the XML schema is created, you need to extract the necessary information from the schema to determine which Java classes should be created. The first step in this process is to look at the XML schema and strictly determine what the output should be. For a simple serviceconfiguration object, two Java primitive properties are defined: name and version. For such a simple object, it is not difficult to determine the required interface. Just capitalize the first letter of the name of the defined type and add these Java attributes to the interface, as shown in Listing 3.

Listing 3. Java code generated from XML schema for serviceconfiguration interface public interface

  ServiceConfiguration {
  public void setVersion(float version);
  public float getVersion();
  public void setName(String name);
  public String getName();

This is quite easy to understand; The interface in Listing 3 provides read and write methods for the attributes defined in the XML schema. In addition, you will need to generate an implementation class to define each member variable of the interface and implement each method in the interface. This method of separating interfaces from implementations enables us to provide multiple implementations for specific needs. For example, a particular service may need to perform calculations rather than just accept the values received from the write method. It’s too early to consider that more complex situation, but I’ll revisit it in a subsequent article. In general, however, you can still determine what the implementation class should look like, as shown in Listing 4.

Listing 4. Java code public class generated from XML schema for serviceconfiguration implementation

  ServiceConfigurationImpl implements ServiceConfiguration {
  private String name;
  private float version;

  public void setVersion(float version) {
  this.version = version;

  public float getVersion() {
  return version;

  public void setName(String name) {
  this.name = name;

  public String getName() {
  return name;

The same principle applies to other objects defined in the XML schema. You can see other Java classes below (because they should be generated):



By now, you should be familiar with all aspects of data binding. I’ve outlined the reasons why you should use data binding, especially in the context of configuration information, and outlined some basic concepts you need to know to implement this approach.

Recommended Today

Application of observer pattern in design pattern in Ruby Programming

Observer mode(sometimes referred to as publish / subscribe mode) is softwareDesign patternA kind of.In this mode, a target object manages all its dependent observer objects and actively notifies when its own state changes.This is usually achieved by calling the methods provided by each observer. When implementing the observer mode, it should be noted that the […]