J2EE seems to be on the right track with EJB3 architecture
J2EE at its early stages was designed to cater a world having a component market place. The extent to which it has materialized this objectve is doubtful. Anyway it is clear most of the time J2EE is used to solve a complex business problem rather than to write course-grained components that can be plugged seemlessly between systems.
If we look at the EJB2.o or EJB2.1 frameworks they seems to be designed to favour big J2EE vendors not the poor J2EE developers :) . The complexity of the platform required complex tools in supporting the development. Further more developers were spending most of the time solving complex J2EE configuration issues rather than solving the business problem in hand.
Few of the most significant drawbacks of the EJB2.x architecture are
- its non-ability to test the business components out side the container.
- dependency lookup nature of JNDI requred high amount of coding in refering a resource.
- entity beans are not serializable so DTOs are to be used causing more coding and less performance.
- deployment discriptors are hugely complex and has a steep learning curve.
- making the business component classes completely independent of the EJB framework classes is not possible even with a complex patterns due to framework abstractions and wiered checked exceptions of the framework. (For an example you could write a POJI as a framework independent interface for your business object and let EJBObject interface to extend it, if the RemoteException class was a unhcecked exception)
- EJB-QL was unable to solve most of the complex querying requirements
... and more... and more....
Some times I was thinking like Sun may not have any people actually doing projects in J2EE, even they involve designing J2EE archtecture. The EJB2.x design is that much cumbersome and developer frustration was that high specially when your company doesnt want to spend on complex tools for J2EE development.
Any way as the time passes, Some open-source products like Spring for business tier and Hibernate for persistance seemed to be right tools compared to EJB2.x. Assembling your own container with Tomcat, Spring and Hibernate was seemed to be the better way for data centric web projects. Both hibernate and Spring uses POJO model, making out side the container testing to be very mush easier (to be more precise they dont run withing a context of a container).
Spring uses Dependency injection pattern to inject any resources required by the components. The setter injection model has prooved to be very useful specially in unit testing. Here you can find a very simple example demonstating the concept behind Sping framework. Also the light weightness of Spring and Hibernate attracted most of the frustrated EJB2.x developers.
But today EJB3.0 is well designed to solve most of the EJB drawbacks it had in early versions. It has learnt very much from Spring and Hibernate. Persistance model is completely redesigned following the Hibernate model. In EJB3 you enterprice beans are POJOs and not dependent of any framework classes. It largly make use Annotations and avoid use of abstractions as much as possible.
In my openion this trend brings a hope to a much better form of frameworks. if I remember right a framework is defined a set of abstractions on which developers can extend. Hibernate/Spring uses reflection to avoid framework specific abstract chasses and intefaces... EJB3.0 uses annotations and avoid use of framework classes as much as possible. This allows the developers to consentrate more on the actual business logic.
In future blogs I will describe how EJB3.0 integrates most of the powerful features of Hibernate and Spring to make our lives easier. For me it seems with EJB3.0 Java communty is well armed to face M$ challenge ...