Clouds
Home

Test Driven Development

Aspect Oriented Programming

Annotation Based Programming

Inversion Of Control - Part 1

Inversion Of Control - Part 2

Hibernate Interview Questions - Part 1

Hibernate Interview Questions - Part 2

Hibernate Interview Questions - Part 3

Spring Interview Questions

EJB 3.0 Interview Questions

EJB 3.0 Interview Questions


How would EJB 3.0 simplify your Java development compared to EJB 1.x, 2.x ?

EJB 3.0 is taking ease of development very seriously and has adjusted its model to offer the POJO (Plain Old Java Object) persistence and the new O/R mapping model inspired by and based on Hibernate (a less intrusive model). In EJB 3.0, all kinds of enterprise beans are just POJOs. EJB 3.0 extensively uses Java annotations, which replace excessive XML based configuration files and eliminate the need for rigid component model used in EJB 1.x, 2.x. Annotations can be used to define a beanís business interface, O/R mapping information, resource references etc. EJB 3.0 also supports XML files for overriding default values and configuring external resources such as database connections.
  • In EJB 1.x, 2.x the container manages the behavior and internal state of the bean instances at runtime. All the EJB 1.x, 2.x beans must adhere to a rigid specification. In EJB 3.0, all container services can be configured and delivered to any POJO in the application via annotations. You can build complex object structures with POJOs. Java objects can inherit from each other. EJB 3.0 components are only coupled via their published business interfaces hence the implementation classes can be changed without affecting rest of the application. This makes the application more robust, easier to test, more portable and makes it easier to build loosely coupled business components in POJO. The business interface:

    public interface Account {
    public void deposit(double amount);
    }


    The bean implementation class:

    @Stateless
    @Remote({Account.class})
    public class AccountBean implements Account {
    public void deposit(double amount){
    //..
    }
    }


    you can also specify multiple interfaces for a session bean. One for local clients and one for remote clients.
  • EJB 3.0 unlike EJB 1.x, 2.x does not have a home interface. The bean class may or may not implement a business interface. If the bean class does not implement any business interface, a business interface will be generated using the public methods. If only certain methods should be exposed in the business interface, all of those methods can be marked with @BusinessMethod annotation.
  • EJB 3.0 defines smart default values. For example by default all generated interfaces are local, but the @Remote annotation can be used to indicate that a remote interface should be generated.
  • The EJB 3.0 (i.e, Inversion Of Control design pattern) container takes care of the creation, pooling and destruction of the session bean instances and the application only works with the business interfaces. But if the application needs a finer control over the session beans, for example to perform database initialization when the container creates the session bean or close external connection etc, you can implement lifecycle callback methods in the bean class. These methods are called by the container at various stages(e.g. bean creation and destruction) of the beanís lifecycle. Unlike EJB 2.1, where all callback methods must be implemented even if they are empty, EJB 3.0 beans can have any number of callback methods (i.e. even no methods at all) with any method name. In EJB 3.0, you can specify any bean method as a callback by annotating it with the following annotations @PostConstruct, @PreDestroy, @PrePassivate, @PostPassivate, @PostActivate, @Init, @Remove (only for stateful session beans) and @PostConstruct.

    public class AccountBean implements Account {
    //...
    @PostConstruct
    public void initialize(){
    //initialize data from the database
    }
    @PreDestroy
    public void exit(){
    //save data back to the database
    }
    }


  • An MDB (Message Driven Bean) class must implement the MessageListener interface.
  • EJB 3.0 makes use of dependency injection to make decoupled service objects and resources like queue factories, queues etc available to any POJO. Using the @EJB annotation, you can inject an EJB stub into any POJO managed by the EJB 3.0 container and using @Resource annotation you can inject any resource from the JNDI.

    public class AccountMDB implements MessageListener {
    @EJB Account account;
    //use the "account" variable
    // ..
    }


  • EJB 3.0 wires runtime services such as transaction management, security, logging, profiling etc to applications at runtime. Since those services are not directly related to applicationís business logic they are not managed by the application itself. Instead, the services are transparently applied by the container utilizing AOP (Aspect Oriented Programming). To apply a transaction attribute to a POJO method using annotation:

    public class Account {
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public getAccountDetails(){
    //..
    }
    }


  • In EJB 3.0, you can extend the container services by writing your own interceptors using the @AroundInvoke annotation. You can specify any bean method as the interceptor method that will execute before and after any other bean method runs.

    @Stateful
    public class AccountBean implements Account {
    // bean methods that are to be intercepted by the log() method
    // ..
    @AroundInvoke
    public Object log(InvocationContext ctx) throws Exception {
    //..
    }
    }


  • EJB 3.0 supports both unidirectional and bidirectional relationships between entity beans. To create an entity bean, you only need to code a bean class and annotate it with appropriate metadata annotations. The bean class is a POJO.

    @Entity
    public class AccountEntityBean {
    private Integer accountNumber;
    private String accountName;
    @id (generate=AUTO)
    public Integer getUserId() {
    return this.accountNumber;
    }
    //getters & setters
    //..
    }


  • EJB QL queries can be defined through the @NamedQuery annotation. You can also create regular JDBC style queries using the EntityManager. POJOs are not persistent by birth and become persistent once it is associated with an EntityManager.

    Test Driven Development Interview Questions >>>




    Home Clouds