Having come from a technical background, this is my first tech post. With the EJB 3.1 specifications finalized on 10 Dec, 2009, I wanted to touch upon the new features introduced and how it would affect the developers.
EJB Interfaces are not mandatory any more:
From Specification: “A simplified Local view that provides Session Bean access without a separate Local Business interface.”
Many a times I have wondered why we go through the pain of declaring interfaces when we know for sure that it would not be required. This gets more painful when you use RAD (Rational Application Developer), since you also have to create a separate project for the EJB Client.
One can declare Session beans or MDB with just the annotation @stateless or @stateful.
Packaging made simple:
From Specification: “Packaging and deployment of EJB components directly in a .war without an ejb-jar.”
Developers can package the EJB classes within a WAR file like a POJO and the annotations will do the magic. They can also declare the EJB in WEB-INF/ejb-jar.xml. This makes the EJB available in the same namespace as the WAR.
Singleton EJBs:
From Specification: “A Singleton session bean component that provides easy access to shared state, as well as application startup/shutdown callbacks.”
As I think of it this should have been introduced a long ago. Until now developers had no definitive way of sharing application wide data with concurrency. Most third-party caches had their own pros and cons, each having a focus area. Declaring static variables in an EJB is a nightmare (atleast for me). You can manage concurrency either by yourself or leave it to the container by declaring it with annotations.
EJB Timers:
From Specification: “Automatically created EJB Timers” & “Calendar based EJB Timer expressions.”
Though there was some Timer support in earlier version it was difficult to use with not much support for cron like scheduling. With simple annotations developers can schedule periodic runs for a method.
Asynchronous Services:
From Specification: “Asynchronous session bean invocations”
This one is really ingenious. Developers can declare an EJB (or a specific method) to be asynchronous using annotation (i.e. @javax.ejb.Asynchronous) and this EJB can be used just like a JMS queue.
EJB Lite:
From Specification: “The definition of a lightweight subset of Enterprise JavaBeans functionality that can be provided within Java EE Profiles such as the Java EE Web Profile.”
One of the major points made in support of not using EJBs is that they are heavy-weight and many applications won’t ever need all the container services provided by the specifications. EJB lite seems to be an attempt to silence this. I’m not sure whether it’s already late with other alternatives lying around like Spring, OpenEJB, etc. But EJB lite provides support for Stateless, stateful and singleton session beans with transaction and security services.
Overall, EJB 3.1 specs appear to be a definite positive step forward, evolving with time and competition.
0 comments:
Post a Comment