Good article. While I have only a passing knowledge of Spring and some of the pieces of J2EE you employ, I agree completely with your thesis that there many promising approaches lie in hybrids of what is available or alternatives to JCP products. In fact, I made a similar case (http://www.mentata.com/ldaphttp/why/) in a less receptive environment several years ago. Although subsets of J2EE have been done since the beginning (e.g. Tomcat), I'm happy to see the Java world move further in this direction because that is what I believe burgeoning libraries of reusable object-oriented code are all about. I really liked the way the application grew incrementally in your article. I also agree with a tendency to keep things simple and avoid slick but obfuscating patterns, especially in introduction.

Alas, it seems to me that this application's paradigm has some of its own built-in complexitites like the separated datasource, transaction management, added messaging, dependencies on atomikos products, and the client harness. Encapsulation is a great thing, yet ideally it should still be possible to look at each source file and know pretty thoroughly what it accomplishes without detailed investigation of the other components. Also, any time I read somebody telling me not to worry about code volume because you can just "cut and paste", I get concerned.

The J2EE itself started simply too, but grew in complexity over time to fill a broader range of requirements. Such is the nature of software, and surely Spring or Struts or Hibernate or Java Faces or whatever could each bloat to become the perl CGI scripting of tomorrow.

As a developer who has spent a lot of time in what I refer to as "software archeology", the richness of modern development can be a double-edged sword. As a future educator, I'm pondering how best to separate the essence of enterprise computing capabilities from the implementation details of particular frameworks: something like blueprints, but without inherent product placement. My own work is intended to be a modest stab a that, but as it slowly evolves the industry naturally continues to push for levels of capability and efficiency that can ultimately and ironically snowball to limitation and burden. Enterprises come in all sizes, and the smaller ones are often ill served by this dynamic.

So a toast to a new era of eclectic toolkits to benefit the little guy. I only hope we can keep from crushing him with maintenance nightmares while quality-driven Indian development firms systematically eat our collective lunches.