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.