Apache XMLBeans is a technology that provides a simplified model for interacting with XML documents and was originally donated from BEA. Apache has announced that now it is a full-fledged Apache community and codebase under Apache License 2.0.
- Posted by: Dion Almaer
- Posted on: June 28 2004 10:00 EDT
NOTE: This is one of the steps of the Apache XML Project to promote its projects upwards and become a federation, or a central information repository, of all the XML-related projects at the ASF. Look for more promotions over the next few months.
Visit the current home of XMLBeans at: http://xml.apache.org/xmlbeans
View the XMLBeans announcement
- Apache XMLBeans moves up to top level by Kit Davies on June 29 2004 05:22 EDT
- XMLBeans vs SDO by George de la Torre on June 29 2004 09:50 EDT
- XMLBeans is easy, too by Java Coder on June 29 2004 14:52 EDT
- feature set by Stefan Chis on June 29 2004 17:04 EDT
I have only looked at XMLBeans briefly so apologies if I have missed something.
But I couldn't see what benefits XMLBeans brings over any standard JAXB implementation. They seem very similar in purpose and method. Is there a JAXB facade? If not, what's the selling point?
Unlike the options available today with JAXB, XMLBeans supports 100% of the W3C XML Schema specification. This is pretty significant difference from an alternative that means you never really know when you're going to get a schema that you want to bind to that won't be supported by the technology you've built on.
XMLBeans also has full Infoset fidelity with a store to support this. This means that you can grab XML, manipulate the parts you want in Java, and then pass the intact document (other than your particular changes) onto the next process -- no more worrying about what seemingly insignificant parts of the doc got stomped on along the way.
Actually there are significant differences between xmlbeans and jaxb 1 (jaxb2 remains to be seen). The differences primarily revolve around support of the full xml feature set, primarily in the xml schema area, and around providing access to the full xml infoset.
In the xml schema area I *believe* it is safe to say xmlbeans has the strongest support of any of the java/xml binding tools. When you compile a schema or many schemas in xmlbeans you get the full xml schema type system, including the built-in schema types, as well as the custom types that you have defined. There is a nice diagram here(http://edocs.bea.com/workshop/docs81/doc/en/core/index.html) showing the mapping of xml schema types to the equivalent xmlbeans java class. In xml schema all types, including custom types, inherit from the anyType. In XMLBeans the anyType is represented by XmlObject and all of the generated classes inherit from XmlObject. XMLBeans treats schema compilation in a very similar way to Java compilation with target namespaces (which can have mapped names) being like packages and the schema types becoming classes (or primitives). Also, there is the concept of schema type loaders that operate similar to java class loaders. The result of all of this schema compilation work is to create schema type system in java that supports ALL of xml schema features in IMO a very elegant manner.
All that being said, from a user perspective, the usage is very similar to JAXB and other java/xml bindings. You get interfaces/classes that have a javabean type shape. However, when you get into some of the advanced features of schema the advantage of truly representing the xml schema type system in java becomes readily apparent. Also, you have full access to the schema type system (similar to java reflection) at any point if you need it.
The other major difference between xmlbeans and other java/xml binding strategies is in the area of access to the full xml infoset. Pretty much all of the other java/xml binding strategies (including JAXB) unmarshal an xml instance directly into java objects, meaning they take whatever xml that fits into the java objects and then throw the rest of the xml away. XMLBeans takes a different approach, instead it loads the xml into an xml store, thus preserving the xml infoset. The generated binding classes sit on top of the xml store. A user you can then work at the generated class level and at any time you need to switch to working directly on the xml store. In XMLBeans v1 the api to work with the xml store is the xmlcursor api, in v2 DOM Level II is also supported natively. An implication here is that XMLBeans has a full 'untyped' programming model that is a partner with the java/xml binding 'typed' programming model. There are many projects that are just using the xmlcursor api because of it's stong performance characteristics - this should also be true of the dom support in v2.
The idea behind xmlbeans, that is not a stated goal of any other existing java/xml binding approach that i know of, is to support every XML Schema and every XML Document that an enterprise has - or will have. As an enterprise it seems near impossible to be able to control all of the schemas and/or xml documents that you will be expected to support so it seems that xmlbeans would an important option to consider.
There are tradeoffs for the approach that xmlbeans takes to java/xml binding. Since all of the generated interfaces derive from xmlobject you do not have POJOs (plain old java objects) to work with so it is an exercise left to you as a developer if you want to map these to your own java classes (although xmlbeans may help with this in the future). Keeping an xml store as well as the java objects (although the java objects are lightweight) will have some amount of perf overhead (memory and cpu).
Hope this helps people understand the differences a bit. Maybe I am too close to it but these seem like significant differences that could have a lot of impact on your architectural decision making.
apache xmlbeans committer
I was looking into XMLBeans for our service connections to EJBs. But, the Service Data Objects are a better comprehensive solution.
So, what ever happened to SDO?
I am very pleased to see it get promoted. I used it just recently for a simple task. I needed to create a data dictionary for our datatabase, and found that I could query it for the structure. I used XMLBeans to produce an XML document that I could easilly transform into a readable document.
I built a simple schema and ran the build.xml ant script on it, and voila! I had my classes. It was then a very simple matter to populate the objects and save them to get my XML, then I simply applied my transform.
This is a great project! Here are a few out of context lines from the code that creates the XML objects
col = cols.addNewColumn();
XmlOptions xmlOpts = new XmlOptions();
doc.save(new File("c:/test-schema.xml"), xmlOpts);
I took a quick look at your wiki. You mention XQuery at one point. Could you give more details?
Also, will there be support for RelaxNG in a future release?
since xmlbeans keeps an xml store around it can work well with xquery. the original xmlbeans implementation had (and still has) an execQuery api that called out to bea's proprietary xquery engine (xqrl). when xmlbeans was moved over to apache xqrl did not move over with it and research is in process on which xquery engine that would make sense to work with in apache. saxon seems to be the leading contender.
xpath 1.0 is available now using the selectPath() api (this is provided through Jaxen integration). so, from any of your generated classes (any xmlobject or xmlcursor) you can do an xpath. if the result of the xpath is known to xmlbeans you will get back a typed object (otherwise you get back an untyped xmlobject). this allows from some pretty cool scenarios where you can get a document and use a selectPath() to get directly to the object you want to party on rather than going through the standard getters from the top down.
in terms of relax/ng we have not yet got that on the feature list (we should add it as a research item). this would be a good xmlbeans dev list question (xmlbeans-dev at xml dot apache dot org).