The metadata dilemma
Java EE development has been packed with lots of metadata since day one. Things have changed a lot over times and we have been provided with more elegant solutions. I don’t want to go deeply into the ongoing debate on Annotations versus XML but rather go one step back and discuss metadata on a more conceptual level.
What is metadata?
Wikipedia names “data about data” and further explains:
In data processing, metadata is definitional data that provides information about or documentation of other data managed within an application or environment.
In case of application development metadata mostly is a model of some functional or nonfunctional aspect of the application domain. JavaEE defines metadata models to express persistence, transactionality, security. These are mostly technical aspects but often tied to business requirements.
To tie or not to tie?
Thus one could raise the question of how to capture the metadata in a way that it’s relation to functional requirements can be derived easily on the on hand and nevertheless be separated from core domain logic to avoid tangling on the other hand.
Spring was rolemodel in stating that the distinction between business and technical aspects are key to maintainable software. Due to its origin (no annotations available those days) it provided a clean component model based on XML to apply technical aspects with AOP means. Thus the separation was logical AND physical.
JavaEE and Spring 2.0 (and upwards) leverage annotations to express metadata concerns as the preferred way (especially in case of JavaEE). Annotations are tied to the actual code and thus mostly compiled into the class files. Here we separate the metadata aspects logically from the actual code but physically tie it to the class.
The is an ongoing debate if this tight coupling is really suitable, especially defining crosscutting concerns (the JavaEE interceptor model) in one place and binding (and thus tangling) them around classes all over the application.
Nevertheless I definately see advantage in defining e.g. security attributes right at the class - or even more public - at the interface of a component. This would tighten the contract between client and implementation much more. From a business perspective I maybe want the user management component only allow an administrator to delete users, completely independent from what the implementation looks like. Thus it would enrich the interface’s semantics.
Problems
I see two issues in this: first, what if the client is not interested in this particular aspect modeled to the interface at all. As the annotation is compiled into the class to be evaluated at runtime, clients would need the annotation JAR in their classpath. Taking persistence as example I actually don’t see no point why a plain client should be bothered to have the JPA JAR in its classpath just to deal with JPA annotated entities. Very often I end up with more JARs in my classpath that are simply required by metadata annotations rather than implementation libraries.
The second thing is the pure amount of annotations. Suppose you want to persist an entity with JPA and serialize it via JAXB. Welcome to annotation hell ;). Oh, I forgot there is a validation JSR based on annotations on its way round the corner. Erm… do you see the problem?
Conclusion?
While the first issue can be somewhat limited by a set of standardized annotations available via the JRE, I can not really see a way out of problem two today. Of course we raised the abstraction of expressing metadata around application logic, the next quest seems to manage the pure amount of metadata created.
What do you think?
