This article
Transfer from IBM DeveloperWorks China website
Object, there is an ubiquitous object in this first part of the series of articles consisting of four parts, we will figure out what is data binding, what is its advantage over other methods of processing XML data in the Java application, and How to start using it. This section will examine why the data binding is used, and how to establish a model for a variety of constraints, so that the XML document can be converted into Java objects. It also covers inputs and outputs used to generate data binding classes. Do you want to use XML in your Java application? So good, with thousands of others together. When you know in depth, you will find the DOM and SAX API (see Resources), but it is a pan. You may think that there is certain simple way to get an XML document, and access it through the Java application, right? Don't use a callback or complex tree structure, but use methods like SETOWNER (STRINGOWNER) and INT GETNumOrDers ()? If you have considered a problem along this idea, the data binding is the solution you are looking for. Analyze a variety of choices today XML and XMLism are flooding (XSL, RDF, Namespace, RSS, XML Schema, Xslt ...), you may think that there will be many ways to access XML in the Java application. data. Surprisingly, if you find out if you find it, there is only three ways to access XML data. That's right - there are only three ways, one of which is still recently seen with a new Java API. It should be taken like this: The selection range makes it easier to select the method suitable for your method. The callback callback is working as an event drive model. When analyzing an XML document, some events-such as the start of the document and the start of character data in an element - will trigger the callback method. You can implement the Java code for these events by using the data required to perform logic. It is necessary to understand that this approach cannot be completely intuitive; developers usually take a period of time to understand and master the use of the callback model. SAX, a simple API for XML, is a factual standard for this XML usage method. Tree is more common, more popular is this API, which makes an XML document and then creates the tree structure of the data. The XML document has become a tree, which acts as a container. It has several child, such as root elements. The root element has its additional child, and it is pushed until (in a sense) obtains a picture of XML data. Because almost every college student has handled a tree structure at a certain stage, this can be used as a very intuitive way to represent XML data. The most popular API used for XML document tree representation is the recommended standard for W3C, namely document object model (DOM). An updated API, JDOM (this is not the first letter abbreviation) recently being promoted and popular. (Although this program is built with Jason Hunter, I have to say truth.) In addition, DOM and JDom are the basic requirements for Spinnaker scheme design, Spinnaker is a new XML analyzer, which is the Apache XML scheme. Some are under development. Although the tree API looks more easily than the event-driven SAX, they are not always suitable. Very large document may require a lot of memory (especially when using DOM); when the tree structure is converted (XSLT), the system may stop running even completely crash.
Although updated APIs (such as JDOM) can handle these issues, they will still be a problem if you have to handle extremely large amounts of data. Moreover, sometimes developers prefer to model data in the XML document into a simple reading and writing method without a tree model. For example, developers would rather not access the child node named Skunumber and set the text value of the node, and only want to call setskunumber ("mysku") and proceed. The term interpretation of data binding: A new method of accessing XML data within the Java application, using an API, JSR-031, still developed. JSR-031: Sun is still a new Java specification request in development, designed to compile XML documents into one or more Java classes, and can easily use these Java classes in the Java application. Package: Convert Java objects to XML representation, with the current value. Unpack: Create a Java object according to the XML object, usually generate a Java object based on the package.
Upon access to XML data with Java code To rely on a new set of Java methods and related APIs, these APIs are still under development. Data binding is a "Java Specification Requirements" built by Sun, seeing a reference, it is designed to make Java objects to XML documents more convenient, so that a format can easily convert For another format, vice versa. Binding references a Java object with a read and write method, reading and writing methods affect the XML document on the bottom layer, and is also directly mapped to the names and features of the XML document. When you enter some details in this series of articles, this illustration will make more meaningful, but in the current, just say it is enough: this makes XML document characteristics Name can pass a setName () Method, change its value, just like I hint above. Data Binding This access method is being popularized and is particularly useful when storing configuration information in an XML document. Many developers have found that it is very convenient to access the required parameters without having to use a more complex tree structure. Although this access is not used for document conversion or messaging, it is extremely convenient for simple data processing. It is our third use of XML in this article and this series of articles. (Of course, any method will then take a range of new terms, so please see the term explanation to understand these new jars.) Can any XML documentation can be converted to a Java object? Or just some types of XML documents can you? Asked! You are likely to simply want to convert documents that meet a set of constraints to Java objects. This is similar to the way to define the Java interface: You make sure you only instantiate and use objects that adapt to the interface, allowing how to operate the object to make assumptions. Similarly, you only allow XML objects that meet a set of constrained conditions to Java objects; this allows you to use the created objects as desired.
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. Is it a new class to create a new class for each document or an instance of a existing class? Which existing class do you want to use? And most importantly, is your document that is processing solely to convert to a Java object? That is a lot of questions, but you will find all the answers here. Will these problems as a series of decision points, a range of options. First, you must determine if you can create a Java object from the XML document (as discussed earlier). If you can, you have to decide that the conversion should appear in the form of a new Java class or only in the form of an example of an existing class. Finally, if the existing class is selected, which class is used? The result is a variety of decision trees. If we examine one example XML document shown in Listing 1, then handle these problems, the meaning of the decision tree is clearer. This sample document represents a service in ENHYDRA Application Server (specifically a web container). Listing 1. A XML document for configuring a web container in ENHYDRA
This configuration document contains information about the version and name of the service itself, as well as several nested items, each project represents some additional information about the web container service. It gives detailed information about ports (including port numbers, protocols, and security), which also gives document service information (including document roots, default extensions for index pages, and error pages). All of these is to configure all the information required for a new web container service. Remember this example, you can start answering the issues indicated by the data. Is it suitable for conversion? Absolutely suitable! Just look at the XML document in Listing 1 will find that it represents an object (overall configuration object), has several features or variables. Some variables are additional objects (ports and documents), which have their own characteristics. In fact, this is an excellent example of XML document that is suitable for converting to Java objects. To further ensure that this object is available, I will show you a way to confine the data in the document later. But, let's go down along the decision tree. Converting into a class or an example? After solving the appropriate problem, you can make a decision now, it is a new Java class that makes each XML configuration document as a new Java, or a new instance of a certain existing class. In other words, it is to generate a new code or use an existing code. According to this, this has become a simple reusability issue. Easible and smarter is to generate a new instance of a present class for each XML document. If you must try to create a new Java class from each document, you may have no compatibility between the individual classes - that is, two identical documents may cause two different Java classes! Without this may cause confusion, you can use a set of XML constraints (represented by a DTD or XML scheme, will be described below), and generate a Java class according to these constraints (or multiple classes, as needed) . This 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 a constraint condition for a document that represents a web service configuration. These constraints will be mapped into a Java class, which we will call WebServiceConfiguration. You can then get any XML document that represents a specific web service configured and assumes that this document meets our constraints, which creates an instance of the previously generated class. This will allow applications to use different XML documents as objects as the same type, as long as data in these documents is effective for the object design to achieve purposes. New category or existing class? Now you have any conditions to answer the next question: You want to create an instance of an existing class is the WebServiceConfiguration class. All things that need to be removed are, how this class is pre-made. So, now please focus on such a question: How to get a set of constraints, implement them with XML, and ensure that the document meets these constraints? Another question is, how do you generate a reusable Java class from these constraints?
With document constraints, since you know that this document will be converted to a Java instance, this has generated another question: Describe that you must ensure that this document must be unpacked to a selected Java class in some way. The lack of variables or data types are incorrect. It may result in errors in the unpacking process - or even run when the client accesss the configured container. The best situation is that before the actual unpacking process begins, the author of the document guarantees that the configuration document is "legal" for the class to indicate the data. The XML person who reads this program may turn their eyes and say, "Ok, of course you will use XML document constraints." Confirm that the legality of the data on the selected class can be referenced by reference DTD (document type) Define) or XML schemes to complete. By using a set of constraints represented by an external DTD or scheme file, the document author can test configuration data on the "interface" of these data. In other words, you can create an application so that it is possible to check the data contained in the XML instance document, while the required data is specified in the external file of the document constraint. This way, you can create an interface for data. Making a decision between using the DTD scheme or using an XML scheme is a fairly simple choice: because the Java language is highly type, we hope to support type in the XML document. For example, the data interface should be able to verify that an integer is provided for the port number of the web container, not a string, the latter will cause an error when the service is started. DTD does not support type checks, so we will undoubtedly choose an XML scheme. Although the XML scheme is a little uncertain in the field of norms, it has been stable to a large extent and is expected to be in the same year. We can write data constraints in an XML scheme and then verify possible instance documents with this scenario to ensure that the unpacking can do it on these instance documents. The following XML scheme represents the data interface of our web container service. Listing 2. XML scheme of the data interface of a web container configuration document
The XML scheme in Listing 2 defines several different data objects that together represent a configuration object for a web service. First, a core service configuration is defined, which contains the version and name. This can be used as all services (such as load balancing services, EJB containers, and of course there are our web services). Then, as an extension of this basic service, the web serviceconfiguration is defined. Note that after Java is formed, the program has established a model for the data interface. We add additional Web service properties Port and Document to the version of Version and Name. These properties themselves are objects, with their own properties (Protocol, root, error, etc.). In the definition of this scenario, the features represent simple Java types, typically the primitive type. In this way, Name and Version become the Java original type of type String and Float, respectively. Elements such as Port and Document become Java objects, which can have their own properties, or with feature. This will have a recursive phenomenon: the element turns into a new object and checks each attribute of it. If the property is a feature, create a simple Java original member variable for this object; if the attribute is an element, create a new object and add it as a member variable, then start again on this new object. Procedure until all classes have been created. From radishes ... Um ... XML Get Java Once you have created an XML scheme, you need to extract the necessary information from this scenario to determine which Java classes should be created. The first step in this process is to view the XML scheme and strictly determine what the output should be. Two Java raw properties are defined for simple serviceConfiguration objects: Name and Version. For such a simple object, it is not difficult to determine the required interface. Simply write the name of the name of the name of the type, and these Java properties can be added to the interface, as shown in Listing 3. Listing 3. Java code generated from XML scheme for serviceConfiguration Public Interface
ServiceConfiguration {public void setVersion; public float getversion (); public void setname; public string getname ();
This is quite understandable; the interface in Listing 3 provides a read method and write method for the attribute defined in the XML scheme. In addition, you will need to generate a class to define each member variable of this interface and implement each method in this interface. This method separated from the implementation allows us to make us a variety of implementations for specific needs. For example, a particular service may need to perform calculations, not just accept the value received from the write method. Now considering the more complex situation is a bit fashionable, but I will re-refer to it in subsequent articles. However, in general, you can still determine what you should look like, as shown in Listing 4. Listing 4. Java code generated from XML scheme for ServiceConfiguration PUBLIC CLASS
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 The same principle is also applicable to other objects defined in the XML scheme. You can find other Java classes below (because they should be generated):
Porttype.java
PortTypeImpl.java
DocumentType.java
DocumentTypeImpl.java
WebServiceConfiguration.java
WebServiceConfigurationImpl.java
Summary to so far, you should be familiar with all aspects of data binding. I have initially introduced the reasons you should use, especially within the scope of configuration information, and outlined some basic concepts you need to do for this method. The next article of this series of articles will continue to investigate the process of data binding. You will have the opportunity to check the org.enhydra.xml.binding.schemamapper class, which will accept the XML scheme created in this first part as the data interface and create a Java interface and implement class from it. The second part of this series will explain each step of this process and explain how to ensure that the scheme is accurately represented so that the XML document can then be converted to the example of the generated class.
