11.18.06
The typical bleeding-edge Web Application Framework Stack
Most developers now agree they should avoid heavyweight frameworks like EJB2. Maintenance is a nightmare, and more importantly, developers don’t enjoy anything that deals with the generation of stubs and skels (The same applies to technologies like CORBA).
So, what is the recommended technology stack for developing web applications today ? It looks like nowaday’s buzz goes toward :
- Apache Maven2 for build-management, and managing profiles (development, integration, production) and its set of plugins which ease application development, like Jetty6 plugin, which avoids constantly redeploying wars to tomcat.
- A so-called “lightweight” JEE framework, like the famous Spring Framework, that everybody raaaves about.
- A Object Relational Mapping framework, like Hibernate, or any of the Java Persistence API implementations (Hibernate EntityManager, OpenEJB, or Oracle TopLink)
- An MVC framework, which is either Action/Request Based (The 2 most popular ones being Spring MVC and Webwork2/Struts2 ), or Component Based (The 2 most popular ones being Apache Tapestry and Java Server Faces )
- A security framework like Acegi to handle authentication and authorization.
- In addition, other secondary frameworks are often used, like DWR for transparent AJAX, or the client side Dojo Toolkit Javascript framework.
From a methodology viewpoint, the current hype is about :
- Test-Driven-Development, thanks to some Unit testing frameworks like JUnit+Easymock, and functional-testing framework like Canoo Webtest.
- Inversion Of Control : Each technical (technical or functional) component must be described by an interface, and the inversion of control container - usually Spring - takes care of instantiating the right objects to avoid the need to create hundreds of Factories and Singletons).
- Aspect-Oriented Development (AOP) : User code should not be polluted by cross cutting aspects such as Security, performance, Transaction Management, etc. AOP is what allows to factor out this kind of code into reusable aspects.
- Domain Driven Development (DDD), to design rich domain POJOs. Since designing rich domain objects implies that the objects will be smart and will need to access technical objects like DAOs, and directly accessing the implementations would lower the testability of the application, DDD often means using something similar to Spring’s @Configurable annotation in addition to Spring’s AspectJ integration, to magically dependency-inject domain objects (which cannot be managed by spring, since they can be instantiated everywhere)
From my experience, integrating all these frameworks doesn’t work out-of-the-box. It is often necessary to play with the miscellaneous versions of each framework, and it sometimes causes headaches. Classpath issues and human errors are also a great cause of trouble.
If the proliferation of frameworks continues (and I believe it will) , integrated stacks (like AppFuse, but backed by commercial support) will emerge as a de-facto need for kickstarting developments. How many developers out there actually use the whole IoC/AOP/DDD/TDD fuzz ? By looking at the amount of problems I get by using all these frameworks, I have the feeling that not so many people do ……
A simple example of that, is for instance, the use of Spring AOP declarative Annotation-based (@Transactional) transaction management. Nobody tells you that you cannot use @Transactional on a Spring MVC controller, or that you have to activate CGLib proxying to use @Transactional on Webwork Actions. Sure, once you’ve run into the problem and analyzed the cause, the reasons seem obvious, but I still believe that something needs to be fixed with the integration of all these frameworks. Everything works as expected in isolation, but once you start to deal with dozens of frameworks, problems arise more often, and their cause isn’t always obvious. The access to the right frameworks should be eased to improve the overall quality of applications in the software industry.
Sami Dalouche » HOWTO: Use Direct Web Remoting (DWR) with Spring Framework and Java5 Annotations said,
November 27, 2006 at 2:38 am
[…] As a sidenote, DWR is part of the typical Bleeding Edge Web-Framework Stack that I wrote about in a previous post. Surely, not everybody uses this Stack, but it gives an idea of what the current trend in the Java world is. The current java world is full of innovation. Every 2 days, a new framework arrives on the scene, and beginners are more and more afraid of the overall complexity of the platform (if we can call this a platform, because it more looks like a set of unrelated tools that people struggle to use together, in opposition to Microsoft .Net’s stack that we can safely call a “solution” because of the tight integration between the components). Innovation is doublessly a very good thing, and nothing should prevent innovation from happening. However, I believe it is also very important to document the best practices and tools and try to gather the community around a limited set of paradigms and frameworks. It doesn’t make sense to have a different framework for each programmer in this world. And in my humble opinion, using such an RMI-like system for communicating between Java classes and Javascript is definitely one of the best and efficient (from the developers viewpoint) practices around. Java class […]