JSR 244 started yesterday, is the specification request for the next release of the J2EE platform spec, 1.5.
The key goal of 1.5 is for ease of development. This may mean increased use of metadata (being introduced in J2SE 1.5) to allow developers to specify class behavior (eg, markup tags to signify an EJB) by using tags similar to XDoclet’s approach, or maybe some other approach.
I think the key for J2EE 1.5 is they have to make a solid commitment to where the EJB spec is going. Hibernate and JDO are already showing a large following, and if the EJB spec does not follow in a similar approach, in particular with Entity Beans, then I think the use of Entity Beans will become irrelevant.
Sun have submitted a JSR (243) for the next version of the JDO specification, 2.0.
As JDO is seen as a viable alternative to Entity Beans, it makes you wonder were Sun is headed with this, especially as they are also working on the EJB3.0 spec.
It would make sense to leave Entity bean support in future J2EE specs for backward compatibility, but surely they must see that the majority of everyone else is going in the direction of Object persistence (with Hibernate and JDO), while Sun are still beating Entity Beans to death? And the majority of those who have implemented systems with Entity Beans are moaning about how complicated the development is, poor performance, bad fit with the Business Domain Model etc?
O’Reilly’s OnJava.com site have a good article on developing webapps using a combination of Struts, Spring and Hibernate.
The section on using Spring is very interesting – using Spring gives you declaritive control over the dependencies between objects, and therefore also between application application layers. This can be used to further reduce coupling between code in each architectural layer, for example between Presentation and Business, and between Business and Persistence.
From what I understand about the use of Spring (or other ‘microcontainers’), it gives you a level of abstraction and allows you to reduce direct coupling between Classes by being able to define relationships and dependencies declaritively (rather than in actual code). I think this can be compared to what the struts-config.xml gives you for webapps, in that it reduces coupling between web pages and page navigation, and the logic that controls that navigation.