Features of EJB 3.0
Now its time to look over the new features of EJB 3.0 that provides some simplification over the previous EJB API. There are various simplification made in EJB 3.0 like:
Now we will discuss all the above aspects of EJB3.0 that makes the EJB programming model simple and more efficient.
Elimination of Home and Remote Interfaces: Deprecation of home and remote interfaces simplifies the development. The new session beans contain all the business methods inside the business interface. The bean provider designates the business interface as local business interface or the remote business interface or both according to the client whether it is local or remote. Business methods on remote interface can throw arbitrary application exceptions, while they are not allowed to throw java.rmi.RemoteException. While in case of EJB 2.1 all the methods of home and object interface throws the java.rmi.RemoteException. Package javax.ejb.EJBException encapsulates exceptions such as protocols, system level problems, or otherwise that the container returns to the client. Since EJBException is the subclass of the java.rmi.RemoteException therefore we did not include it in throws clause of business methods.
A message driven bean does not need to include the business interface as there is no direct interaction of the client with the message driven bean. Whenever a MDB has an unexpected problem then the container logs the error and communicate it with the help of javax.ejb.EJBException to the corresponding resource adapter rather than the client.
Elimination of Component Interface: Component
interface in EJB2.1 or in earlier versions are used to provide a way through which the container
notifies the bean instances
of various life cycles they are affecting it. The previous versions of the
component interface are used to stay in the events in its lifecycle. These
component interfaces includes the various life cycles methods
implemented by the bean class. The container used to call the appropriate method
of the component interface to handle the bean's instance life cycle
events according to the way it wants.
Now the next question that arises is that how a bean class get notified by the container if it is interested? The solution is that there are two ways to do so, the first one is, the bean provider can implement a separate bean class that consists of all the callback notification methods that inform the container to treat it as a listener class. The second way is that, a bean provider can implement the notification method inside the bean class and designate this method to handle the corresponding events In both the cases bean class uses annotations. Annotations are the additional key features of EJB 3.0 specifications. To know about the annotation just click on the link annotations.
Simplified Access to Environment: Almost all the
EJBs are required to access the environment to gain access to external resources,
enterprise beans and other entries like properties. To get hold of these
entries EJB mainly relies on JNDI API. EJB 3.0 also includes the features like
lookup method on the EJBContest and dependency injection to access the
EJB Context: Bean must know about its environment at runtime such as security principle, transaction context in which its method is invoked and so on. javax.ejb.EJBContext API works like a window for the bean to the outside world through which it is interacting to the container. EJBContext is further categorized into SessionContext and MessageDrivenContext for the session beans and message driven beans respectively. Bean instances may use the dependency injection to access EJBContext instance. Another way through which a JNDI accesses the environment variables is the lookup() method of the EJBContext interface. Bean must use the JNDI API to access the environmental dependencies.
Enhanced Lifecycle Methods and Callback Listener Classes: EJB 3.0 does not enforce to implement all unnecessary callback methods but can designate any other method to receive the notification for life cycle events. We can also use the callback listener class instead of callback methods defined in the same bean class.
Interceptors: An intercept is a method used to intercept a business method invocation. Stateless session beans, Stateful session beans and message driven beans may includes the interceptors. We can also define an interceptor class instead of defining the interceptor methods in the bean class.
Simple JNDI lookup of EJB: Lookup of the EJB has been simplified so that the client can directly invoke methods on EJB rather than creating the bean instance simply by invoking create method on EJB.