How can you make your classes, YOUR classes!

Answer to 'Dude, where’s my class?'
After writing AADA, and starting some applications in some projects, I encountered this blog entry from Uri Boness Dev Thoughts » Blog Archive » Dude, where’s my class?
Here was my answer:
So I read a lot of your Dev Thougths and I'm surprisingly impressed. The subjects are right on today's Java critical issues and your analysis is open minded and fun to read.
But, after a lot of thoughts, I disagree about your bottom line on Annotations vs. XML and JBoss MC vs. Spring.

Spring
Spring is what I call an “Educational Framework”. People ask about Spring: “What does it do?”. Answer: Well, in fact, basically, heuh... instantiating Java classes from names written in an XML file...
WOW, that's a hell of a framework!
You can argue about the answer, but the point is: I like Spring not because of what it does, but because of what it makes me do.
I mean that Spring is educating Java developers to organized their classes and interfaces. It cleans my code from spaghetti plate dependencies, it enables me to play like Lego with my implementations, and gives high level of control of where a specific code should be.
From my experience, the first framework that had this effect was Struts. Before Struts, the amount of very ugly code in Web Application was amazing. But, when I arrive to customers using Struts I'm sure of 2 things:
They will have extended and overridden most of the basic classes of Struts (Action Servlet, Request Processor, Action, ...), reducing to a very thin amount what they actually used from Struts;
They will have some kind of MVC separation in their code.
For more than 3 years now, it proves to be faster and more efficient to write your own small MVC web framework than to use Struts. The main benefit of Struts was that it educated a lot of Java Web users on how to organized their code and architecture.

Today, Spring is on a lot better ground than Struts for one main reason: It was meant and build to be discreet: “Don't pollute my POJO”?
Now, having a good ground like the Spring framework, enables Spring to build additional framework pieces like WebFlow, Swing, Web, Transaction, Remoting, Validation and so on. But here, there is a danger:

• Should I start using Spring for what it does?
• And if I want WebWork?
• And if I want JBoss Remoting?
• And if I want Hibernate Validation?
• And so on...

I know the answers to the questions above but it's not clear anymore for a lot of people.
So, for me, some of these additions are not Spring Framework anymore.
Don't misunderstand me, I really like the Spring classes interfacing Hibernate, JTA, JDBC, the exception handling (Rod Johnson view of no more checked exception is brilliant), and they should be part of the basic Spring Framework.
But, for example:
Spring Web is great but should not be in Spring Framework,
Transaction declarations are perfect, but I saw too many high-end deployment relying solely on Tomcat + Spring Transaction crashing in production.

For me the basic Spring Framework should only be a good Micro Container with interfaces, and it should be clear that it doesn't replace real container services. Adding too much to Spring Framework will kill the motto of Spring: “Spring should not compete with good existing solutions”.

JBoss MC
The amount of code for a basic MC is relatively small (instantiating classes from names) and JBoss cannot build their platform on top of Spring! They need to offer full support on this.
So, they did it again. It's logical, it's good, and let's see other solutions. JBoss MC has completely different constraints and requirements than Spring. They will, can and should provide technical features that competes with other solutions.
JBoss led the POJO concept against the big guys (IBM, BEA, Oracle, ...), and it's not because they won (AS leaders) that the community should stop the support.
The bad guy is IBM WAS, not JBoss. I had the misfortune to look at some WAS Java code, and this is way more pathetic than JBoss MC. Those guys really completely missed the concept of MC and well organize Java code. I will jump with joy when Geronimo and JBoss will throw this ersatz of AS to history...

Annotations vs. XML
I'm thinking about this “Dude, where is my class?” issue for quite some time now (see AADA), and like you did, I went back and forth between XML and Annotations for managing metadata/configuration.

Today I'm sure of what I want: Annotations.
And this is for one simple reason: The XML way is at a dead end.

Everything was already done (and Spring the first) to maximize the capabilities of XML driven configuration/metadata, and it's still not good enough.
On the other hand, we just started with annotations and its teaming with ideas, feature requests, improvements and so on. “.NET” and then Java 5, just open a huge amount of opportunities on how to design and write applications and technical infrastructures.
In all projects using Java 5, it starts with puzzled developer faces but after a while, I'm always amazed by the ideas and implementations coming out of annotation usages. Once the developers gets it, amazing improvements goes on and on. This does not happens with XML.
We are just starting to play with this stuff. And, like you point out in “Java Annotations - We’re not quite there yet!”, Sun needs to add a lot more to Annotation in the language itself.
And here is my big disagreement with your view: Let's not throw Annotations away because of Sun short views. Let's push it forward. Let's keep asking for all the improvements we want, and may be, one day, Sun will give up under the pressure and make Java open source... (Wishful thinking isn't it?).

About the discussion around the “@injected” annotation (Bob vs. Spring). I don't understand the dilemma here. I'm an application developer and I need something that is not under my control (from the infrastructure or from another module/project/application). In Spring XML way, I need to declare injection in a shared XML file with configuration that I don't even understand.
Isn't it simpler just to write “@injected AnotherInterface myMember;” and expect the system to provide it, without going anywhere else than my class.
For me, “@injected” is the most understandable metadata information: This is “out-of-my-juris-dick-tion”, but I need it. Please give it to me.
In one project we refactored a huge J2SE application to be container enable. We used Spring to “Springify” the code so it will be “soft” enough to be inserted into JBoss. During this process we missed a lot the “@injected” annotation feature. The amount of repetitive XML and setter/getter was very tiring.

So, annotations are not polluting your code if you make them yours. And to link your personal annotations to infrastructure annotations is Spring (or other infrastructure) framework job.

About IDE, I'm using IntelliJ and the Spring navigation is amazing. It really gives what I need to write XML and Spring beans. But, I still prefer annotations navigation. Finding usage, controlling AOP injection, reviewing code and all other architect work is a lot easier with annotations then with any XML based system.
Lately, we refactored an application that used expression based AOP (declared in XML of course). The mental mapping (where are my pointcuts?) was giving us headache. We just wrote some well defined annotations, used them all over the code and redefined our expressions to point to them. It was an amazingly refreshing experience. We solved all the bugs related to AOP (mainly wrong cutting) and now the application developers can managed their Aspects without us.
Here also you can go on with “Is a pointcut position metadata?”. Well, I think I don't care about it. Annotations answered our need in a beautiful way, and I will stick to them.

MDA is dead, long live AADA

With recent additions of powerful language structures to the Java platform, the time is ripe for a fresh development methodology. The promise of design techniques - like Waterfall, Spiral, RUP and MDA - for an agile and efficient Object-Oriented development process is within reach.

Features like Annotations, AOP, Generics and IoC bring upon an opportunity to reevaluate our architecture design strategy. In this article I will introduce AADA (Annotations and Aspects Driven Architecture) a compelling alternative to MDA. AADA is a refactoring-oriented design methodology that effectively eliminates the need for massive code generation.

Present Shortcomings

I've been a software developer since 1992. Since then I’ve had my chances of using almost all methodologies, techniques and consequent buzzwords often mentioned in Information Technologies. Methodologies like Waterfall, Spiral, RUP, MDA, OOP techniques, UML, and other J2EE tools revolved around resolving common design problems.

I really liked MDA and used it in some projects. It proves to work only when doing a bottom-up approach. I mean that once some “kind of” framework or infrastructure was in place, you can build MDA Components that will deliver software for this infrastructure. It enables a high-level OO view of the running system. This view is not a write-only document generated in the early stages of the waterfall cycle, but a view of what is really running. With MDA you can remove the “boilerplate” code a-posteriori by defining MDA components. The problem is that defining MDA components elements (tagged value, stereotype, operations) is a difficult and non-trivial work that is hardly or never maintained, so MDA components proved to have a short usage time.

XP is another great improvement for developers. It focuses development teams on the needed missions, and on the needed missions only. It forces by means of refactoring to analyze and rethink all the “manual code generation” (or monkey programming) that’s been built up underway. XP avoids the trap of overshooting the design and the planned technical features. I find XP refactoring to be the best software design mechanism. What I mean is that refactoring code is actually designing software out of real raw material, like sculpting clay.

The job, simply put, is to find the best way to preserve the running system’s abilities with less amount of code. This is ultimate software productivity. It’s funny, as I was being paid to find the best way to eliminate the maximum amount of developers’ code. Without the code of a previous XP iteration though, it’s impossible to do the refactoring correctly. The argument: “Why didn’t you tell me that before I wrote all this code?” doesn’t hold. Guessing what is needed in a piece of software before writing it (sometimes referred to as Detailed Design) doesn’t make sense – it’s a waste of time. XP methodologies gave a big productivity boost to a lot of teams around the world.

So what’s new?

It seems as if very few exciting or new innovations came about since I started J2EE consulting in 1999. But today software development and consulting is becoming fun again. Nowadays, concepts like eXtreme Programming (XP), Inversion of Control (IoC) and Aspect Oriented Design (AOP) combined with features like annotations and generics (introduced with Java 5) are becoming common to current development environments.

During the last year, I realized that MDA or UML design is no longer needed. The level of expression obtained in an annotated Java class is actually better than it's PIM UML class counterpart. The mentioned advancements present the following advantages:

1. Expressiveness and Extensibility – Java annotations are more powerful than UML extensions defined in MDA (stereotypes and tagged values). Annotations are strongly typed and thus have the advantage of compile-time checks. Modern IDE’s can easily and quickly enumerate all instances of an annotation usage throughout the code, without the need for reverse engineering.
2. Strongly typed class associations – By use of generics, it’s possible to define class associations such as aggregation in a strongly typed manner.
3. Cross cutting concerns – Aspects successfully replace both MDA transformations and UML definitions of pre-conditions and post-conditions.
4. Elimination of boilerplate code – declared aspects remove the need for code generation. Although this is achieved mainly by employing aspects, strongly typed annotations greatly enhance readability.
5. Decoupling technical details from business logic – Strongly typed annotations combined with dependency injection contribute to a clean and efficient configuration setting. Str ongly typed annotations decorate strongly typed elements.
6. Traceability – One of MDA’s strong features is traceability. A good source code auditing is achieved by employing a good Source Configuration Management, as is the custom in an XP environment. Since a class is usually involved in more than one feature, associating a Version Control System commit action (of both implementation and tests classes) with an XP user story provides real traceability.

The MDA dream was to have one model generating software for multiple platforms, for example, the same PIM can generate a J2EE or .NET application. In practice achieving this goal demands building conforming infrastructures that are compliant with the same model. AADA enables to achieve real platform flexibility - in terms of multiple databases, multiple O/R mappings, multiple UIs, choice of a container (EJB or Servlets) and so on – with a main prerequisite, which is also the driving force: Java 5.

These compelling concepts are well demonstrated in specifications such as EJB 3.0 and the upcoming JEE version. These standards are likely to boost this new development technique.

AADA: The Code IS The Model
So I propose a new development technique: AADA (Annotations and Aspect Driven Architecture). This technique is to actually have full decoupling between the business classes (what used to be PIM classes in MDA) and all kind of technical considerations using Java 5 annotations and AOP. A ADA’s core is to annotate the business classes with project specific annotations that are created following the XP process of refactoring. These domain-specific annotations may potentially use EJB 3.0, Seam and AOP specific annotations.

To demonstrate the process, consider the following sequence:

Analyze the code to find patterns of annotations and aspects usage to obtain a higher level of meta-annotations. For example: “@Stateful @Name("hotelBooking") @Interceptor(SeamInterceptor.class) @Conversational(ifNotBegunOutcome="main") @LoggedIn” found in a Seam example can be replaced with “@MyCompanyConve rsation” which expresses the project’s naming convention, default values and Seam as the conversation state manager.
The basic component of AADA is the Annotation Factory Manager. In MDA a transformation has the ability to add more tagged values, stereotypes and classes based on an original PIM UML model element. This can be more clearly and easily done with a Java based annotation generator, which will contain the architectural logic and can be applied via AOP.

AADA and MDA compared
To illustrate the points made I’ll use one of the most non-trivial common examples, using the following data model:

a person has a list of addresses indexed per type and each address has a state and a country:

The first requirement for managing the above data model is that AddressType, State and Country would be “static/read only” data. This information would be used by whatever underlying framework you use (like persistence manager, data entry UI, marshaller/de-marshaller, etc.). Changing an address from Texas to California, for example, should not change the actual database entry of Texas to California (Although this might be a good idea after all).

In MDA you start by stereotyping or tagging the “static/read only” classes as “My Reference Classes”, and Person and Address as “My Business Classes”. From this simple declaration the architect can begin handling the model:

In Hibernate:

• All classes declared as “My Reference Classes” are cached read only;
• All associations to “My Reference Classes” should have outer-join=”false”;

In Data Entry UI:

• Associations to “My Reference Classes” should be combo box based;
• Changing association to “My Reference Classes” means finding the static entity California and associating it with my address;

In Marshalling:

• When serializing a Person all references to “My Reference Classes” should be passed by ID.
• De-serialization of a Person should link the Reference ID with a matching static reference data.

In an MDA environment, all these issues are managed through different MDA transformations that would generate extra classes, XML files, and so on. When these new elements are generated, reverse engineering becomes a headache.

The next XP iteration might pose a requirement to be able to reload on demand the list of Address Types available. As a developer to do that you just change the Hibernate XML mapping files (and possibly the cache definition also). By now, your MDA transformations are destroyed. From experience, MDA and XP practices don’t go very well together.

How does AADA handle this? Define 2 business annotations “@MyReferenceClasses” and “@MyBusinessClasses” and apply them to your model. Write pure clean Java classes that completely define the above model, using generics. These Annotated Java classes contain the same information (even more in fact) than the previous UML model.

For each annotation write an annotation factory that will inject by using AOP:

1. All EJB 3.0 annotations needed for the classes and their relationships
2. All Seam annotations needed for the State conversation and JSF UI definitions
3. Your specific aspects that manage these 2 annotations

The immediate benefits are evident:

• Everything is Java – No UML modeling tools are required.
• Readability - The code is properly decorated to add readability. For XP refactoring needs, being able to find all usages of annotations is very powerful and effective.
• Extensibility – Adding new features means to add specific annotations in the right places (for example @Remove or @IdleTime). If used often, these combinations of annotations can be transformed into “@MyNotSoReadOnlyReferenceClass”.
• No reverse engineering – The Code IS the Model.

All this AADA concepts are well demonstrated in the EJB 3.0 specifications and the Seam framework. To gain more flexibility, avoid using framework specific annotations (like EJB 3.0’s or Seam’s) directly in your business classes, as this could limit changes to the architecture after having developed code. For example, choosing a JNDI name by naming convention (not the default one of the Fully Qualified Name) or choosing a Conversation type from a project specific enumeration is something that a standard framework shouldn’t and doesn’t do. This means that in a generic framework like EJB 3.0 or Seam, a lot of annotation associations need to be string based. In a project specific, strings can be replaced by enumerations or a naming convention. This is not strictly an academic point, it really gives the benefit of being able to trace names and design decisions. The framework’s string based annotations may still be used, but they are easily identified for refactoring purposes of the next XP iteration.

MDA enables extending standard components (Corba, EJB etc.) with your own MDA component definitions. Using AADA you should stay clear of importing specific annotations (e.g. avoid importing javax.ejb in your business classes), but still have type safe compliance check, based on your own annotations and the injected ones. Today EJB 3.0 and Seam are the first AADA components that you can extend for the specific project needs. In fact, Seam already uses this concept of meta-annotations.

Adding new technical features or changing the architecture in AADA is XP compliant. Let's take for example an addition of a Web Service interface layer to your Seam conversation, or POJO services that use Inversion of Control in Seam. In an MDA environment the only approach that works, from my experience, is bottom-up. That means integrating a web service framework (like XFire) and at first developing all the Java code inside your actual business classes to be able to test that things work correctly. Once you’re happy with the results (which rarely happens in real life) you create an MDA transformation that represents your final goal. This takes a lot of time and energy, and the resulting transformation is very difficult to refactor.

In AADA such a change would mean adding the web service annotations to the business classes, testing the change and then adding these annotations to the Annotation Factory.
A fully XP process is ensured by allowing permanent testing and refactoring capabilities that don’t block developer decisions.

Summery
MDA focuses the architecture design efforts on an abstract model from which it’s possible to derive an implementation, but with the concurring cost of relying heavily on code generation. XP methodology advocates frequent changes and goes against excessive design. An attempt to adopt both strategies eventually exposes their mutual incompatibility. With recent additions to the development environment, these shortcomings may be efficiently resolved.

AADA introduces a fresh and convincing methodology that is compatible with principles of MDA but is not as cumbersome. AADA is refactoring-oriented and flexible enough to enable agile development cycles a-la XP.

Resources

Java

• Java Tiger, version 5 introduced very powerful constructs to the Java language including annotations and generics.
• Java 5 home: http://java.sun.com/j2se/1.5.0/index.jsp
• New features introduces in Java: http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html
• Annotations are the new strongly typed declarative coding facility introduced with Java 5.
• Annotations (JSR-175) Community Process page: http://www.jcp.org/en/jsr/detail?id=175
• Generics (JSR-14) Community Process page: http://www.jcp.org/en/jsr/detail?id=14
• EJB3 is the new standard specification that would greatly simplify developing EJB’s.
• EJB3 (JSR-220) Community Process page: http://www.jcp.org/en/jsr/detail?id=220
• JBoss EJB 3.0 implementation: http://www.jboss.org/products/ejb3/overview

Methodologies

• Introduction to Model Driven Architecture (MDA): http://www-128.ibm.com/developerworks/rational/library/3100.html
• XP is a set of methodologies for an agile development process: http://www.xprogramming.com/xpmag/whatisxp.htm

Frameworks

• The Seam framework ties up the JSF framework for UI with EJB 3.0 standard as the backing model: http://www.jboss.com/products/seam
• XFire is a Java SOAP framework for an easy integration of Web Services: http://xfire.codehaus.org/