Zeus, Data Binding, and You
By Brett McLaughlin
In this month's "Making Waves" column, I want to spend a little time talking about
a subject and project close to my heart: Zeus. If you have been on any of the Enhydra
mailing lists, you've probably seen some announcements about the Zeus project in the last
few weeks. It's a new project at enhydra.org, and I'm happy to say it's been getting a
lot of attention. And as my area of expertise these days seems to be Java and XML, you
probably won't be surprised to learn that it's these areas that Zeus is built upon. But
before I tell you more about what's going on with Zeus, let me answer some often asked
Question: What is Data Binding?
Answer: Data Binding is just what it sounds like - a process that takes XML data, and provides a Java
binding. In other words, it converts an XML document into a Java object. However, unlike APIs like SAX, DOM, and
JDOM (see a later question about these), data binding does not provide a generic tree structure for this data. Instead,
it generates Java classes from a DTD, XML Schema, or other constraint mechanism. These classes are data-driven. So you might
have a Person class with a firstName, lastName, and a nested Address object with its
own fields and properties. An XML document would be converted to this format, and the data in the document would be used
to populate the fields in the Java object. At the end of binding, your Java object behaves by using methods like
setFirstName(String firstName) and Address getAddress(), rather than with less intuitive methods like
getFirstChild() or setText(). Therefore, it is perfect for situations where convenience is needed over
Question: Does Sun have anything to say about Data Binding?
Answer: Yes, they sure do. JSR-31 is a Java Specification Request that seeks to both define data binding and
provide a Java implementation. The specification has actually been around for about a year now, and has been tossed to
and fro quite a bit. However, there should be an initial specification and reference implementation (code-named "Adelard")
out sometime this year. That will be Sun's first offering in the data binding space; however, there is little information
to be had about how this will behave, so your guess is as good as mine! I have spoken with Mark Reinhold, the specification
lead, and others involved, and Zeus is going to track JSR-31's development very closely.
Question: Does Zeus implement JSR-031?
Answer: No. JSR-31 is actually very thin right now, and until there is a reference implementation (Adelard), it
will be more or less impossible to "implement it." However, the way that Zeus is built allows it to adapt very quickly to
any new requirements, so once JSR-31 is available for implementation, Zeus will probably move in that direction. And by the
way, lest you be fooled, nobody implements JSR-31 right now - don't let anyone fool you ;-) Additionally, the first
release of Adelard and JSR-31 is supposedly going to be absent schema support, which Zeus will have. So we're even better
than JSR-31 :)
Question: Does Zeus use DTDs or XML Schemas?
Answer: Both, at least very soon! ;-) Zeus in Beta 1 supported DTDs with a few known bugs. The current code has fixed these bugs, and
handles just about any DTD you throw at it. Additionally, XML Schema work is being done as you read this, and will be
supported in a very near release (probably Beta 2 or 3). So by the time you read this, the answer will probably be "Both,
right now!" :)
Question: What if I don't like DTDs, but don't want to use schemas?
Answer: This question is a really important one, and brings out something critical about the way Zeus is
architected. Currently, Zeus supports DTDs for constraints, and work is being done to support XML Schemas soon (expect
something very soon - maybe by the time you read this!). However, there are lots of other constraint mechanisms out there -
Relax schemas come to mind, for example. Zeus is completely exstensible, in that it converts a set of constraints (in the
form of a DTD or schema) into a set of Zeus bindings. These are then converted to Java classes. What this means is
that when class generation occurs, it is completely isolated from the constraint mechanism. So, to support something like
Relax, all that would be needed is a class to convert from Relax to Zeus bindings. This turns out to be a fairly simple task,
and then class generation is already in place! So plugging in a new module (and a simple module, at that) is all it takes to
support a new constraint mechanism. So you can use whatever you want - submit your request today, and we'll work on new
modules as they come up!
Question: Why can't I use XMLC for this?
Answer: This is a common question. XMLC does provide an XML to Java mapping, converting an HTML, WML, or other
*ML page to a Java object that can then be worked with. However, XMLC is built specifically for presentation layers, and
is not well-suited to frequent conversion between an XML document and Java, and back (and forth, and back, and forth...),
which is a common task in working with configuration data and other data binding tasks.
It also does not easily work with XML Schemas or DTDs in terms of providing validation, as that functionality is rarely
needed in presentation. On the other hand, if you are focusing on converting XML to a presentation layer, XMLC is the perfect
tool; so each has their own specific task and niche to fit into.
Question: Should I use data binding instead of SAX, DOM, or JDOM?
Answer: That's a bit of a tricky question. I consider SAX, DOM, and JDOM low-level APIs (or at least
lower-level). They provide more granular control over the XML document being worked with, and often offer complete
flexibility in the tasks that can be accomplished. Zeus, however, is a high-level API, and suited for different tasks.
While Zeus may not give you complete control over XML, it does provide an XML document in a more convenient fashion,
representing XML as a custom Java object (based on the XML data being represented), rather than a tree or similar structure.
This means that if you simply need to read and write data from XML without changing the document structure, Zeus can
really make your life easier. So the answer is, "I don't know!" Sometimes low-level APIs work best, and sometimes high-level
ones do - it will depend on your application.
Question: Where can I find out more?
Answer: Well, that's an easy one! You need to browse on over to http://zeus.enhydra.org
and you can get a ton of information on data binding in general and Zeus in particular. Additionally, you should read the
mailing list archives and join the mailing list, which is where discussions like these take place on a daily basis. I hope
to see you there soon! Also, be sure to check out the Zeus documentation section for links to an IBM series on data binding.
So, now you've hopefully got a better idea about what Zeus is, and hopefully see how
it relates to the overall Enydra picture. But before I let you go back to surfing,
coding, or listening to some bluegrass guitar (well, maybe that's just what I'll get
back to doing!), I wanted to say a few more things about the project. As many of you
know, I've started and run several other open source projects in my time - Apache's
Turbine (which I co-founded with Jon Stevens) and JDOM (which I co-founded with
Jason Hunter) are two of the most recognized. So when I started up Zeus, I was really
insistent about running it in the same open-source manner as these other projects. And
that's exactly what I've done with Zeus.
So what does that mean? Well, let me give you some examples. I've yet to write a single
e-mail about the Zeus project (after its inception, of course) except to the public
mailing list. That means that the community knows everything I know about the project,
from planning to coding to testing. All tasks to be done are put forth on the list and
everyone can "sign up" for them. In the first two weeks of the project, before any
public announcement was made, we had nearly a dozen subscribers. That number has exploded
to close to a hundred, and the project has only been around for a month and a half! I've
also started without any committers, other than myself, and add committers based on
a number of merit-based criteria. Submitting patches is the most obvious one; and we
now have two other committers, one from Lutris (who I've actually never met!), and one
from the external community. In other words, you could join up today and be one of the
next committers! And documentation, testing, and integration is all being done by the
community. Everything is a complete group effort!
What's the point? Well, the point is that this is a proof of concept at Enhydra. And
the tremendous success of this approach means that you will see the other Enhydra projects,
like XMLC, DODS, Kelp, the EJB container, the web container, and all the rest, begin to
adopt aspects of this model. And that, in turn, means that Enhydra will continue to
embrace open source, taking the model further and further over time. So look for Enhydra
to shed the trappings of a commercial product line, letting the community take more
and more of a part in every aspect of development. Maybe this is no big deal to you; but
if you are like me, this is a pretty cool thing. When the developer, the user, and the
manager are all on a level playing field, projects tend to be useful, not just a line
item on a glossy sales sheet. And Enhydra seeks to be just that - the most useful tool,
server, program, and experience you can find. So join me on the Zeus list, have a good
time, and I'll see you (as always) online! Viva la Open Source!
Brett McLaughlin is
the author of Java And XML, published by O'Reilly. He currently
specializes in building application infrastructure using Java and
Java-related technologies. He has spent the last several years implementing
these infrastructures at Nextel Communications and Allegiance Telecom,
Inc. Brett is one of the co-founders of the Java Apache project
Turbine, which builds a reusable component architecture for web
application development using Java servlets. He also contributes
to the EJBoss Project, an Open Source EJB application server, and
Cocoon, an Open source XML web-publishing engine. His projects all
focus on XML and the J2EE platform in mission-critical, high-performance
distributed systems. Brett has recently been appointed Enhydra Strategist
at Lutris Technologies.