BEA today released XMLBeans, an alternative to SAX/DOM that provides a Java object-based view of XML data without losing access to the richness of the original, native XML structure. XMLBeans can convert a schema into a static java-object binding that is actually a 'view' over the original XML data, manipulating the XML data behind the scenes as the object model is used.
Essentially, XMLBeans lets you take a schema and instantly get a static binding to it, with a dynamic binding way to access it. A true static binding option is also available.
Check out XMLBeans Technology Preview
, hosted on BEA dev2dev.
BEA's Press Release announcing XMLBeans and a webinar about it
BEA Service Aims to Ease XML-Java Fusion
BEA Hosts Free Service That Turns XML Into Java
Beans make XML into Java
A similar, less proprietary tool, can be found at http://www.dom4j.org
XMLBean is similar to JAXB. In fact, it is JAXB + XPath. Seems to be pretty nice, although one can only compile schemas from BEA's web site.
dom4j is like DOM.
Have to wait to hear how much BEA is going to charge before plunging in, although I have tried JAXB and it is very NICE and it is FREE.
These technologies are in the same category, but they definitely aren't similar.
XMLBeans is a complementary technology to JAXB. However, they overcome a significant lacking in the technology: full fidelity of documents, 100% schema representation and 100% document representation.
With JAXB and other technologies, the XML document is gone once you load it into Java. You can regenerate the document, but the specification doesn't guarantee that the XML documetn will be exactly the same: including wild cards, comments, etc. Document preservation is critically important, especially when dealing with <xsd:any> tags in a schema document. JAXB is particularly unclear about this element.
JAXB could do a good job of this, it's just not guaranteed. XMLBeans focus on document preservation and extensibility, which are non-goals of JAXB. This makes the technologies very compatible and worth taking a look at. This also makes XMLBeans very different from the open source technology referenced above.
Just curious, how much BEA is going to change for this technology?
I do agree with you that the lack of XQuery support is a big drawback in JAXB.
This does sound interesting and worthwhile. I remember some of the older HTML-generating GUI tools that would totally muck up a web page. I shudder to think what could happen with the equivalent symptoms in the b2b world when XML is being passed around.
The XMLBeans service is a free service that BEA is offering. It is technology that we will be incorporating into our core platform, the service made available today will continue to be free.
We are also investigating some other channels for distribution to the developer community, but haven't solidified on anything yet.
| "XMLBeans is a complementary technology to JAXB."
Tyler, can you describe with a simple example in what way XMLBeans is complementary to JAXB? Do you mean that you could use the standard JAXB API's to unmarshall a document, but then somehow then in memory use XMLBeans features on it?
Or would the JAXB and XMLBeans "worlds" be two separate stacks available in the developers toolbox for working with the same XML documents, offering slightly different API's and feature sets?
I ran a sample schema just now through your XSDUpload.jsp page and the interfaces produced don't seem to be JAXB compatible.
What would be a usecase where you would use some implementation of the JAXB standard -- like Sun's reference implementation or Oracle's XDK for Java 10i Beta or others -- together with XMLBeans on the exact same document in memory without reparsing? I didn't grok that angle from your previous replies.
Hi. When I said that JAXB was complementary, that was very high level. Today, we follow the JAXB naming scheme and its conceivable that XMLBeans could be a type of JAXB implementation in the future. In fact, we have a relationship with the JAXB team and we are working with them on a better understanding of the technology.
Just to give some better clarity as to what is meant by fidelity, I copied this text from David Bau, one of the minds behind XMLBeans. After reading this text, it definitely enlightened me as to some of the consequences of XML binding:
Full fidelity gives several advantages:
(1) Sequencing and interleaving information is not lost in XMLBeans. There are schemas where you care whether <input> comes before <output> or <buy> comes before <sell> or the other way around. If you just give people a Java .getBuy() and a .getSell(), they've lost the ability to tell which came first. In XMLBeans, after the .get you always have the ability to grab an xml cursor on the <buy> and another one on the <sell> and ask which one came first.
(2) Information that comes into wildcards aren't lost in XMLBeans. That's the <xsd:any> and <xsd:anyAttribute> features of schema that Mark refers to. You can get see where and how your document has been extended at the wildcards, and change or manipulate the wildcarded data. Furthermore, something cool is that if you have compiled schemas for the wildcarded data you can even coerce the wildcards to strongly-typed XMLBeans and keep on drilling in conveniently. We do plenty of this kind of stuff when processing WSDLs: the w3c schema for WSDL uses wildcards for nearly every interesting piece of data in a WSDL.
(3) Loading, modifying, and saving an XML document using XMLBeans, you won't lose all the "other stuff" that human beings don't want to lose on human-readable XML files, namely comments and all that extra pretty whitespace between things. (Unless you want to lose it; xbeans can be put in a mode where it is used to strip extra whitespace too.)
(4) The architecture is set up so that 100% of schema types can correspond one-to-one with a Java type. This is perhaps a subtle benefit, but it is powerful because it means that there are "no regrets" and "no dead-ends" later. You never run into a schema type can't be subclassed because of Java problems, or some extension that has some data that can't be accessed from Java. A specific example of a dead-end that can occur with other approaches: in schema, you can extend a simple type like a number by adding an attribute... Beginning with instances like:
The type of "quantity" might be a schema "xsd:double", translated to a Java "double". But here's a subclassed instance:
<quantity xsi:type="dimensioned" units="pounds">22.4</quantity>
In schema you can subclass "xsd:double", but in Java you can't. So in a typical translated Java API, there is no way to discover that quantity is "dimensioned" in the second instance, and there is no way to access the "units" attribute. But in XMLBeans you could (if you really needed to) write:
// getQuantity is a Java double
System.out.println("Quantity is " + item.getQuantity());
// xgetQuantity is an XmlDouble that has a subclass called Dimensioned
if (item.xgetQuantity() instanceof Dimensioned)
System.out.println("Dimension is " + item.xgetQuantity().getUnits());
There are other situations with this kind of problem in XML Schema. The idea is, you don't want dead-ends... your data can evolve, and when it does you don't need to throw away your app code.
It's really about which is the important piece in your model: the XML or the business object. If it's the XML, then keeping the XML as the model behind the object keeps the highest data fidelity. If it's the business object, then the XML is secondary. Identify the requirements; then choose the tool. This one sounds pretty handy if the XML fidelity is important.
: Easily share live data across a cluster!
Sounds interesting, i've had come thro' a similar XML fidelity scenario recently. Tyler or BEA Folks, any push from your side to standardize this tech.? Even though offered free, it'd be nice to have wide support.
BEA is very much involved in all of the standards including JAXB. We are working on a number of ways to standardize different XMLBeans technology. However, we feel that it's equally important to get this technology to market to gather additional feedback and perspective from the community to help us guide the direction that we should take when standardizing this technology.
I think, BEA is trying to overtake Sun Micro System by making new standards.
Someone has to be creative, right? Might as well be BEA.
Why don't they improve and enhance JAXB instead of inventing a new proprietary standard? Oh I forgot, they're trying to make money. Sorry.
Having a working proprietary solution that does what you need now is much better that having a standard process started and first implementations showing in a few month at earliest. Yes it would be nice to have XMLBeans influencing JAXB 2.0, but it's even better to use it now.
Also it seems to me that many succesfull standards come from exisitng proprietary technology, and many that started on paper are failures (don't want to start a war, but look at message beans vs entity beans, or JDO vs entity beans).