Did you use EJB 2.x before moving to EJB 3.0? If so, you might be well informed about the “waves” of changes that EJB 3.0 brought in.
EJB was hated by the programmers because of it’s complex programming model and a “heavy weight approach” for developing applications. Yes, you know about the pain, might have experienced it and would have vowed never to use ejb again. Chances are there that you might have considered or even moved to alternate “light weight” frameworks like Spring.
Fortunately, the ejb spec designers listened to the community and came out with a much much simpler programming model with EJB 3.0. Now, the ejb deployment descriptor is optional and the home interface has gone. You can lookup other ejbs by using a simple @EJB annotation, without the need for “jndi”. And all your EJB 3.0 classes are now ordinary “POJO”s, with a little bit of annotations. This makes it extremely simple to “unit test” your ejbs unlike the EJB 2.x era.
But even then, people complained about a “lot’ of other things. For example, you need a ejb container to deploy ejbs whether it’s embedded (like the one provided by jboss) or standalone. Where as, you don’t need any such thing to deploy frameworks like Spring. Yes, this is not the only one issue raised.
So, what did the ejb spec designers do? Did they hear the community’s voice?
Not surprisingly they are hearing it. (EJB 3.1 spec is still in it’s intial stage)
And here are the (possible) new features that might be available in EJB 3.1:
– EJB interfaces are optional.
– A new type of bean called Singleton Bean.
– Support for direct use of EJBs in the servlet container.
– Simplified ejb packaging options. This means you can have your ejb classes inside the WEB-INF/classes directory.
– EJB Timer Service enhancements to support cron-like scheduling .
– Support for stateful web services.
– EJB support in minimal containers (like Tomcat) in the form of EJB Lite.
– Support for asynchronous Session Bean invocation.
– The standardization of JNDI mapping.
There can be even more, as the draft is finalized.
This sounds really great, which would help uplift the image of ejb. But what’s more important is, the application server vendors should quickly provide their implementations as well, to spread adoption of this new spec.