Related Topics: Apache Web Server Journal, XML Magazine, Java Developer Magazine

Apache Web Server: Article

XML Heaven or XML Hell?

Why anti-XML sentiment is misguided

There is no doubt that annotations are well suited to simple configuration. They provide the great advantage of co-locating the code and the configuration data, and from the tooling perspective, a code editor that understands Java 5 provides everything you need. However, reuse is the elephant in the room. Say, for example, you have a business entity to which you want to add information about validation rules or a hint as to how it should be used in the user interface. If you use annotations to add this information, that entity can't be reused in a different context with a different set of requirements - the annotation is very tightly coupled to the primary use case. Annotations may well be all you need for simple applications, but you need more for the enterprise. It's clear that abstraction does indeed have its place, and XML-based metadata is the best way to provide it.

The XML Metadata Vision
In an enterprise framework such as Oracle Application Development Framework, XML can offer significant benefits.

•  The power of abstraction. The abstraction offered by XML metadata not only allows objects to be mapped or reused in many ways, it also provides a decoration point. Both the definition and the usage metadata for framework objects can be decorated with artifacts such as user interface hints and validation, which can be expressed using XML and incorporated into that same metadata. This has even more benefit when the objects being consumed (for example, a callout to a Web Service) can't be directly accessed by the framework. We can easily add behaviors and validation to the remote service without having to generate client stubs and wrapper code in Java.

Of course, let's not hide from the inevitable objection that abstraction through XML can lead to problems such as the management of dependency analysis and refactoring. This can be a real showstopper if all you have to work with is a dumb Java IDE editor. Again, this is not a significant issue for today's advanced IDEs; they have a holistic understanding of object and metadata interrelationships and can manage refactoring processes on the
programmers' behalf. There are also issues such as performing a diff/merge process of metadata from source control systems, but this is not something you would consider doing manually. With tooling support, though, it's not a problem.

•  Future-proofing. Another benefit of abstraction through XML metadata is that it allows the underlying implementation of the framework to evolve without requiring framework users to recode. We can change the framework's implementation or deploy to new platforms without rebuilding or recompiling. Even if the metadata has to change - to add enhancements, for example - it's easy to transform the XML.

•  Visualization of complex relationships. I mentioned before how important visual flow designers were in helping Struts adoption, but the other aspect of this observation is from the perspective of someone who is developing tooling for a framework. It's easier to build a diagram or visual editor directly on top of XML metadata than it is to parse Java code and build an intermediate memory model of the relationships. For most open source frameworks, tooling is an afterthought, but for us it's as important as the runtime itself, so this is a significant factor.

•  The metadata is the code. XML-based metadata should not be viewed as just the configuration data or glue - it can be the application code itself. With frameworks, we can boost developer productivity by internalizing common activities such as talking to a database. The developer can then effectively code through the XML's manipulation of the framework at runtime. What that the developer "writes" - using the structured wizards and diagrams surfaced through the IDE - is the XML itself. When it comes time to deploy the application that same XML is packaged and deployed. There is no transformation or code generation to change the design time meta-model into code, because the XML is already in the correct form to run on the framework. In such frameworks, conventional Java coding is concentrated solely on the business problem rather than on infrastructure tasks.

Moreover, having an XML-based runtime model opens the door to runtime manipulation of that model though metadata management. We can use a layered metadata repository to provide customization, personalization, and even design time at runtime capabilities for deployed applications. This is simply not possible in the same way with an application fully coded in Java.

What's Next?
The vision of XML metadata as the primary code artifact is an exciting and compelling one, but there is a slight hitch. One of the biggest weaknesses of XML-driven frameworks today is debugging. Developers are insulated from the gory details of the framework implementation by the metadata until something goes wrong. Invariably, as soon as you try to debug such a framework you're thrown headlong into a huge stack of mystifying data structures that bear little or no resemblance to that nice clean representation you saw in the design time XML. This is the next great problem for framework developers to solve. How can we represent debugging at the same level of abstraction as the design time experience? It is this as a challenge that I, for one, am really looking forward to.

More Stories By Duncan Mills

Duncan Mills is senior director of product management for Oracle's Application Development Tools - including the JDeveloper IDE, and the Oracle Application Development Framework. He has been in the IT industry for the past 19 years working with Oracle, Java, and a variety of more obscure programming languages and frameworks along the way. Duncan is the co-author of the Oracle Press book: Oracle JDeveloper 10g for Forms and PL/SQL Developers - a Guide to Web Development with Oracle ADF.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
hkara 11/25/08 11:36:20 AM EST

Well, there is truth in this article, but there is
also truth in the developers that speak of
"XML hell". XML is great when computers speak to
computers, and it was made in great part for that :
to quickly write reliable and fast parsers for
structured documents. Unfortunately, just like when
Tim Berners Lee never thought that people would
actually *write* html using text editors, people
started writing xml with text editors.
Why ? Because there's nothing else, most of the
time. Imagine what would have happened if XML had
existed when relational databases were invented...
Imagine expressing SQL queries in XML (this actually
exists, but it's for machines).

When people are not in contact with XML directly,
XML isn't a problem. When we edit an SVG document
in Inkscape, when I change my preferences in Eclipe,
I use an XML document, but through a specialized
user interface that does not make the whole thing
cumbersome and painful. Yet the documents produced
have all the advandages of XML : portability, reliability, ease of parsing, etc. So I guess the
problem is more : how easy is it to configure the
system ? If you have to edit XML directly, chance
are that this is difficult. It may be powerful,
portable, etc, but it is still difficult.
I agree that annotations are not the right thing.
For me, the right thing is either a specialized
language using an LL or LR parser, or a specialized
editor that manipulates the XML for the user.

Besides that, I think that your article is hitting the right point.

Best regards,