Can an Apache XMLBeans Help Speed Java Devs on XML?
Concerned that Microsoft is way ahead of Java in supporting XML, BEA has handed over its internally-developed XMLBeans technologies to the Apache Software Foundation (ASF) to make it available as Open Source to devs. BEA VP Byron Sebastian told us why BEA is concerned about availability of XML support for Java devs, and how an Apache-run XMLBeans may help.
BEA wants to jump-start the Java community's work on supporting XML standards and dev tools. Concerned that today's Java efforts are moving too slowly, BEA has handed over its internally developed XMLBeans technologies to the Apache Software Foundation (ASF).
"XML support is an important area to move in quickly, as Microsoft is far ahead of [the Java community]," Byron Sebastian, BEA's vice president for WebLogic Workshop/Portal, told IDN. "XMLBeans is definitely an opportunity to provide Java developers a way to take their base functionality [with controls] and more easily extend them" to XML/web services.
XMLBeans is an XML-Java binding tool, enabling Java devs to map the features of XML and XML Schema to the equivalent Java language and typing constructs. In specific, BEA designed XMLBeans to use XML Schema to compile Java interfaces and classes that in turn can be used to access and modify XML instance data. "This is not a plug-in approach, but a [Java] controls approach, extending properties and [adding] specs for adding controls to the IDE," Sebastian said.
In addition, XMLBeans was built to provide devs a similar user experience to other Java interfaces/classes, providing 'getFoo' or 'setFoo' just as when working with Java. XMLBeans also provides APIs that allow devs access to the full XML infoset (XMLBeans keeps full XML Infoset fidelity), and to reflect into an XML schema through an XML Schema Object model.
Where Java Fails on XML
Currently, Java devs need to make a choice if they want to program with XML. They could get full access to the XML by writing code that uses tedious and fragile APIs such as SAX or DOM, or they could use a marshalling solution to bind XML to Java classes. But there's a trade-off in that approach: Devs would lose the advantages of XML and its schema information.
According to ASF, "Fundamentally, there is a mismatch between XML and the Java data models, and until now, you've had to pay the price in either flexibility or robustness." XMLBeans is a step toward enabling Java devs to not make that trade-off, ASF added.
"We only invent something if it has a chance to be 2-3 times better than what's already out there as a standard," Sebastian told IDN. "In Struts, for instance, could we have built something better? Yes, we probably could have. But would it have been 2-3 times better than Struts? Probably not. But XML tools for Java [devs] is a relatively new area, so there's lots of opportunity to improve on what's out there," Sebastian said.
For more details on XMLBeans, see the ASF's XMLBeans Explanation. XML Beans as an Apache Project, complete with code downloads, backgrounder, documentation and related FAQ can be found at http://xml.apache.org/xmlbeans/.
BEA's XMLBeans Hand-off:
Why Open Source vs. JCP?
"It's clear that the Java community is more than just 10-15 vendors -- it's the developers out there," Sebastian said. He points to work done with Java's Struts, which was developed by Apache and individual Java developers, as a model for what BEA hopes will happen with XMLBeans. "Struts was developed by Apache [developers] to solve a special developer problem, and now the Java community uses it."
BEA hopes the hand-over of XMLBeans to "Open Source" status will help start the building of better bridges between traditional Java devs on the one side and new web services/XML-driven projects on the other. "XML is an important part of web services support for developers, and we need tools that will help [Java] devs support services as Java objects," Sebastian said. "In addition, at BEA, web services are an important part of our implementation strategy, and we need to make sure that Java developers have powerful and easy-to-use tools."
We asked Sebastian if BEA is seeing evidence that Java devs are interested in building XML/web services projects. Sebastian said he sees the momentum and expects 2004 to be a big year for web services/XML projects among Java devs. "A year and a half ago, there may not have been enough standards in Java to support web services. But today, with many Java vendors working with Microsoft and others, through WS-I and other groups, we're getting critical mass," he told IDN.
We also asked Sebastian why BEA offered XMLBeans to ASF, rather than Java-focused groups, such as Java Community Process (JCP) or even Eclipse?
Sebastian's reply left little doubt that BEA feels that ASF and other Open Source forums are best for XMLBeans and potentially for other innovative technologies it may want to release to the dev community in 2004.
"The main value the Java Community Process is providing still is at the mercy of a single vendor," Sebastian told IDN. Sebastian's response comes as BEA has already waited more than a year for JCP to take action on its proposed JSR to the JCP for handling metadata (JSR 181). As for Eclipse, BEA has committed its architecture to Swing, not the underlying XWT used by Eclipse/IBM. "All our tools [leverage] Swing, and now the proprietary XWT has a real potential for confusing ISVs."
While devs will get the core underlying code as a free, open download, the GUI-driven support that comes via WebLogic Workshop will not be included.
With the XMLBean interfaces in a Java application, devs can write code that uses the new types to handle XML based on the schema. In one use case example, a Java printItems method receives a "file" object that contains the purchase order XML file.