If we look at the way Java open source technologies are advancing around plain old Java objects, we can definitely say that this is an era of POJOs. Now, you may be feeling that writing functionality in simple objects is enough to build a complex application, where rest of the supporting services can be provided externally. Spring has be the front runner in building technology around POJOs. But Sun’s recent releases of SDK and JEE are focusing on the same principle. EJB is not left out from Sun’s this focus, upcoming release of EJB specification 3.1 tries to make this competition fierce. In this article, we try to see what these two technologies are trying to give us, while competing with each other.
Following new features definitely take EJB to a new level but simultaneously some of these do challenge Spring framework.
- Simplified Local View: A simplified Local view that provides Session Bean access without a separate Local Business interface. EJB accessed locally simply means objects communicating in same JVM. Now if EJB specification requires an interface just to provide container offered services to the object, then Spring is already doing it with some simple configuration and without touching the POJO or requiring any interface. EJB 3.1 just removes this hurdle to be in line with what Spring already has, but it still leaves remote accessibility through an interface only. Just to give an example, this is how the EJB will look like now and this is how we can access it.
NewEJB.java
@Stateless
public class NewEJB {
public String printString(){
Return "I am new EJB":
}
}
Accessing this new EJB
Access.java
...
....
@EJB
private NewEJB newEJB;
public void main (String[] args) {
System.out.println( newEJB.pringString());
}
...
...
- Simple Packaging: Packaging and deployment of EJB components directly in a .war without an ejb-jar. Preparing EJB for deployment is always an additional step, when you are deploying an application. If you are doing the build using an advanced tool like Maven, then it is just few lines of xml, but if you are doing it manually or with a less advanced tool, then it is really a pain, where you feel like getting rid of this step. EJB 3.1 simplifies this.
- Run on Java: An embeddable API for executing EJB components within a Java SE environment. Java is to build once and run anywhere, then the business components must be able to run on any JVM which is plugged in with something that can run these special components, isn’t it similar to we plugging in Spring container to the JVM and to manage all objects. EJB has adapted it and the new feature is on it’s way.
- Number of Instances: A Singleton session bean component that provides easy access to shared state, as well as application startup/shutdown callbacks. EJB container is creating EJB instances then it must be able to manage how many instances it creates. Not sure why but somehow this thing was missing since beginning of EJB. Spring container makes it configurable through the singleton/prototype properties. Now we have it available in EJB.
Following changes to EJB are specific to EJB that to compare with Spring.
- Automatically created EJB Timers.
- Calendar based EJB Timer expressions.
- Asynchronous session bean invocations.
- 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.
- A portable global JNDI name syntax for looking up EJB components.
Remote Accessibility
This is why we used EJBs for ages, cause this technology provided something more than what others like RMI, CORBA etc. provided. Security, transaction, lookup etc. services are offered by EJBS. What alternative Spring has to offer to counter remote access? It is Spring web services. Something that is simple (though based on interface), which brings in good from web services to address remote accessibility.
What More EJB Needs?
There are many more things which EJB or Sun needs to match though it has be pioneer in Java technology. Just for example, the unit testing framework, integration with technologies like AspectJ, which handle cross cutting concerns and so on. If you can think of any more points then leave as a comment.
