J2EE - in a state of Flux

It has been nearly eight years since the J2EE spec came into the market. The need to address the distributed computing environment was the driving force behind it. With a lot of industry backing the spec has been implemented by a lot of vendors and the developer community embraced the new programming paradigm with a lot of enthusiasm. But today the landscape of java looks different. The fortress of the J2EE specification has been broken. Lot of third party frameworks have come in and there is a lot of choice available to the developer community. This article focuses of on some of the key frameworks and their impact on J2EE along with the future direction of the spec itself. 
The most talked about framework today is the Spring framework conceived and developed by Rod Johnson. It aims at simplifying the J2EE development process by introducing a light weight container and supporting an easier coding infrastructure. Though there is a lot amount of debate on whether Spring is gathering more number of supporters in the software community, I would still hold on to the point that the Spring framework is only a natural evolution in the J2EE space. Since 1998 there has been constant innovation and extensions to the J2EE spec. From j2ee1.2 to 1.5, the platform has grown in maturity and clarity. The concept of EJB’s which came in for a lot of flak in its initial days has proved over a period of time that despite its heavy infrastructure and bloated coding is still very effective and scalable –as attested by numerous J2EE projects executed over the last few years. 
The reason for looking at an alternative to J2EE is simply to check out if there is a simpler way of doing things. The concept of dealing with POJO’s (Plain old java objects) vis-à-vis contrived coding methodology as in the case of entity beans seems a point in question. The Spring framework is light-weight container working on the principle of Inversion of control. This simply means that the dependencies of objects are resolved by the spring container during object creation. Objects do not have to have elaborate look up’s for resources and services (The typical JNDI way!). These are injected into the object as and when it is required. The Concept of AOP (Aspect Oriented Programming) adds another interesting dimension by applying common services required by various modules at appropriate points thereby avoid the need for duplication of code. Since most of the configuration is done through XML files, Maintainability and reusability of codes become easier and allows high level of decoupling. 
All the above mentioned features are only new ways of achieving the same objective. Frameworks such as Spring only plug into the existing J2EE environment. In fact the framework is not a monolithic one. Architects can choose aspects of Spring that would like to integrate. This clearly shows that the base J2EE architecture is preserved intact. 
Today, at least in the J2EE space, we have to clearly work with many frameworks in tandem. Sticking to a particular app server and locking the application is not a desired solution. The reason for J2EE’s popularity is the variety and choices it offers to Developers, vendors and end-users. One needs to judiciously decide the best possible technological choice for a given domain and problem context. It is staggering to know that for web solutions alone there are about 26 frameworks addressing different areas of development. All of these are open source frameworks and developed by the members of the java community. Sun actively participates in the furtherment of these initiatives. In the Java one Conference 2006, AJAX and Spring were given their due prominence. This only goes to show that J2EE is not being superseded but only enhanced by these new frameworks.  
One area where J2EE failed was its database modeling through Entity beans. Hibernate, Toplink and other ORM frameworks was far better effective in dealing with databases.

Supports for these beans have been clothed with a lot of debate and controversy With EJB 3.0, Sun has eventually transformed the Entity bean into something simpler and more intuitive. Annotations have been liberally used to cut down the boiler plate code –which was the norm as of EJB 2.0. Relationships are also better handled in the new spec. But unfortunately, the industry has already adopted other ORM models. It needs to be seen how EJB3.0 gains inroads into this space. JEE 5.0 is round the corner and lots of new enhancements have been proposed. The introduction of JMX (Managed Beans), which incidentally had been incorporated in JBOSS, will add another level of abstraction for managing components and resources within the container.  
 
As it seems to me, there is going to be a lot more changes in this area. The new avatar of .NET is still to make its impact felt in the market. Only time will tell how many of these innovations will actually take root. But one thing is certain, we need to be constantly in touch with the market trends and adapt ourselves accordingly. 
I will talk about the basics of the Spring framework in my next installment. Until then – be of good cheer.