Tài liệu Java and XML Data Binding ppt

54237222223154051095082227176186254241250143239137210252117074104060119172099042079097244175

Preface
XML data binding. Yes, it's yet another Java and XML API. Haven't we seen enough of
this by now? If you don't like SAX or DOM, you can use JDOM or dom4j. If they don't
suit you, SOAP and WSDL provide some neat features. But then there is JAXP, JAXR,
and XML-RPC. If you just can't get the swing of those, perhaps RSS, portlets, Cocoon,
Barracuda, XMLC, or JSP with XML-based tag libraries is the way to go.
The point of that ridiculous opening is that you, as a developer, should expect some
justification for buying yet another XML book, on yet another XML API. The market
seems flooded with books like this, and the torrent has yet to slow down. And while I
realize that I use circular reasoning when insisting that this API is important (I did write
this book on it), that's just what I'm going to do.
XML data binding has taken the XML world by storm. Thousands of programmers
simply threw up their hands trying to track SAX, DOM, JDOM, dom4J, JAXP, and the
rest. It's become increasingly difficult to parse a silly little XML document, rather than
increasingly simple. If it's not namespaces that get you, it's whitespace. Is that carriage
return after my element name significant? Well, it depends on whether you specify a
DTD; oh, you used an XML Schema? Well, we don't support that yet. I'm sure you know
exactly what I'm talking about.
The reason why XML data binding is important, and so remarkably different from other
approaches, is because it gets you from XML to business data with no stops in between.
You don't have to deal with angle brackets, entity references, or namespaces. A data
binding framework converts from XML to data, without your messing around under the
hood. For most developers who try to get into XML without spending months doing it,
data binding is just the answer you are looking for.
This book covers data binding from front to back, giving you the ins and outs of what
may turn out to be the API that makes XML accessible to even the newest programmers.
You'll learn how to perform basic conversions from Java to XML, all the way to using
various frameworks for advanced transformations and mappings. It's all in this (nicely
compact) book, without lots of wasted words and frilly examples. If you want to use data
binding, this book is for you. If you don't, well, put it down and go pick up about ten
other books so you can manipulate XML some other way. I think the choice is obvious;
so get started!

154237222223154051095082227176186254241250143239137210252117074104060119172099043170090101072

5

Organization
I begin this book with a brief explanation of what data binding is and what other APIs are
in the XML field. From there, I provide an extensive look at Sun's JAXB, that company's
data binding framework. You'll learn every option and every switch to use this package.
Then, to round out your data binding skills, I examine three other popular open source
data binding frameworks, each with its strengths and weaknesses.
Chapter 1
This chapter is a basic introduction to XML data binding and to the general Java
and XML landscape that currently exists. It details the basic Java and XML APIs
available and organizes them by the general usage situations to which they are
applied. It also details setting up for the rest of the book.
Chapter 2
This chapter is the (only) theoretical chapter in the book. It details the difference
between data-driven and business-driven APIs and explains when one model is
preferable over the other. It then explains how constraint modeling fits into the
data binding picture and how data binding makes XML invisible to the
application developer.
Chapter 3
This chapter is the first detailed introduction to data binding. It explains the
process of taking a set of XML constraints and converting those constraints into a
set of Java source files. It details how this is accomplished using the JAXB API
and then explains how the resultant source files can be compiled and used in a
Java application.
Chapter 4
This chapter continues the nuts-and-bolts approach to teaching data binding. It
covers the process of converting XML documents to Java objects and how the
data should be modeled for correct conversion. It also details the use of resultant
Java objects.
Chapter 5
This chapter details the conversion from Java objects to XML documents. It
explains the overall process flow, as well as the implementation-level steps
involved in marshalling. It also covers creating data binding process loops,
ensuring that data binding can occur repeatedly in applications.

6

Chapter 6
This chapter focuses on binding schemas and how they can customize
transformation from XML to Java. Every option in binding schemas is examined
and discussed both technically and practically.
Chapter 7
This chapter begins an exploration of alternate data binding packages with Zeus.
The coverage is based on the explored JAXB concepts and compares Zeus
operation to the techniques already discussed in previous chapters. Particular
attention is paid to Zeus enhancements that are not in the JAXB API.
Chapter 8
This chapter continues exploration of alternate data binding implementations by
looking at Castor. This open source alternative was the first major data binding
implementation available and offers many features not present in JAXB. These
features, as well as process variations, are all covered in this chapter.
Chapter 9
Quick is another open source data binding API, and this chapter details its ins and
outs. You'll see that Quick offers ideas and processes that are entirely different
from most data binding frameworks and you'll learn how those differences can be
put to work in your applications.
Chapter 10
This chapter looks at the future of data binding. It covers the final version of
JAXB, as well as expectations for the next JAXB release. It also covers how
alternate data binding implementations are likely to change with a JAXB 1.0
release and looks at JAXB in light of the J2EE platform.
Appendix A
This appendix details all the options for the tools provided by various data
binding APIs. It can be used as a quick reference for each chapter and for your
own programming projects.
Appendix B
This appendix details several source files used by the examples in the Quick
chapter.


7


Conventions Used in This Book
I use the following font conventions in this book:
Italic is used for:
• Unix pathnames, filenames, and program names
• Internet addresses, such as domain names and URLs
• New terms where they are defined
Boldface is used for:
• Emphasis in source code (including XML).
Constant width is used for:
• Command lines and options that should be typed verbatim
• Names and keywords in Java programs, including method names, variable names,
and class names
• XML element names and tags, attribute names, and other XML constructs that
appear as they would within an XML document

This symbol indicates a tip.

This symbol indicates a warning.

Comments and Questions
Please address comments and questions concerning this book to the publisher:
O'Reilly & Associates, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
(800) 998-9938 (in the United States or Canada)
(707) 829-0515 (international/local)
(707) 829-0104 (fax)
There is a web page for this book, which lists errata, examples, or any additional
information. You can access this page at:
http://www.oreilly.com/catalog/javaxmldatabind


8

To comment or ask technical questions about this book, send email to:
bookquestions@oreilly.com
For more information about books, conferences, Resource Centers, and the O'Reilly
Network, see the O'Reilly web site at:
http://www.oreilly.com

Acknowledgments
At some point, you start writing acknowledgments and taking them for granted. Then,
you realize that this is the only section that most of your family will read and understand,
and you slow down and get them right.
First, for the technical folks. Mike Loukides and Kyle Hart manage to get me to write
these books, and write them fast, without exploding. Thanks guys, but I'm going on
vacation now! I had two incredible reviewers on this book, and they really transformed it
from OK to great, in my opinion. Thanks to Michael Daudel and Niel Bornstein for
persevering under major time constraints and still generating really good comments.
My family is always amazing, and always interested, even though I know they wonder
what it is I write about. My parents, Larry and Judy McLaughlin, taught me to read and
write and to do them both well. I'm eternally indebted, as are my readers! My aunt, Sarah
Jane Burden, is always there to state the obvious in a way that makes me laugh, and my
sister has simply grown up as I have written these books. She's now teaching math,
probably producing more programmers and writers. I'm proud of you, Sis!
The other side of my family has been there for me since I met them, especially since we
live in the same town. Gary and Shirley Greathouse, my father- and mother-in-law, keep
me laughing as well, mostly at the strange things they manage to make their computers
do ("So, there's this black screen with little rectangles—what do I do now?"). Quinn, Joni,
Laura, and Lonnie are all fun to be around, and that's saying a lot. And little Nate, my
first-ever nephew, is absolutely the coolest little guy on the planet, at least for a few more
months.
My wife, Leigh, has lived with a husband who has written for more hours a day than he
spends with her, for nearly three years, and has always loved and supported me. That's
saying a lot, because I'm a royal pain most of the time. I love you, honey. And as for that
"few more months" comment, I've got a little boy coming in June (2002) who should
make life even more exciting. When you read this one day, kiddo, remember that I love
you.
Last and most important, to the Lord who got me this far: even so, come, Lord Jesus. I'm
ready to go home.

9


Chapter 1. Introduction
With the wealth of interest in XML in the last few years, developers have begun to crave
more than the introductory books on XML and Java that are currently available. While a
chapter or two on SAX, some basic information on JAXP, and a section on web services
was sufficient when these APIs were developed, programmers now want more.
Specifically, there is a huge amount of interest in XML data binding, a new set of APIs
that allows XML to be dealt with in Java simply and intuitively, without worrying about
brackets and syntactical issues. The result is a need in the developer community for an
extensive, technically focused documentation set on using data binding; examples are no
longer just helpful, but a critical, required part of this documentation set. This book will
provide that technical documentation, ready for immediate use in your application
programming.
To fill this need, I want to start off on the right foot and dive into some technical material.
This chapter will give you basic information about existing XML APIs and how they
relate to XML data binding. From there, I move on to the four basic facets of data
binding, which the first half of this book focuses on. Finally, to get you ready for the
extensive examples I walk you through, I devote the last portion of this chapter to the
APIs, projects, and tools you'll need throughout the rest of the book. From there on, I
assault you with examples and technical details, so I hope you're ready.
1.1 Low-Level APIs
By the simple fact that you've picked up this book, I assume that you are interested in
working with XML from within your Java programs and applications. However, it's
probably not too smart to assume that you're a Java and XML expert (yet—although
picking up my Java and XML book could help!), so I want to take you through the
application programming interfaces (APIs) available for working with XML from Java.
I'll start by detailing what I will henceforth refer to as low-level APIs. These APIs allow
you direct access to an XML document's data, as well as its structure.
To illustrate this concept a little more clearly, consider the following simple XML
document:
<?xml version="1.0"?>

<songs>
<song>
<title>The Finishing Touch</title>
<artist type="Band">Sound Doctrine</artist>
</song>

<song>
<title>Change Your World</title>
<artist type="Solo">Eric Clapton</artist>

10

<artist type="Solo">Babyface</artist>
</song>

<song>
<title>The Chasing Song</title>
<artist type="Band">Andy Peterson</artist>
</song>
</songs>

An Abridged Dictionary
Before going further, you should know a couple of terms. For those of you
familiar with XML, this should be old hat, but for XML newbies, this should
prevent future confusion.
Well formed
An XML document that follows all the rules of XML syntax, such as
closing every open element in the correct order.
Valid
An XML document that follows the constraints set out for it by a DTD
or XML Schema. If the document does not follow these constraints, it is
invalid.
Anything else that confuses you can be found in a quick page, either through
O'Reilly's Learning XML, by Erik Ray, or XML in a Nutshell, by Elliotte Rusty
Harold and W. Scott Means. I recommend having one or both nearby as you go
through this book.
Using a low-level API, you could access the textual content of the second artist
element in the second
song. That's the data of the document. In addition, a low-level API
lets you change the name of the third song element to folkSong, or move the second
song element before the first one. In other words, you have direct access, though methods
like setName() and getChild(), to the document itself. These actions don't involve the
data in the document, but the structure. Understanding this concept is important because
you'll see in a moment that a whole set of APIs don't allow this access and are aimed at a
very different set of use cases.
In general, using a low-level API is a little more complex than using high-level APIs
(discussed in a moment), as it requires more XML knowledge. Since you have access to a
document's structure, it's not too hard to create an invalid document. Additionally, you
are going to spend as much, if not more, time dealing with document structure and rules
of XML than with the actual data. This means that in a typical application, you're
spending more time thinking about structure than solving any given business problem.
For these reasons, low-level APIs are usually most common in infrastructure tasks or

11

when setting up communication in messaging. When it comes to solving a specific
business problem, higher-level APIs (see the next section) are often more appropriate.
With that in mind, let me give you the rundown on the major low-level APIs that are
currently available.
1.1.1 Streamed Data
The grandfather of all Java-based low-level APIs is the Simple API for XML (SAX).
SAX was the first major API released that has any sort of following, and it remains the
basic building block of pretty much all other APIs. SAX is based on a streaming input
and reads information from an XML input source piece by piece. In other words,
information is sent to the SAX interfaces as the related input stream (or reader) gets it. To
use SAX for parsing, you register various handler implementations for handling content,
errors, entities, and so forth. Each interface is made up of several callback methods,
which receive information about specific data being sent to the parser, such as character
data, the start of an element and the end of a prefix mapping. Your SAX-based
application can then use that information to perform business tasks within the callback
method implementations.
The advantage to this stream-based approach is raw, blazing speed. SAX easily outstrips
any other API in performance (and don't let anyone tell you differently). Because it reads
a document piece by piece, making that data available as soon as it is encountered, your
applications don't have to wait for the complete document to be parsed to operate upon
the data. However, that speed carries a price: complexity. SAX is probably the hardest
API for developers to wrap their heads around, and even then, many have trouble writing
efficient SAX code. Because data is read in a streaming fashion, your callback methods
won't have access to an element's children, its parent, or its siblings. Instead, you have to
build up some in-memory stack if you want to keep an idea of tree location. Because of
this complexity, it's easy to ignore important data or make mistakes when reading in data.
As a result of this complexity, many developers pass up SAX and prefer an API that
provides an in-memory model of an XML document. You can learn more about SAX
online at http://www.saxproject.org
.
1.1.2 Modeled Data
Java and XML APIs that model XML data are generally more popular, as their learning
curve is much smaller. The oldest and most popular of these is the Document Object
Model (DOM). This API was developed by the World Wide Web Consortium and
provides a complete in-memory model of an XML document. DOM is not a parser (and
neither is SAX); it requires an XML parser that supplies a DOM implementation to
operate. When the parser completes its reading of an XML document, the result is a
DOM tree. This tree models an XML document, with parent elements having children,
textual nodes, comments, and other XML constructs. You can easily walk up and down a
DOM tree using the DOM API and generally move around easily. Because you have to
wait on a complete parse before using a DOM, it is often slower than using SAX; because
it creates objects for each XML structure, it takes a lot more memory to operate.

12

However, these disadvantages are paired with a significantly easier programming model,
a means to traverse the content of the DOM tree, and several implementations that offer
various options. For example, Apache Xerces offers a "deferred DOM," which makes
some trade-offs to reduce the memory overhead when using DOM. For more on DOM,
check out http://www.w3.org/DOM
.
Recently, developers have moved away from DOM. This is because DOM has some
quirks that are not familiar to Java developers; this isn't surprising, considering that DOM
is specifically built to work across multiple languages (Java, C, and JavaScript). As a
result, some of the choices made, such as the lack of support for Java Collections, don't
sit well with Java developers. The result has been two APIs that both are object models
aimed squarely at Java and XML developers. The first, JDOM (http://www.jdom.org
), is
focused on simplicity and avoiding interfaces in programming. The second, dom4j
(http://www.dom4j.org
), keeps the DOM-style interfaces, but (like JDOM) incorporates
Java collections and other Java-style features. I prefer JDOM, but then I cofounded it, so
I'm a bit biased! In any case, DOM, JDOM, and dom4j all offer more user-friendly
approaches to XML than does SAX, at the expense of memory and performance.
1.1.3 Abstracted Data
Completing the run through low-level APIs, the third model is what I refer to as
abstracted data. This type of API is represented by Sun's Java API for XML Parsing
(JAXP). It doesn't offer new functionality over the streamed data (SAX) or modeled data
(DOM and company), but abstracts these APIs and makes them vendor-neutral. Because
SAX and DOM are based on Java interfaces, different vendors provide implementations
of them. These implementations often result in code that relies on a specific vendor
parsing class, which ruins any chance of code portability. JAXP offers abstractions of the
DOM and SAX APIs, allowing you to easily change parser vendors and API
implementations.
The latest version of JAXP, 1.1, offers this same abstracted data model over XML
transformations, but that's a little beyond the scope of this book. In terms of pros and
cons in using JAXP, I'd recommend it if you will work with SAX or DOM and can get
the latest version of JAXP. It helps you avoid the hard-coded sort of problems that can
creep in when working directly with a vendor's implementation classes. In any case, this
brief little whirlwind tour should give you at least a basic understanding of the available
low-level Java and XML APIs. With these APIs in mind, let me move up the rung a bit to
high-level APIs.
1.2 High-Level APIs
So far, the APIs I've discussed have been driven by the data in an XML document. They
give you flexibility and power, but also generally require that you write more code to
access that power. However, XML has been around long enough that some pretty
common use cases have begun to crop up. For example, configuration files are one of the
most common uses of XML around. Here's an example:

13

<?xml version="1.0"?>

<ejb-jar>
<entity>
<description>This is the Account EJB which represents
the information which is kept for each Customer</description>

<display-name>TheAccount</display-name>
<ejb-name>TheAccount</ejb-name>

<home>com.sun.j2ee.blueprints.customer.account.ejb.AccountHome</home>

<remote>com.sun.j2ee.blueprints.customer.account.ejb.Account</remote>
<ejb-
class>com.sun.j2ee.blueprints.customer.account.ejb.AccountEJB</ejb-
class>
<persistence-type>Bean</persistence-type>
<prim-key-class>java.lang.String</prim-key-class>
<reentrant>False</reentrant>
<env-entry>
<env-entry-name>ejb/account/AccountDAOClass</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>
com.sun.j2ee.blueprints.customer.account.dao.AccountDAOImpl
</env-entry-value>
</env-entry>

<resource-ref>
<res-ref-name>jdbc/EstoreDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</entity>
</ejb-jar>
In this case, the example is a deployment descriptor from Sun's PetStore J2EE example
application. Here, there isn't any data processing that needs to occur; an application that
deploys this application wants to know the description, the display name, the home
interface, and the remote interface. However, you can see that these are simply the names
of the various elements.
Instead of spending time parsing and traversing, it would be much easier to code
something like this:
List entities = ejbJar.getEntityList();
for (Iterator i = entities.iterator(); i.hasNext(); ) {
Entity entity = (Entity)i.next();
String displayName = entity.getDisplayName();
String homeInterface = entity.getHome();
// etc.
}
Instead of working with XML, the Java classes use the business purpose of the document
rather than the data. This approach is obviously easier and has become quite popular.

14

Xem chi tiết: Tài liệu Java and XML Data Binding ppt