Features of EJB 3.0

This page discusses - Features of EJB 3.0

Features of EJB 3.0

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:

  • No need of home and object interface.
  • No need of any component interface.
  • Made use of java annotations.
  • Simplifies APIs to make flexible for bean's environment.

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.
For example, the container notifies the message driven bean instance that it is about to destroy, simply by invoking ejbDestroy() method on the corresponding class of  the message driven bean. Bean class can close the JDBC database connection within the ejbDestroy() method to free up the resources. Similarly the container that is going to associate a client in case of stateful notifies the bean instance by calling the ejbCreate() method on the bean class and the bean class instantiates the bean instance. Consider the situation, when the bean does not receive the notification from the container about its life cycle's methods then the bean has to implement the component interfaces regardless whether it is needed or not. In case of session bean, the bean class does not need to implement the javax.ejb.SessionBean or javax.ejb.MessageDrivenBean in case of message driven bean.

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 bean's dependencies.

Dependency Injection: Dependency injection is the mechanism through which the container injects the requested environmental entry to make available to the bean instance before any bean instance is invoked on that particular instance. Then the container injects these entries into bean variables or methods. It is bean provider's duty to tell the container that which method or variables should be injected at runtime. The bean provider can do this by using the deployment descriptor or annotations. Bean methods used for dependency injection should follow the java naming convention for properties in that they should follow the setXXX() convention. 
Consider the situations like dependency injection fails due to some reasons, the container can not make available the environmental entries due to which the bean is functioning properly, in such situations the container discards the bean instances and creates new instances.

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.

Tutorials

  1. C Tutorials
  2. C Array copy example
  3. C Array Declaration
  4. C Array default values
  5. C Array length example
  6. C array of pointers
  7. C array sort example
  8. C String length
  9. C Break with Switch statement
  10. C Break for loop
  11. C break continue example
  12. Array of String using Pointers
  13. C Array of String
  14. C String to Int
  15. C define Macro
  16. C Current Time
  17. C String Remove Spaces
  18. C Pointer to a function
  19. C Multiple Indirection
  20. C Goto Statement
  21. C GMT Time
  22. C file write example
  23. C file rename
  24. C file read example
  25. C file open example
  26. C file Last Modified Date
  27. C file delete example
  28. C Dynamic Array
  29. C String Copy
  30. C String Concatenation
  31. C String Compare
  32. C Replace String
  33. C String lowercase
  34. C String Join
  35. C get Substring from String
  36. C Temperature Converter
  37. C Structure Pointer
  38. C Structure example
  39. C String uppercase
  40. C String Tokenizer