The Irony Of Separation Of Concerns, Best Practices and Anti Patterns in Java EE 📎
Most J2EE architects were just obsessed about separation of concerns which led to (too) many fine grained layers and indirections. The applications were packaged as EARs which were containers for different deployment units. Especially the web tier was deployed separately from the business logic - an average application even consisted of several ejb-jars, which reflected some architectural concepts (layer, component etc.). The application servers, at the other hand, were rather monolithic. The exception was JBoss, with it microkernel architecture, all others were in general used "as is" - a huge blob :-).
Java EE 6 turned some J2EE anti patterns into best practices for certain contexts. So bundling EJB 3.1 components together with web components in a WAR, without the need for EAR and EJB-JAR creation is possible and makes absolutely sense for "just" web applications. Separation Of Concerns is actually violated - but the productivity could be increased at the same time. So the deployment of Java EE 6 applications could become more monolithic - and be still considered as "best practice".
On the other hand, application servers became modular. Glassfish v3, with its hk2 and OSGI architecture, is able to load and unload its modules on the fly. Even the admin console is loaded on demand. This dynamic behavior is "caused" by Java EE 6 profiles - a predefined, standardized set of APIs and capabilities.
So in Java EE 6 the web and business logic could fusion together and become "monolithic" - the application servers become modular. Something like "Inversion Of Best Practices" :-). Nonetheless - it's good stuff in both cases. Instead of layers, more and more architects, fall in love with modules and plugins right now. Let's wait for the next "Inversion Of Best Practice" :-).