Zeus, Data Binding, and YouBy Brett McLaughlinIn 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 questions. 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 complete control. 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. |  |
|
