First came light-weight containers such as Spring which provide some of the useful features of application servers, but with less constraints over both design and deployment. Now we have Web Beans:
- A Web Bean does not have to be an EJB
- Web Beans should be executable outside the EE environment
This is further support for the move away from the over-engineered and invasive approach in the original J2EE specification to a simpler POJO based model. However the Web Beans proposal attempts to stay within the formal J2EE fold by choosing to delegate some services to the application server:
” … not every component needs the services that EJB provides (transaction demarcation, authorization, etc). However, Web Beans will not duplicate this functionality, so when these services are needed, the Web Bean should be written as a session bean.”
In contrast, Spring implements some services (such as transaction management) and supports integration with other components to support others – for example Hibernate for persistence, Terracota for clustering – and does not rely on an application server (although it can be deployed within one).
It will be interesting to see where this ends up, and whether Web Beans ends up moving closer to or further away from the model adopted by Spring.
But what about the application server ? Certainly not dead, but perhaps leaner.
Hopefully these POJO based approaches will make design decisions less about the deployment architecture and specification constraints and more about implementing the business logic.