Java Reference
In-Depth Information
Chapter 3. Working with XML and Java
Introduction
This chapter provides some useful techniques for handling XML data in a variety of ways that
are important specifically in the context of building out your SOA. We'll also examine some
relatively new ways of working with XML as provided by the latest Java APIs. As Java pro-
grammers, we've been processing XML in a variety of ways for several years, so I'm going to
forego the basics there. I assume that you've worked with SAX and DOM before, so we can
get right to the new stuff. Finally, this chapter aims to illustrate how to effectively use XML
and data binding specifically within an SOA.
It is not a given, however, that every architect will design an SOA around XML. If you have
decided that all your services will be implemented in straight Java using EJBs or RMI, that's
fine too. But using XML as your mode of message exchange isa very popular approach, and
for good reason. SOA is about flexible integration. And while legacy data may live in a variety
of formats, if you can get it into XML, you can move it anywhere else, transform it, and give
it new life. In this way, XML supports what is, in my view, the core message of SOA: em-
brace difference. Midrange iSeries computers from IBM whose day job is running 20-year-old
COBOL programs now come with SAX parsers out of the box. Native XML databases such
as Xindice and Berkeley XML DB are gaining modest popularity. In support of SQL 2003,
Microsoft SQL Server, Oracle, and JDBC 4.0 treat XML as a first-class citizen, no longer for-
cing you to relegate your XML data to CLOBs. Using XML as a translation layer allows you
to always select the right tool for the job, rather than resigning yourself to choosing between a
world of application silos that don't communicate, or one vendor's idea of what your IT stack
should look like. So, using XML for messages is the general approach I take in this topic.
Finally, there are a lot of choices out there for XML-to-Java round-trip generation. We'll look
at a couple of them, including JAXB and XStream. There are other popular frameworks too,
including Castor and the XMLBeans project at Apache. But in working with a Java stack, it
is convenient to go with JAXB, as you automatically inherit performance improvements and
functionality due to its having been rolled up with Java SE and the JAX-WS reference imple-
mentation. It can be comforting to know that the technologies will grow together and remain
compatible with minimum fuss. In general, it seems like a good idea to minimize dependen-
cies, but that doesn't mean you shouldn't use the best tool for the job you have to get done.
Everyone has exceptions, and I (and everyone I know) still use Log4J even though Java's had
its own logging API since 1.4. The corollary of embracing difference is using the right tool
for the job.
