One of the data bindings from XML to Java code

xml| data objects, objects everywhere

In the first part of this four-part series, we'll figure out what data binding is, and what the advantages are, and how to start using it, compared to other methods of processing XML data in a Java application. This section examines why data binding is used and how constraints are modeled to allow XML documents to 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 application? So good, go aboard this boat with thousands of others. As you delve into XML, you may find that the DOM and SAX APIs (see Resources) are nothing but bluffing. 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 a callback or a complex tree structure, you use a method like SetOwner (stringowner) and int getnumorders (), right? If you've ever considered a problem along this line of thought, data binding is the solution you're looking for.

　　 Analyze various options

Today all kinds of XML and XML are rampant (XSL, RDF, namespaces, RSS, XML Schema, XSLT ...). , you might think there are many ways to access XML data in Java applications now. Surprisingly, there are only three ways to access XML data, if you're really curious. Yes-there are only three methods, one of which appears recently with a new Java API.

This should be the case: a small selection makes it easier to choose the right approach for you.

Callback

Callbacks work as an event-driven model. When parsing an XML document, some events-such as the start of the document and the start of character data in an element-trigger the callback method. You can implement the Java code for these events by using the data needed to perform the logic. It is not intuitive to understand this approach; it often takes a developer a while to comprehend and master the use of the callback model. SAX, a simple API for XML, is the de facto standard for this method of XML usage.

Tree

More common and popular is the API, which gets an XML document and then creates the tree structure of the data. The XML document becomes the tree Head 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 you (in a sense) get a picture of the XML data. Since almost every college student has worked on a tree structure at some stage, this can be used as a very intuitive way of representing XML data.

The most popular API for the tree representation of XML documents is the recommended standard for the consortium, the Document Object Model (DOM). An updated api,jdom (which is not an acronym) has recently been popularized and popular. (although this project was built by me and Jason Hunter, I have to tell the truth.) In addition, DOM and JDOM are basic requirements for Spinnaker scenario design, Spinnaker is a new XML parser that is being developed as part of the Apache XML solution.

Although the tree-like APIs appear to be easier to use than event-driven SAX, they are not always appropriate. Very large documents may require a large amount of memory (especially when using DOM), and when a transformation (XSLT) is performed on a 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 extremely large amounts of data. Also, sometimes developers prefer to model the data in an XML document as a simple Java object with a read-write method with a value instead of a tree-like model. For example, a developer would prefer not to access a child node named Skunumber and set the text value of that node, but only to invoke Setskunumber ("Mysku") and continue.

　

　 Terminology Interpretation

Data binding: A new way to access XML data from within a Java application, using a api,jsr-031 that is still under development.

A new Java specification request that Jsr-031:sun is still developing is designed to compile XML documents into one or more Java classes, and these Java classes are easy to use in Java applications.

Packaging: Converts a Java object to an XML representation with the current value.

Unpack: Creates a Java object from an XML object, usually a Java object based on packaging.

　

The latest approach to

accessing XML data in Java code relies on a new set of Java methods and associated APIs, which are still under development. Data binding is a "Java specification requirement" built by Sun (JSR-031, see Resources) 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. A binding refers to a Java object with a read-write method that affects the underlying XML document and is mapped directly to the element and the name of the feature in the XML document. When you enter some of the details in the next section of this series of articles, this statement makes more sense, but at the moment, suffice it to say that this allows the XML document feature name to change its value through a method called SetName (), as I indicated above.

Data Binding

This access is being popularized and is especially useful when storing configuration information in an XML document. Many developers find it very easy to access the required parameters directly, 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 that we are interested in using XML in this article and in this series of articles.

(Of course, any method will then elicit a new set of terms, so look at the terminology explanations to understand the new jargon.)

can any XML document be converted to a Java object? Or are there only certain types of XML documents? Good question! You will most likely want to convert a document that satisfies a set of constraints to a Java object. This is similar to the method that defines the Java interface: you ensure that only objects that are adapted to the interface are instantiated and used, allowing assumptions about how to manipulate the object. Similarly, you only allow XML objects that meet a set of constraints to be converted to Java objects, which enables you to use the objects you create in the way you want.

　　Constraint Data

Before you look at 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. Create a new class for each document, or create 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. Consider these issues as a series of decision points, a series of choices. First, you must determine whether you can create Java objects from the XML document (as discussed earlier). If you can, decide whether the conversion should occur as a new Java class or just as an instance of an existing class. Finally, if you chose an existing class, which class would you like to use? The result is a variety of decision trees.

If we look at one of the sample XML documents shown in Listing 1 and then deal with these issues, the decision tree is more clear. This sample document represents the configuration of a service (specifically, a Web container) in Enhydra application Server.


Listing 1. An XML document to configure the Web container in Enhydra

This configuration document contains information about the version and name of the service itself, as well as several nested projects, each representing some additional information about the Web container service. It gives details about the port (including port number, protocol, and Security), as well as document service information (including the document root, the default extension for index pages, and the error page). All of this together is all the information you need to configure a new Web container service.

With this example in mind, you can begin to answer the various questions that the data represents.

Is it suitable for conversion?

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

Convert to class or instance?

After addressing the suitability issue, it is now time to decide whether to change each XML configuration document into a new Java class, or simply to change it to a newer instance of an existing class. In other words, whether the new code should be generated or the existing code should be used. In this way, this becomes a simple reusability problem. It is easier and wiser to generate a new instance of an existing class for each XML document. If you must try to create a new Java class from each document, the resulting classes may not be compatible--that is, two identical documents can result in two different Java classes!

Without this potentially confusing method, you can take a set of XML constraints (represented by a DTD or XML schema that will be described below) and generate a Java class (or classes, as needed) based on those constraints. This generated class will represent any XML document that conforms to these constraints, and each of these XML documents will be extracted 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. You can then obtain any XML document that represents a specific Web service configuration, and assume that the document conforms to our constraints by creating an instance of the previously generated class. This allows applications to use different XML documents as objects of the same type, as long as the data in those documents is valid for the purpose of the object's design.

New class or existing class?

Now you have the conditions to answer the next question: you want to create an existing class, an instance of the Webserviceconfiguration class. All that remains to be clarified is how this class is built beforehand. So, now focus your attention on the question of how to get a set of constraints, implement them in XML, and ensure that documents conform to these constraints? One more question is, how do you generate a reusable Java class from these constraints?

[1] [2] Next page